Le module Audit File Export dans Business Central: architecture et configuration
Index 
Le précédent article a posé le cadre: une obligation légale précise, des normes techniques détaillées jusqu'au moindre champ, une sanction qui ne pardonne ni l'absence ni la non-conformité du fichier. Reste une question pratique: comment un ERP traduit-il cette contrainte réglementaire en fonctionnalité logicielle? Microsoft Dynamics 365 Business Central y répond par un module dédié, Audit File Export, conçu dès l'origine pour être décliné pays par pays. Cet article en présente l'architecture générale, puis la configuration commune, avant de détailler les deux voies principales que sont SAF-T et le FEC.
Une architecture pensée pour être étendue
Le module repose sur un nombre restreint d'objets pivots.
La table Audit File Export Header, numéro 5265, porte un document d'export: une demande de génération pour une période donnée.
La page Audit File Export Doc. Card, numéro 5267, en constitue l'interface de pilotage.
Autour de ces deux objets gravitent une table de lignes de traitement, une table de fichiers générés, et deux tables de paramétrage, l'une pour la configuration générale, l'autre pour les options propres à chaque format.
Le choix d'architecture le plus structurant se trouve ailleurs. Le champ Audit File Export Format n'est pas une simple valeur de liste, c'est une interface. Chaque valeur de cet enum implémente deux contrats logiciels, l'un pour la vérification des données avant export, l'autre pour leur transformation en fichier.
Le socle du module ne fournit qu'une implémentation vide. Chaque extension pays y ajoute la sienne.
SAF-T ajoute une valeur SAFT, reliée à son propre moteur de génération XML.
Le FEC ajoute une valeur FEC, reliée à un moteur qui produit un fichier texte à plat.
La page 5267, elle, ne change jamais de structure: elle délègue systématiquement au format actif, et se contente d'afficher ou de masquer certains champs selon la sélection. Un mécanisme d'extension par interface, sobre, qui évite toute duplication de code entre pays.
Le paramétrage commun à tous les formats
Avant tout export, deux éléments de configuration s'imposent, quel que soit le format retenu.
Configuration de l’exportation de fichier d’audit
Centralise le format proposé par défaut à la création d'un document, ainsi qu'un ensemble de contrôles de qualité de données (adresse, code postal, coordonnées bancaires) pertinents pour SAF-T, mais sans effet pour le FEC.
Configuration du format d’exportation de fichier d’Audit
Fixe, pour chaque format installé, le modèle de nom de fichier et l'option d'archivage en Zip.
Pour le FEC le nom du fichier n’est pas à spécifier car le process le construit en fonction des normes de l’administration fiscale. (SIREN + FEC + Date de clôture)
SAF-T: un assistant plutôt qu'une simple page
La configuration de SAF-T ne se résume pas à quelques champs: elle passe par un assistant dédié, le SAF-T Setup Guide, qui déroule plusieurs étapes successives. Le choix du type de compte standard à utiliser, la période du premier fichier à produire, le mapping du plan comptable de l'entreprise vers le référentiel normalisé, le mapping de la TVA compte par compte, l'export des dimensions analytiques, puis la désignation de l'employé responsable du contenu du fichier.
Deux actions automatisent une partie de ce travail: le rapprochement automatique du plan comptable existant avec le référentiel normalisé, et la création d'un plan comptable directement à partir de ce référentiel lorsque l'entreprise n'en dispose pas encore.
Cet assistant illustre une différence de nature entre les deux formats. SAF-T exige une modélisation préalable des données comptables: mapping des comptes, des taux de TVA, des dimensions. Le FEC, lui, se contente d'extraire les données telles qu'elles existent déjà dans le grand livre.
Le FEC: une configuration réduite, des prérequis stricts
À l'installation de l'extension FEC, le paramétrage minimal se fait sans intervention: le format est enregistré automatiquement, sans nom de fichier particulier ni archivage en Zip.
Le FEC produit toujours un fichier texte unique, jamais une archive.
Aucun assistant, aucun mapping de comptes à réaliser en amont. La configuration se déplace alors sur le document d'export lui-même, avec trois champs propres au format: l'inclusion ou non des soldes d'ouverture, un code journal par défaut pour les écritures qui n'en portent aucun, et un filtre optionnel sur le plan comptable pour restreindre le périmètre exporté.
Cette simplicité de paramétrage ne dispense pas d'un travail préalable sur les données. Deux vérifications s'imposent avant toute première génération.
D'abord, le numéro SIREN, renseigné dans les informations de la société: il conditionne le nom du fichier final et bloque l'export en son absence.
Ensuite, la qualité du plan comptable et des codes journaux déjà présents dans la base (numéros de comptes conformes au plan comptable général, libellés rédigés en français, sans transcodage de masse ni reliquat d'une configuration importée d'un groupe étranger).
Le module ne corrige rien de lui-même. Il se borne à extraire ce qui existe déjà.
Trois enseignements ressortent de cette architecture.
- La logique d'extension par interface garantit une cohérence d'usage entre formats, sans imposer les mêmes contraintes de configuration.
- Le niveau d'exigence en amont varie fortement: lourd pour SAF-T, léger pour le FEC, mais jamais nul.
- Dans les deux cas, le module reflète la qualité des données déjà présentes dans Business Central. Il ne la corrige pas.
Une fois ce paramétrage en place, reste l'essentiel: produire le fichier, en suivre l'exécution, et comprendre comment chaque champ réglementaire se construit à partir des données de Business Central.
C'est l'objet du prochain article, consacré à l'utilisation quotidienne de la page Audit File Export Doc. Card, à la planification du traitement en arrière-plan, et au détail du mapping des dix-huit champs du FEC.
Aucun commentaire pour le moment.