Spécifications externes 2.4

Après une semaine de lecture des plus de 200 pages et des annexes de cette nouvelle version 2.4 , que peut-on dire ?

Tout d’abord, je rappelle qu’il s’agit de Spécifications Externes du PPF, c’est-à-dire d’un document décrivant ce que fait le PPF et comment interagir avec lui, sachant que le PPF a 3 fonctions majeures :

• PPF_Annuaire : gestionnaire de l’annuaire, qui a été revu en profondeur
• PPF_Concentrateur : de données requises par l’Administration fiscale, connecté avec les PDP et le PPF_PDP (cf ci-dessous)
• PPF_PDP : Plateforme de service d’échange de factures et statuts et de collecte du e-reporting, connecté aux utilisateurs du PPF (émetteurs et / ou destinataires) ET aux PDP pour l’interopérabilité (en Circuit C, B1 et B2).

On pourrait même ajouter une fonction particulière PDP_B2G, dans la mesure où les processus B2G diffèrent des processus B2B, notamment dans la gestion du cycle de vie, mais aussi sur la construction de l’Annuaire.

D’ailleurs, une des premières modifications notables est l’affirmation que les factures B2G devront obligatoirement être émises à partir du PPF (Circuit A Obligatoire, cf 3.2.10, haut de page 75).

Par conséquent, si une entreprise privée choisit un prestataire PDP pour émettre ses factures, ce dernier devra se comporter en tant qu’OD pour émettre les factures à destination du secteur public. L’entreprise privée devra donc maintenir son compte ChorusPro en compte PPF et habiliter son prestataire pour qu’il puisse agir en son nom sur le PPF pour émettre et suivre ces factures B2G. Comme il y a environ 1 million d’entreprises privées dans ce cas, ceci impose en pratique à toutes les PDP de disposer d’une offre d’OD en amont de son offre PDP pour servir ces flux.

L’ANNUAIRE

Ensuite, comme annoncé, cette version s’est attachée à redéfinir la gestion de l’Annuaire, qui sera la première composante mise en production fin 2024, accompagnant la mise en place d’une interopérabilité en réseau entre PDP (PEPPOL).

L’Annuaire fournira un référentiel des SIREN assujetti à la TVA (donc pas tous les SIREN) complété des entités publiques, ainsi que les SIRET qui y sont attachés. La présence du SIREN d’une entreprise dans l’annuaire permet de savoir s’il correspond à un assujetti à la TVA (et donc en e-invoicing). Ils sera aussi indiqué si cette structure est privée (B2B) ou publique (B2G). Étant donné que la gestion des entités publiques se fait à l’échelle SIRET, avec pour certaines, un échelon plus fin donnant lieu à des Codes Services Exécutants, un référentiel additionnel des Codes Routage est aussi fourni. Chaque Code_Routage est obligatoirement attaché à un SIRET, et peut le cas échéant avoir une adresse physique différente de celle du SIRET auquel il est attaché. Il s‘agit là d’un héritage B2G, qui ne s’applique qu’aux entités publiques, car dans le secteur privé, toute nouvelle adresse physique donne lieu à la création d’un établissement et donc d’un SIRET.

Ces Codes Routages, qui à l’origine avaient été conçus pour permettre le choix de différents canaux de réception de factures, donc différentes PDP / PPF, pourront être utilisés par les entités privées pour diversifier leurs adresses de facturation, mais obligatoirement au sein de chaque SIRET.

Enfin, et c’est le plus important, l’annuaire expose un référentiel des Lignes d’adressage, au travers d’identifiants d’adressage qui sont en pratique des Adresses Électroniques. Celles-ci sont de 2 types :

• Soit SIREN_SIRET_CODE_ROUTAGE (Code Service Exécutant pour le secteur public), qui doivent obligatoirement être indexées par le SIRET et le Code_Routage. Ainsi si l’émetteur de la facture omet de renseigner l’adresse électronique de son client dans sa facture, le PPF utilisera le SIREN, le SIRET et le Code_routage présents dans la facture pour trouver une adresse qui convient.
• Soit SIREN_SUFFIXE, ce suffixe étant aussi un index de cette adresse qui alors n’EST PAS rattachée à un SIRET ou un CODE_ROUTAGE. Ainsi, lorsque l’entreprise souhaite disposer de plusieurs adresses électroniques de facturation, soit pour distinguer certains types d’achat (achats de Media, achats de Production, achats de frais généraux, achats confiés à une centrale d’achat, factures de ventes en Autofacturation, …), soit pour alimenter différents systèmes de gestion (par activités, suite à une acquisition, …) et le cas échéant choisir différentes PDP / PPF.

