Annexe B — Mapping des données réglementaires (Flux 1) vers CII

Table de correspondance complète entre les données réglementaires du Flux 1 (e-invoicing) et les chemins CII, avec l'état de couverture par Facturx.CII.

• Source : Annexe 1 — Format sémantique FE e-invoicing — Flux 1 — v1.2 (onglet « FE - Flux 1 - CII »), spécifications externes B2B v3.2 du 30/04/2026, publiées par la DGFiP. Voir Annexe A pour la provenance exacte et la méthode de vérification.
• Card. : cardinalité sémantique PPF. 1..1 / 1..n = donnée obligatoire.
• Traj. : trajectoire — D = DEMARRAGE (exigé dès l'entrée en vigueur), C = CIBLE (échéance ultérieure).
• Émis : ✅ = produit par Facturx.CII.build/2 ; — = non produit à ce jour.

Les chemins sont reproduits depuis l'annexe. Seule correction apportée : une parenthèse fermante orpheline après certains @format (coquille de la source).

Couverture complète, et à quelle condition

Les 116 données sont émises. Il n'y a plus de ligne —.

Mais 20 d'entre elles — les 19 extensions françaises EXT-FR-FE-* et le conteneur de note de ligne BT-127-00 — n'existent qu'en profil :extended. Elles ne font pas partie de l'EN 16931, dont le XSD rejette tout élément hors profil ; c'est pourquoi le XSD EXTENDED est embarqué en plus (priv/xsd/extended/), avec son schematron.

Concrètement : Facturx.build(inv, profile: :extended) produit les 116 données, Facturx.build(inv) en produit 96 et laisse tomber les 20 autres — sans erreur, délibérément, plutôt que de fabriquer un document que la plateforme rejetterait.

Ce qu'un profil autorise ne dépend pas de l'appelant. BT-127-00 (note de ligne répétée) et EXT-FR-FE-183 (son code sujet) ne sont émis qu'en :extended ; en EN 16931, Facturx.CII.build/2 ne garde qu'une note et retire le code sujet, plutôt que de produire un document qui serait rejeté. Les lignes ✅ de ce tableau décrivent donc la trajectoire CIBLE.

La colonne Émis est écrite à la main, mais elle n'est plus livrée à elle-même : Facturx.MappingAnnexeTest lit ce tableau et évalue chacun des 116 chemins contre le document produit par Facturx.CII.build/2. Ce qui est vérifié est le nombre d'occurrences, pas la simple présence : neuf chemins sont revendiqués par deux lignes chacun — BT-110 et BT-111 sont tous deux ram:TaxTotalAmount, distingués par leur seul currencyID, et les quatre familles remise/charge par leur seul ChargeIndicator. Un chemin portant moins de nœuds qu'il n'a de lignes cochées, ou un chemin sans ligne cochée qui porte quoi que ce soit, fait échouer la suite.

⚠️ Corollaire : toute donnée nouvellement émise doit être renseignée dans Facturx.TestInvoice.maximal/0, sinon sa ligne apparaît comme une dérive. Le document témoin est construit en :extended, la trajectoire que ce tableau décrit.

Couverture : 116 / 116 données réglementaires émises.