Le moteur de mapping & validation

1. Le mapping des champs

Pour chaque module (TVA, liasse fiscale, taxe professionnelle…), une table de correspondance associe un champ Excel à un champ XML. Cette correspondance ne se limite pas à un simple renommage : chaque entrée du mapping porte des attributs techniques propres au format DGI :

• champ Excel — la colonne ou la cellule source dans votre classeur ;
• champ XML — le nom du champ correspondant dans le fichier généré ;
• type de champ — texte, numérique, date, montant… ;
• caractère obligatoire — si le champ doit impérativement être renseigné ;
• valeur par défaut — utilisée si la cellule source est vide ;
• code tableau / code modèle — les identifiants du tableau et du modèle DGI concernés ;
• nombre de caractères — la longueur maximale attendue par la DGI pour ce champ ;
• feuille / code ligne / code ligne XML — la position exacte de la donnée dans le classeur Excel et dans la structure XML cible.

Ce niveau de détail est ce qui permet de générer un fichier dont la structure correspond fidèlement au modèle attendu par la DGI, plutôt qu'un simple export XML générique.

2. Les règles de validation

Avant génération, chaque valeur est contrôlée par les règles de validation définies pour son champ : caractère obligatoire, format attendu, valeurs autorisées, etc., chacune associée à un message d'erreur explicite. Ces règles sont compilées puis mises en cache pour ne pas être recalculées à chaque traitement, et peuvent s'appuyer soit sur une configuration par défaut, soit sur des règles propres au module stockées en base — ce qui permet d'ajuster une règle sans modifier le code de l'application.

Si une donnée ne respecte pas une règle, le traitement s'arrête avant génération et remonte le détail de l'erreur, plutôt que de produire un fichier XML structurellement correct mais fiscalement invalide.

3. Le remplacement de valeurs

Une donnée peut être valide dans votre Excel (un intitulé courant, une mention en clair) sans correspondre au code exact attendu par la DGI. Une table de remplacement de valeurs, propre à chaque module, associe la valeur telle qu'elle est saisie (« donnée saisie ») à la valeur normalisée attendue (« donnée de remplacement »), et peut être activée ou désactivée entrée par entrée. Ce mécanisme évite d'imposer une saisie rigide en amont : c'est l'application qui absorbe l'écart entre votre façon de saisir et le code attendu par la DGI.

4. La génération du fichier

Une fois le mapping appliqué, les données validées et les valeurs normalisées, le fichier XML est généré et associé à un enregistrement de suivi (fichier source, statut, dates de traitement, nombre de tentatives). En cas d'échec, le fichier peut être retraité sans nouveau téléversement, et un accusé de réception DGI peut ensuite être rattaché une fois le dépôt effectué.

Pourquoi ce découpage en trois étapes

Séparer mapping, validation et remplacement de valeurs en trois mécanismes distincts, propres à chaque module et modifiables indépendamment, permet d'ajuster une déclaration précise (par exemple un changement de longueur de champ ou l'ajout d'un code DGI) sans toucher aux autres modules ni au code de génération lui-même.