Dès lors que les factures renseignent bien l’adresse électronique du destinataire sous cette forme, ce qui sera obligatoire pour l’interopérabilité entre PDP, ce second mode est le plus adapté aux besoins des entreprises.

Au démarrage deux adresses électroniques seront créées :

• L’adresse SIREN
• L’adresse SIREN_SIRETPrincipal

Ensuite l’entreprise pourra en créer d’autres et / ou en fermer l’une de ces deux. Ceci sera toujours fait en pratique par la ou les PDP ou le PPF choisies par l’entreprise. Par contre, cela fait 2 adresses là où la plupart des PME en utiliseront une seule avec le risque que ces dernières n’aient pas conscience d’avoir 2 adresses à relever. Dans un second temps, seule l’adresse SIREN sera créée à l’initialisation, normalement (d’après les discussions en cours avec l’équipe projet).

En consultant cette partie de l’annuaire les vendeurs pourront connaître les adresses électroniques actives utilisables pour un SIREN donné, et la PDP / PPF en charge de l’émission y trouvera le matricule de la PDP / PPF destinataire.

Enfin, pour cette partie annuaire, un Swagger a été publié pour les échanges en mode API, ainsi l’xsd des 3 messages à utiliser ainsi qu’un exemple pour chacun d’eux.

LE CYCLE DE VIE

Cette version 2.4 a aussi donné plus de détail sur le Cycle de vie, à la fois sur l’utilisation du message CDV (UN/CEFACT CDAR), mais aussi au travers de nombreux ajouts de schémas décrivant la cinématique des statuts, en fonction des Circuits et des canaux (EDI, API, Portail).

Pour le PPF, les factures ont toujours un seul statut courant, ce qui impose une certaine chronologie. C’est assez naturel pour les statuts de la phase transmission (de « Déposée » à « Mise à Disposition »), pour les suivants, il peut y avoir des boucles (par exemple « Suspendu », « Complétée », « Prise en Charge », … “Encaissée” qui peut apparaître au début de cycle en cas de facture déjà payée). Les statuts dits « Obligatoires » restent les mêmes : « Déposée », « Rejetée » pour lequel il faut distinguer un Rejet à l’émission (donc pour une facture non émise), d’un Rejet en réception, « Refusée » et « Encaissée » (quand facture à l’encaissement).

Mais tous les autres statuts seront aussi gérés par le PPF, qui a décidé d’utiliser les messages Cycle de Vie pour confirmer tout échange de fichier, voire l’annoncer avec les statuts Déposée et Emis qui seront transmis en parallèle des flux 2 et flux 1. Un message Cycle de Vie est lui-même confirmé en retour par un autre message cycle de vie.

Comme en canal EDI il s’agit de transmettre des fichiers par blocs (ce qui est appelé «flux»), il y a aussi des CDV pour confirmer la bonne réception de ce flux, ou le déclarer IRRECEVABLE si l’un de ses éléments n’est pas conforme au format attendu. Il faudra alors rejouer tout le flux. Une fois reçu et découpé en “Objets Métiers” (par exemple en factures), le traitement devient unitaire.

Le statut « Refusée » est confirmé dans sa conséquence, à savoir une annulation de la TVA de la facture qui en est l’objet avant qu’un avoir ne soit transmis. Il est alors TRÈS IMPORTANT que ces factures « Refusées » soit TOUJOURS traitées de la même façon, c’est-à-dire comme un REJET : pas de comptabilisation coté destinataire et un AVOIR INTERNE non transmis coté émetteur, ce qui n’est pas encore exprimé clairement et uniformément dans cette version 2.4.

Il en résulte aussi une restriction des motifs de REFUS, pour éviter tout abus puisqu’un Refus implique une annulation de facture et une nouvelle facture (avec potentiellement un décalage de date d’échéance), normalement uniquement pour erreur de destinataire (émetteur inconnu) ou facture non conforme réglementairement, voire contractuellement.

Ce point reste encore à être clarifié car il reste indiqué (dans certains cas d’usage) que des factures pourraient être Refusées pour raison métier alors que c’est un cycle de Litige ou Approbation partielle avec demande d’Avoir ou de Facture Rectificative qui doit alors être mis en œuvre.

La difficulté est ici que la pratique actuelle B2G est de refuser des factures qui n’ont qu’un litige commercial. De plus, les motifs de refus ou de litiges sont pour l’instant ceux du B2G, qui ne sont pas adaptés aux pratiques B2B et doivent être adaptés (discussions en cours avec le groupe Co-Construction).

