Tronc commun · Facturation electronique
La facture electronique, obligation partagee.
La reforme impose de recevoir des factures electroniques structurees dès septembre 2026, d'en emettre ensuite. Un chantier reglementaire commun aux deux produits, bati sur un socle tronc : formats, statuts, et raccordement a une plateforme agreee.
Note de l'editeur
Contrairement aux autres chantiers, celui-ci n'est pas un choix : c'est une obligation legale avec une echeance. La bonne nouvelle, c'est que les deux produits sont deja partiellement prets — Anim'Gest est avance, et le schema de Cockpit'Gest porte deja les colonnes dormantes de la reforme. On cable un socle commun, on branche une plateforme, on respecte le calendrier.
L'obligation, en clair
Recevoir des factures electroniques structurees devient obligatoire pour toutes les entreprises assujetties a la TVA.
La reforme (RFE) remplace la facture papier ou le PDF simple par une facture structuree — des donnees lisibles par les logiciels, transmises via une plateforme agreee. Un PDF envoye par e-mail ne sera plus une facture conforme entre entreprises francaises. Deux echeances : reception obligatoire pour tous au 1er septembre 2026, emission par etapes (grandes entreprises 2026, TPE/PME 2027).
Pour la cible de No Sage's Editor (TPE/PME), cela signifie : recevoir des e-factures dès 2026 (V1 de ce chantier), emettre ensuite (V2). Le non-respect expose a une amende par facture — l'enjeu est donc concret et date.
Les trois briques de la reforme
Toute solution conforme repose sur trois piliers :
- Le format structure — Factur-X (hybride PDF + XML), UBL ou CII, conformes a la norme europeenne EN 16931. Factur-X est le plus accessible : un PDF lisible avec un XML embarque ;
- La plateforme agreee (PA, ex-PDP) — l'intermediaire obligatoire qui transmet la facture au destinataire et les donnees a l'administration. Chaque entreprise designe la sienne ;
- Le e-reporting — la transmission a l'administration des donnees de transaction et de paiement, pour les operations hors e-invoicing (B2C, international).
Point d'architecture cle : la solution ne parle pas a toutes les PA, elle se raccorde a la PA choisie par chaque tenant (Pennylane pour l'un, SuperPDP pour l'autre...). D'ou la necessite d'une abstraction PA : une interface commune, des adaptateurs par plateforme.
Les deux produits
Anim'Gest est le plus avance ; Cockpit'Gest a deja anticipe dans son schema. La cible est un socle commun.
Anim'Gest · avance
Deja engage
Anim'Gest a deja avance sur l'e-invoicing (statuts, format). Il sert de reference d'experience.
- Socle e-invoicing amorce (a constater INV)
- Experience du format structure
- Compta en procedure stockee : point d'attention
Cockpit'Gest · pret dans le schema
Colonnes dormantes en place
Le schema facture de Cockpit porte deja les champs de la reforme, poses mais non cables.
- FAC_RFE_STATUT (cycle e-invoicing)
- FAC_FORMAT_ELEC (PDF/FACTURX/UBL/CII)
- FAC_SIREN_CLIENT, FAC_CAT_OPERATION, FAC_TVA_DEBITS
Ni l'un ni l'autre ne part de zero. L'enjeu : ne pas dupliquer deux implementations, mais converger vers un module tronc (format, statuts, abstraction PA) que les deux produits consomment. Anim inspire, Cockpit cable ses dormantes sur le meme socle.
V1 — Reception (echeance 2026)
La premiere obligation, universelle : savoir recevoir une e-facture.
Recevoir une facture Factur-X (ou UBL/CII) via la PA du tenant, en extraire les donnees structurees (le XML fait foi), les presenter pour validation, et alimenter la comptabilite. C'est le pendant entrant : la ou A1/A2 (Achats) traitent BL et factures papier par OCR, la RFE traite la facture nativement structuree — pas besoin d'OCR, le XML est deja exploitable.
Lien avec les Achats : une e-facture recue rejoint le rapprochement de A2 (facture d'achat vs BL vs commande). La RFE fournit la facture structuree ; A2 la rapproche. Les deux chantiers se rejoignent sur la facture fournisseur.
V2 — Emission (echeance 2027)
Emettre ses factures de vente au format structure, via la PA.
Generer la facture de vente en Factur-X (PDF/A-3 + XML EN 16931), avec les nouvelles mentions obligatoires (categorie d'operation, option TVA sur les debits, SIREN client), et la transmettre via la PA du tenant. Le cycle de statuts e-invoicing (deposee, transmise, acceptee, refusee...) suit la facture — precisement ce que porte FAC_RFE_STATUT.
Les colonnes dormantes de Cockpit (FAC_FORMAT_ELEC, FAC_PA_REF, FAC_PA_DATE, FAC_RFE_STATUT) sont exactement les receptacles de ce flux. V2 les cable.
L'abstraction Plateforme Agreee
Le point d'architecture qui evite le piege du couplage a une seule PA.
Chaque tenant choisit sa plateforme (Pennylane, SuperPDP, ou une autre agreee). La solution ne doit donc pas etre couplee a une PA unique, mais offrir une interface commune avec des adaptateurs par plateforme. La PA active est un parametre du tenant.
Tronc commun
L'interface PA
- Contrat abstrait : emettre / recevoir / statut
- Modele de facture structuree (EN 16931)
- Generateur / parseur Factur-X
- Cycle de statuts e-invoicing
Adaptateurs (par PA)
Le raccordement
- Adaptateur Pennylane (API)
- Adaptateur SuperPDP (API)
- Autres PA agreees, ajoutables
- Config PA active par tenant
Ainsi, ajouter une PA = ecrire un adaptateur, sans toucher au coeur. C'est la meme discipline que le seam Eliot : un coeur agnostique, des adaptateurs a la peripherie.
Regles de gestion
- Le XML fait foi — pour une facture structuree, les donnees exploitees sont celles du XML, pas du rendu PDF. Le PDF est l'affichage humain.
- Conformite EN 16931 — toute facture emise est validee contre la norme avant transmission ; une facture non conforme est rejetee par la PA.
- Abstraction PA — aucun couplage a une plateforme unique ; interface commune, adaptateurs par PA, PA active configurable par tenant.
- Validation humaine a la reception — une e-facture recue est presentee pour controle avant imputation comptable, comme tout document entrant.
- Mentions obligatoires — categorie d'operation, option TVA sur debits, SIREN client, adresse de livraison si differente : posees a l'emission (V2).
- Archivage — la facture structuree (PDF/A-3) est archivee en GED, format concu pour l'archivage long terme.
- Logique versionnee — generation/lecture du format et imputation vivent dans du code versionne, jamais dans une procedure stockee (regle commune).
INV prealable — bloquant des deux cotes
Anim'Gest etant avance, son INV est surtout un constat de l'existant a consolider ; Cockpit, un constat des dormantes a cabler.
INV Anim'Gest · existant
Dans le projet dedie
- Etat du socle e-invoicing (statuts, format)
- Raccordement PA deja amorce ?
- Generation Factur-X existante ?
- Impact procedure stockee (compta)
INV Cockpit'Gest · dormantes
CC-READ, base de dev
- Colonnes FAC_RFE_* : etat, valeurs ENUM
- Point de cablage a l'emission
- GED pour archivage PDF/A-3
- Config tenant pour la PA active
Le RECAP oriente la convergence tronc : ce qui est agnostique (format, statuts, interface PA) se leve ; ce qui est produit (imputation, config) se reinstancie. Aucun build avant ces constats.
Ce que l'INV Cockpit a revele (v1.1)
Un inventaire read-only du code Cockpit a corrige deux hypotheses de la v1.0. A lire avant tout build.
1. Les colonnes dormantes servent l'EMISSION, pas la reception. Les 7 champs FAC_RFE_* vivent sur la facture de vente (statuts DEPOSEE_PDP / TRANSMISE / ACCEPTEE... prets, mais 0 cablage). Ils preparent la V2 emission, pas la V1 reception. La V1 ne s'appuie donc PAS dessus.
2. Cockpit ne genere aucun PDF de facture aujourd'hui. Aucune librairie PDF, aucune impression de facture (le FEC est un simple .txt). Or un Factur-X est un PDF/A-3 porteur d'un XML. Il manque donc, cote emission, un prerequis : savoir generer un PDF de facture avant d'y embarquer le XML structure.
Deja la (appui)
Sur quoi s'adosser
- GED reutilisable : mime application/pdf deja accepte -> archive un PDF/A-3 sans modif
- SIREN client derivable de tiers.TIE_SIRET (si renseigne)
- Categorie operation derivable de ART_TYPE (partiel : lignes libres indeterminees)
- Dormantes RFE typees, pretes pour l'emission (V2)
Greenfield (a batir)
Ce qui part de zero
- Generation PDF de facture (prerequis emission, inexistant)
- Parseur / generateur format structure (Factur-X/UBL/CII)
- Connecteur PA + config PA du tenant
- Facture fournisseur entrante (depend d'Achats A2)
- Adresse de livraison, option TVA debits (mentions manquantes)
Consequence sur les dependances : la V1 reception a besoin d'une table facture fournisseur entrante — qui viendra du chantier Achats A2. La V2 emission a besoin d'un generateur PDF de facture prealable. Aucune des deux n'est autonome : chacune a un prerequis revele par l'INV.
Sequencement (recadre)
Ordre propose, dependances integrees
| Etape | Objet | Depend de |
|---|---|---|
| Pre-V1 | Achats A2 : facture fournisseur entrante (table + rapprochement) | Achats A1 |
| V1a | Socle format : parseur Factur-X/UBL/CII + modele EN 16931 | - |
| V1b | Reception : interface PA + adaptateur Pennylane + validation | A2 + V1a |
| V1c | 2e adaptateur PA (SuperPDP) : prouver l'abstraction | V1b |
| Pre-V2 | Generateur PDF de facture (inexistant aujourd'hui) | - |
| V2 | Emission : generateur Factur-X + mentions + statuts + transmission PA | Pre-V2 + V1a |
La reception (V1) reste prioritaire pour l'echeance 2026, mais elle s'enchaine apres Achats A2 (qui porte la facture fournisseur recue). L'emission (V2) reste 2027, mais exige d'abord un generateur PDF de facture. Le socle format (V1a) et l'interface PA sont communs aux deux versions et se levent une fois.
Une obligation legale transformee en socle commun.
La reforme impose un calendrier ; No Sage's Editor y repond par un module tronc : formats structures, cycle de statuts, et une abstraction plateforme qui accueille Pennylane, SuperPDP et les autres. Anim'Gest apporte l'avance, Cockpit'Gest ses colonnes dormantes ; les deux convergent vers un socle unique, cable une fois, conforme partout.