Générer le FEC dans Business Central: utilisation, planification et mapping des champs
Index 
L'article précédent a détaillé l'architecture du module Audit File Export et sa configuration, commune d'abord, puis propre à SAF-T et au FEC. Une fois ce paramétrage réalisé, trois questions demeurent: comment piloter un export au jour le jour, comment le traitement se planifie en arrière-plan, et surtout, comment chacun des dix-huit champs réglementaires du FEC se construit à partir des données déjà présentes dans Business Central. Ces trois points font l'objet du présent article.
Piloter un export depuis la page Audit File Export Doc. Card
Chaque export correspond à un nouveau document, créé depuis la liste Audit File Export Documents.
Le format est hérité du paramétrage général, puis modifiable. Pour le FEC, la carte affiche un groupe de champs dédié: l'inclusion des soldes d'ouverture, le code journal par défaut, et le filtre optionnel sur le plan comptable.
Les champs propres à SAF-T (découpage mensuel ou journalier, archivage en Zip, commentaire d'en-tête) restent masqués dès lors que le format FEC est sélectionné. La carte s'adapte au format, non l'inverse.
Le groupe Processing affiche l'état d'avancement: statut du document, dates de début et de fin d'exécution, et pour SAF-T uniquement, le résultat du dernier contrôle de données.
Une sous-page liste les lignes de traitement, une seule pour le FEC dans la plupart des cas, davantage pour SAF-T selon le découpage retenu.
Chaque ligne propose quatre actions: relancer le traitement, afficher le message d'erreur de la dernière tentative échouée, consulter le journal d'activité, télécharger le fichier produit.
Quatre actions structurent le cycle de vie du document.
- Contrôle de données, réservé à SAF-T: vérifie en amont la complétude des fiches clients, fournisseurs, comptes bancaires et paramétrage TVA.
- Démarrage: crée les lignes de traitement et lance la génération. Pour le FEC, ce démarrage vérifie au passage que les dates de période et le numéro SIREN sont renseignés, et échoue si aucune écriture ne correspond au périmètre défini.
- Recréation des fichiers: reconstruit le résultat final à partir des données déjà collectées, sans relancer toute la collecte, utile pour changer une option d'archivage sans tout recommencer.
- Téléchargement: ouvre la liste des fichiers produits.
Dès que toutes les lignes atteignent le statut Terminé, la génération du fichier final s'enchaîne automatiquement. L'action de recréation ne sert donc qu'à une nouvelle génération volontaire.
La planification du traitement en arrière-plan
Le module ne s'appuie pas sur la file d'attente de tâches classique de Business Central, mais sur le planificateur de tâches interne, celui qui exécute des sessions en arrière-plan sans file d'attente visible.
Trois paramètres gouvernent ce comportement sur la carte:
- Traitement parallèle, activable seulement si l'environnement l'autorise techniquement.
- Nombre maximal de tâches simultanées, fixé à trois par défaut.
- Date-heure de démarrage au plus tôt, qui conditionne le lancement effectif des tâches planifiées.
Un délai de quelques secondes sépare chaque planification de ligne, pour limiter les conflits de verrouillage entre sessions concurrentes.
Le statut du document suit une logique simple: non démarré, en cours, puis terminé ou échoué selon l'issue des lignes qui le composent.
Chaque ligne dispose d'un compteur de tentatives, initialisé à trois.
En cas d'échec, le module consigne l'erreur dans le journal d'activité, décrémente le compteur, et relance automatiquement les lignes qui n'ont pas encore démarré.
Un mécanisme complémentaire détecte les sessions perdues (un serveur redémarré en cours de traitement, par exemple) et relance les lignes restées bloquées en cours d'exécution sans qu'aucune intervention manuelle ne soit nécessaire.
Ce dispositif reste toutefois dépourvu de récurrence native. Aucune intégration à la file d'attente de tâches standard n'est prévue par défaut.
Automatiser une génération périodique, mensuelle pour SAF-T ou annuelle pour le FEC, suppose d'encapsuler l'appel au module dans un codeunit personnalisé, déclenché lui-même par une entrée de file d'attente classique. À défaut, le déclenchement reste manuel, ce qui convient à un usage ponctuel, moins à une production récurrente.
Le mapping des dix-huit champs du FEC
Le moteur de génération du FEC parcourt les écritures de grand livre de la période, dans les limites du filtre de comptes éventuellement défini, et construit une ligne par écriture. La correspondance avec les données de Business Central suit une logique directe, à quelques exceptions près qui méritent attention.
Identification du journal et de l'écriture
- JournalCode / JournalLib: proviennent du code source de l'écriture, ou du code source par défaut renseigné sur le document lorsque l'écriture n'en porte aucun. Le libellé associé est celui déclaré dans la fiche du code source.
- EcritureNum: reprend le numéro de transaction interne de Business Central, dans une séquence unique et continue sur l'ensemble du fichier, jamais reprise par journal.
- EcritureDate: correspond à la date de comptabilisation de l'écriture.
Identification du compte et du tiers
L'identification du compte est directe.
- CompteNum / CompteLib: reprennent le numéro et le nom du compte général tels qu'enregistrés dans le plan comptable.
- CompAuxNum / CompAuxLib: ne se renseignent que lorsque le compte général exporté correspond au compte de contrepartie client, fournisseur, ou à un compte de rapprochement bancaire. Sur les autres comptes, ces champs restent vides, conformément à la règle du champ conditionnel toujours présent mais parfois vide. Lorsqu'une transaction regroupe plusieurs tiers, le module inscrit une valeur conventionnelle, un astérisque en CompAuxNum et une mention explicite en CompAuxLib, à documenter dans le descriptif d'accompagnement.
Pièce justificative, libellé et montants
- PieceRef / PieceDate: reprennent directement le numéro et la date de document de l'écriture.
- EcritureLib: correspond à la description saisie sur l'écriture.
- Debit / Credit: reprennent les montants au débit et au crédit tels qu'enregistrés, formatés sans séparateur de milliers et avec une virgule décimale.
Lettrage, validation et devise
- EcritureLet / DateLet: restituent les références de pièces des écritures appliquées en règlement et la date de la dernière application trouvée. Ces champs restent vides en l'absence de rapprochement.
- ValidDate: Business Central ne disposant pas d'un mode brouillard distinct pour le grand livre général, ce champ reprend la date de création du lot d'écriture (le G/L Register) plutôt qu'une date de validation métier à proprement parler. Dans la majorité des cas, cette date coïncide avec la date de comptabilisation. Un écart peut apparaître en cas de saisie différée par rapport à l'événement comptable.
- Montantdevise / Idevise: ne se renseignent que sur les écritures portant une devise étrangère, et restent vides sur les opérations en devise de tenue de comptabilité.
Cas particulier: les soldes d'ouverture
Un cas mérite une mention séparée. Lorsque l'option correspondante est activée sur le document, le module génère des lignes de solde avec un code journal fixe, 00000, un libellé de journal fixe, BALANCE OUVERTURE, et un numéro d'écriture fixe, zéro, pour l'ensemble de ces lignes. Cette convention, parfaitement lisible dans le fichier, doit néanmoins figurer explicitement dans le descriptif d'accompagnement, faute de quoi elle apparaît comme une rupture de numérotation aux yeux d'un vérificateur qui n'en connaîtrait pas l'origine.
Ce niveau de détail technique conditionne directement la conformité du fichier produit.
Le prochain article referme cette série avec les aspects opérationnels restants: permissions nécessaires, démarche de dépannage en cas d'échec, purge des documents obsolètes, et surtout les points de vigilance à connaître avant de considérer un export FEC comme définitivement fiable.
Aucun commentaire pour le moment.