Pour finir sur ce sujet, en annexe 2, deux matrices ont été ajoutées, une pour décrire quels acteurs peuvent poser quels statuts, et une autre décrivant quels statuts peuvent être suivis par quels statuts. Il faut d’ailleurs retenir de cette seconde matrice les impossibilités (croix rouge), comme par exemple que rien ne peut arriver après un statut “Refusée” ou “Rejetée” (lecture en colonne de la matrice) et rien ne précède un Statut “Rejetée à l’émission” ou “Déposée” (lecture en ligne de la matrice).

LE LISIBLE

Cette version précise aussi la gestion du LISIBLE pour des factures structurées (UBL, CII ou formats tiers), sachant que Factur-X dispose déjà d’un lisible par essence.

Pour ce faire, l’émetteur peut ajouter une Pièce Jointe, qui doit être qualifiée de « LISIBLE », ce qui signifiera qu’il s’agit de la représentation lisible réglementaire (contenant toutes les informations du fichier structuré de facture). Le destinataire pourra alors l’utiliser comme la version LISIBLE dont il doit disposer si nécessaire.

Il sera aussi possible de référencer une feuille de style, que le destinataire pourra exécuter sous sa responsabilité pour disposer d’une présentation lisible de sa facture. Par contre, au titre de son obligation de fournir une présentation lisible, le PPF n’exécutera que sa propre feuille de style commune pour toutes les factures (car c’est la seule dont il peut garantir qu’elle présente effectivement toutes les informations de la facture, en toute intégrité).

Il résulte aussi de cette obligation le fait que le PPF n’acceptera pas de factures relevant de profils plus larges que le profil EXENDED-CTC-FR décrit en annexe 1, parce qu’il ne sera pas en capacité d’en fournir une représentation lisible complète.

LES FORMATS DU SOCLE

La notion de format du socle minimal est précisée au travers de l’annexe 1, qu’il faut bien lire comme étant en fait 2 profils :

• Un profil EN16931, correspondant à toutes les données, à l’exclusion de celles commençant par « EXT »
• Un profil EXTENDED-CTC-FR, correspondant à toutes les données décrites en annexe 1, avec parfois des variations de cardinalité (par exemple BT-46 qui sert à renseigner le SIRET et le CODE_ROUTAGE de l’acheteur ne peut être présente qu’une seule fois dans le profil EN16931, mais autant de fois qu’on veut dans le profil EXTENDED-CTC-FR : encore une bonne raison d’utiliser l’adresse électronique à la place pour rester dans le profil EN16931). Ce profil remplace aussi quelques règles de gestion par d’autres, notamment pour introduire une tolérance de calcul de 1 centime par ligne de facture ou remise ou charge de niveau document, pour faire face à la fois aux logiciels qui calculent la TVA à la ligne au lieu de le faire en pied, ou pour les factures B2C qui sont en général calculées sur la base de Prix Unitaires TTC.

A noter que Factur-X dispose d’un profil étendu beaucoup plus large (EXTENDED), qui sera accepté puisque, par construction, le LISIBLE est fourni et n’a donc pas à être créé par le PPF ou toute PDP.

A ceci s’ajoute, pour une période transitoire dont le terme sera connu lors de l’arrêté à venir (complétant le précédent), des profils autorisant une sous-partie des mentions obligatoires sous forme structurée (phase dite “DEMARRAGE” versus “CIBLE” : les données d’entête et pied uniquement), avec le profil BASIC_WL de Factur-X, et un profil dédié au dépôt de PDF avec extraction de flux 1 « super réduit » pour créer un Factur-X avec seulement ce flux 1, dénommé alors profil « Key ».

LES CAS D’USAGE

Cette version vient préciser quelques points sur les cas d’usage et en particulier modifier les cas d’usage 13 (sous-traitance) et 14 (co-traitance).

