Passer à la documentation
Flux ERP

Facture électronique
Repères pour DAF et DSI

Dossier de consultation / DAF et DSI

Mapping ERP : préparer les données de facture

Tracez champ source, transformation, contrôle et responsable pour préparer le mapping ERP des factures électroniques et traiter les données absentes.

Mis à jour le .

Définir un dictionnaire plutôt qu’une liste de champs

Le mapping relie une donnée métier de l’ERP à une donnée du message échangé. Pour chaque correspondance, documentez le champ source, la règle, le format attendu et le contrôle. Identifiez également le responsable capable d’expliquer la valeur. Un nom de colonne ne suffit pas : une date peut désigner l’émission, une livraison ou une échéance selon le module.

Quatre mentions sont nouvelles par rapport à la facture actuelle, selon la DGFiP : le SIREN du client, la catégorie de l’opération (livraison de biens, prestation de services ou mixte), l’option pour le paiement de la TVA d’après les débits et l’adresse de livraison lorsqu’elle diffère de celle du client. Identifiez pour chacune le champ source dans l’ERP, le responsable de sa valeur et le contrôle avant émission. Commencez par les factures validées et leurs lignes. Comparez le message obtenu à la pièce comptable de référence. Le dictionnaire doit permettre de comprendre les calculs et les enrichissements. Les formats et règles exacts dépendent des versions techniques applicables ; la documentation officielle fournit les références, tandis que votre dictionnaire décrit leur mise en œuvre dans l’ERP. Ne présentez pas un extrait comme une liste exhaustive des obligations.

Examiner le référentiel tiers

Le référentiel porte les données nécessaires à l’identification et au routage. Une raison sociale connue du commercial ne suffit pas à établir l’adresse électronique de facturation. Identifiez la provenance de chaque valeur et la méthode de contrôle. Séparez les identifiants juridiques, les établissements et les adresses utilisées par le dispositif de transmission.

Organisez le traitement d’un tiers incomplet. Le système peut bloquer le document avant envoi et présenter l’information à corriger au bon interlocuteur. Évitez une valeur par défaut qui détourne la facture vers une adresse sans justification. Documentez les corrections et leur effet sur les documents déjà préparés. Une mise à jour du tiers ne doit pas modifier silencieusement une facture validée conservée comme preuve.

Décrire les transformations de montants

La transformation doit préciser les unités, les quantités, les remises et les totaux. Faites valider les règles par la comptabilité sur des exemples fictifs. Un arrondi effectué ligne par ligne peut produire un résultat différent d’un calcul global. Le connecteur doit expliquer son comportement et conserver les éléments permettant de le vérifier.

Ne corrigez pas automatiquement un écart de TVA pour faire accepter un message. Comparez l’origine du montant et la règle de validation. Une anomalie peut venir du mapping, de l’ERP ou de la donnée saisie. Le dictionnaire indique le responsable de chaque décision. Les taux et traitements fiscaux propres à l’activité sont à faire valider par l’équipe fiscale.

Tester les valeurs absentes et les variantes

Construisez les tests à partir des cas réellement pratiqués : avoir lié à une facture, acompte, remise ou plusieurs références de commande. Pour chaque cas, vérifiez le document sortant et la réponse de la plateforme. Ajoutez une valeur absente et une valeur incompatible avec le format attendu. Le résultat doit montrer où le blocage est détecté et comment il est présenté à l’utilisateur.

Une transformation peut passer une validation XML tout en produisant une information métier erronée. Faites donc contrôler les pièces par un comptable et les messages par l’intégrateur. Conservez les données de test et les résultats. Si la règle change, vous pourrez rejouer les mêmes cas. Cette stabilité permet d’identifier une régression plutôt que de comparer des démonstrations fondées sur des exemples différents.

Gérer les changements de règle

Versionnez le dictionnaire avec la configuration du connecteur et les documents techniques utilisés. Toute modification doit préciser son motif et les cas concernés. Un changement de champ source dans l’ERP peut affecter un flux sans évolution de la norme. Inversement, une évolution de profil peut imposer un contrôle nouveau avec les mêmes données sources.

Avant production, faites valider les résultats sur un environnement distinct. Prévoyez comment revenir à la configuration précédente si la modification provoque un incident. Le responsable métier doit connaître les factures impactées et la décision de reprise. Le dossier de maintenance contient les règles, les exemples et l’historique des changements, afin qu’un autre intervenant puisse diagnostiquer le raccordement.

Grille à joindre à la consultation

Points à documenter et preuves à demander
PointPreuve à demander
Champ sourceTable ou objet, signification métier et propriétaire de la donnée explicités, sans écriture directe non validée.
TransformationCalcul, conversion d’unité et traitement d’une valeur absente décrits avec un exemple fictif.
ContrôleValidation de format distinguée du rapprochement avec la facture comptable et les règles de l’activité.
ErreurMessage compréhensible, responsable de correction et effet sur les documents déjà préparés précisés.
VersionRéférence technique, configuration et cas de régression conservés ensemble pour tester les évolutions.

Livrable attendu

Le livrable est un dictionnaire de mapping accompagné de jeux fictifs et de résultats de recette. Faites signer les règles métier par leur propriétaire et les transformations par le responsable technique. Ajoutez les champs non disponibles, leur mode de collecte et les limites de l’automatisation. Le candidat doit expliquer les enrichissements nécessaires et leur coût d’entretien. Une règle dépendant d’une saisie manuelle quotidienne doit apparaître comme telle dans le dossier remis à la DAF.

Sources