Le cas n°11 (transmission à un “Facturé À” s’il est présent dans la facture ET présent dans l’Annuaire et qu’il ne s’agit pas d’une facture en autofacturation, est maintenu. L’utilisation de ce cas n°11 en l’état permet de dérouter les factures vers un tiers, sans que l’acheteur la reçoive, toute la question étant de savoir si l’acheteur en a pleine conscience.

Pour rappel, il est en pratique préférable d’utiliser la capacité à dédier une adresse de facturation qui sera confiée en gestion et traitement à ce tiers pour qu’il traite la facture pour le compte de l’acheteur. De cette façon, l’acheteur reste maître de ses adresses et peut choisir pour elle une PDP en capacité de partager son traitement entre lui et le tiers à qui il souhaite en confier la gestion.

Pour résumer, les cas d’usage peuvent nécessiter l’utilisation du profil EXTENDED-CTC-FR pour ajouter des données, et en particulier des tiers (PAYEUR, AGENT D’ACHETEUR, AGENT DE VENDEUR, FACTURANT, FACTURÉ À). Les statuts d’encaissement (pour facture de service sans option pour les débits) doivent TOUJOURS faire l’objet d’un statut encaissé, même s’il s’agit d‘une facture “déjà payée”, au moment où le fournisseur peut constater que la facture a été effectivement payée par l’acheteur (donc en cas d’affacturage, c’est quand l’acheteur règle la facture et pas quand le fournisseur en obtient un règlement du fait de l’affacturage).

Le PPF ne traite en émission et en réception que des factures relevant strictement du e-invoicing. Ainsi, par exemple, si une facture est hors score TVA (comme une facture de débours), elle ne sera pas transmise par le PPF à son destinataire, même si l’émetteur et le destinataire sont assujettis tous les deux.

Et pour le reste, il s’agit d‘appliquer les règles en matière de TVA déjà en vigueur depuis plus de 2 décennies (et le document cas d’usage est certainement une bonne opportunité pour beaucoup d’en prendre conscience).

LE E-REPORTING

Certains pourraient considérer que rien de plus n’est dit sur le e-reporting. Ce n’est pas faux. Mais c’est surtout parce qu’il n’y a pas grand-chose à dire de plus du point de vue des spécifications externes du PPF. En effet, celui-ci (tout comme les PDP) collecte des éléments déclaratifs, soit unitaires depuis ses utilisateurs (Flux 10, voire flux 8 ou 9), soit directement sous forme de flux 10 groupé (depuis ses utilisateurs ou depuis les PDP).

Pour rappel, les flux 8 et 9 devaient correspondre aux factures transmises par ailleurs à leur destinataires, confiées au PPF pour qu’il en extrait les données requises (le flux 10.1), puisque le PPF ne transmet, ni n’accepte en réception des factures électroniques hors du périmètre e-invoicing de la réforme.

A noter toutefois qu’en l’état des spécifications, les flux 8 et 9 tels que décrits ne correspondent pas exactement aux factures transmises par ailleurs aux destinataires. Des modifications sont en effet nécessaires. Il sera alors probablement plus simple de directement fournir des extraction 10.1, qui sont semblables au flux 1 de la partie e-invoicing.

Ensuite, le PPF constitue le flux 10 complet, qu’il transmet à la DGFIP (ou transmet tel quel celui qu’il reçoit des PDP).

La seule précision additionnelle est le fait de séparer les flux 10 relatifs aux encaissements, qui sont transmis de façon indépendante.

Ensuite, la complexité est chez les utilisateurs (les entreprises), pour produire les données de facturation sur ventes B2B internationales (depuis le système de facturation), les données de vente B2C, notamment provenant des logiciels de caisses, et, je le rappelle, les données de facturation sur acquisition internationales hors import de biens, pour lesquelles il sera demandé les mêmes informations que pour le flux 1 (toutes les mentions obligatoires), sur des factures dont un certain nombre resteront non structurées. Il faudra donc extraire et contrôler (l’OCR retrouvera son utilité ici).

LES RÈGLES DE GESTION

L’annexe 7 décrit l’ensemble des règles de gestion qui s’appliquent aux différents messages et flux. On y trouve beaucoup de correction, soit de formulation, soit de correction. La conséquence est surtout sur les composants de contrôle des différents flux, qui de toute façon ne sont pas encore produit.

Il s’agit d’ailleurs là d’un sujet : peut on avoir des composants communs de contrôle, voire de production de lisible, pour minimiser les rejets et différence d’interprétation des spécifications.

ET LA SUITE ?

Tout d’abord, il reste des petites imprécisions, et des corrections à faire dans certaines annexes, qui normalement devaient faire l’objet de corrigendum pendant l’été (en tout cas, je l’espère).

L’autre difficulté tient à la richesse des documents, qui peut laisser penser à une complexité de la réforme. Il est important de bien faire la différence entre les impacts pour les utilisateurs et ceux pour les PDP et les OD, et de veiller à respecter un cadre de principes simples et en faible nombre à respecter toujours. On y est presque, mais pas encore formulé de cette façon.