Les ESSENTIELS de la Réforme – #3 Cycle de Vie

Cyrille Sautereau

I            Parce que ça devrait rester simple !

1        Un peu de vocabulaire commun « universel »

La description des échanges de factures et du cycle de vie constitue une part importante des spécifications externes, notamment parce qu’ils sont déclinés par circuit (A, B1, B2, assez peu en C puisque ça ne concerne pas le PPF), et même parfois par canal (EDI, API, Portail). De plus, les spécifications sont centrées sur les besoins ou choix du PPF vis-à-vis des entités qui lui sont connectées sans forcément distinguer si ce sont des utilisateurs (ou leur représentants OD), ou si ce sont des PDP dans le cadre de l’interopérabilité.

Pour y voir plus clair, il est nécessaire de rappeler qu’on se situe dans un cadre d’échange interopéré à 4 coins auxquels s’ajoute le PPF en tant que collecteur de données pour la DGFIP (qu’on nommera PPF-Collecteur, versus PPF-PDP, sans oublier la troisième fonction PPF-Annuaire).

Ainsi, on appellera dans cet article les différents acteurs de l’échange des factures de la façon suivante :

  • C1 (Coin 1) : l’Émetteur de la facture, c’est-à-dire en général le Vendeur (mais ça peut être l’acheteur en cas d’autofacturation). Il peut arriver qu’un tiers émette la facture pour le compte du Vendeur (par exemple un « Facturant » sous mandat. Il sera assimilé à C1.
  • C2 (Coin 2) : la Plateforme de l’émetteur, en charge de transmettre la facture (et d’effectuer les contrôles). Dans notre contexte, c’est la PDP de l’émetteur ou le PPF-PDP s’il a choisi le PPF. Normalement, les traitements devraient être identiques que ce soit une PDP ou le PPF.
  • C3 (Coin 3) : la Plateforme du destinataire, en charge de recevoir la facture pour le compte du destinataire. C’est en général l’acheteur (le Vendeur en cas d’autofacturation). Il peut arriver que ce soit un tiers (par exemple un « Adressé à » dans le cadre de la réforme).
  • C4 (Coin 4) : le Destinataire de la facture.
  • C5 : avec les réformes CTC qui se déploient dans le monde, on a coutume de nommer C5 la Plateforme de l’Administration en charge de collecter les données requises. Ici, c’est donc le PPF-Collecteur.

Il convient aussi alors de bien distinguer dans une Plateforme de services ce qui relève de l’échange de factures et statuts de ce qui relève de la préparation en amont ou du traitement en aval, qui sont des fonctionnalités d’OD.

2        Cycle de vie : Transmission, Traitement et Paiement des factures.

Ceci étant posé, les échanges de factures et statuts se passent de la façon suivante.

2.1        Phase Transmission :
  • C1 prépare sa facture, dans un format du socle minimal (Flux 2)ou un format tiers convenu avec son client (Flux 3). Il peut se faire aider par son OD (par exemple pour transformer un ensemble de données de facturation en facture).
  • C1 transmet sa facture à C2. Cette transmission peut se faire suivant divers canaux, y compris la saisie en ligne. En canal API, il peut s’agir d’un simple dépôt d’une facture constituée, ou bien d’une transmission de données, le cas échéant avec des Pièces Jointes dont une présentation LISIBLE, conduisant ensuite à la création d’une facture électronique sous mandat de facturation. En canal EDI, cette transmission peut se faire (et doit se faire avec le PPF) sous forme de paquets (de batch) de plusieurs factures, ce qui ajoute une étape de groupage / dégroupage. Dans les spécifications externes, ces batch sont appelés « Flux », ce qui peut porter à confusion avec les objets métiers que sont les Flux 1, 2, …). Il faut donc comprendre en fonction du contexte.
  • C2 reçoit la facture, puis effectue ses traitements de contrôles. En canal EDI, il y a une phase de dégroupage pour arriver à des factures unitaires à traiter. Si la facture est jugée conforme, C2 crée un statut « Déposée » qu’il transmet à C3 pour C4 et à C5 (PPF-Collecteur), tout en le mettant à disposition de C1. De même, si la facture n’est pas conforme, C2 transmet un statut « Rejetée (à l’émission) » à C5n statut qui est aussi mis à disposition de C1 (et donc non transmis à C3 et C4). Si la facture est « Déposée » C2 doit transmettre un flux 1 à C5.
  • C2 transmet la facture à C3, après l’avoir trouvé grâce à l’Annuaire et l’interopérabilité.

  • C3 reçoit la facture et effectue des contrôles, qui peuvent conduire à un statut « Rejetée » transmis à C4, C5 et C2 (et disponible pour C1). Sinon, il pose un statut « Reçue », transmis à C2 et disponible pour C4. Il notifie C4 de la réception d’une facture (statut « Mise à Disposition »), et transmet ce statut à C2 pour C1.
  • C3 transmet la facture à C4 (ou C4 vient récupérer sa facture chez C3).

 

Quand il arrive que C2 est aussi C5, la notion de transmission entre C2 et C5 est interne au PPF. Nous sommes dans le circuit B1.

Exception quand le PPF est C3 (Circuit B2) : pour l’instant si le PPF est C3 (et pas C2), c’est lui qui extrait le Flux 1 SAUF s’il Rejette la facture (dans un traitement de réception donc). Ceci contrevient au fonctionnement normal, ce qui oblige C2 à ne pas transmettre de flux 1 et au PPF de gérer le fait que parfois il y aura un flux 1 et un statut « Rejetée », et parfois (quand c’est le PPF qui intervient en C2 ou C3), il y aura un statut « Rejetée » et pas de flux 1.

Heureusement, c’est assez transparent pour les utilisateurs finaux :

  • Si une facture est rejetée, on oublie le flux 1 correspondant.
  • L’émetteur (C1) annule sa facture et en refait une.
  • Le Destinataire (C4) ignore cette facture si C3 l’a reçue ou ne la reçoit pas (ce qui le conduit de fait à l’ignorer aussi).

Si C2 est aussi C3 et C5, et donc le PPF, on est en circuit A.

 

Pour résumer, la règle est donc simple :

  • Les Plateformes C2 et C3 servent de pivot pour la transmission des factures.
  • Elles créent les statuts de transmission qui sont chronologiques (Déposée ou Rejetée, Émise, Reçue ou Rejetée, Mise à Disposition), et les mettent à disposition de leur clients respectifs tout en les transmettant à l’autre Plateforme (C2 à C3 et C3 à C2).
  • C2, Plateforme de l’émetteur transmet le flux 1 à C5 (PPF-Collecteur) uniquement si statut « Déposée », avec pour seule exception malheureuse quand C3 est le PPF-PDP (Circuit B2).
  • C2 et C3 transmettent au PPF-Collecteur (C5) les statuts dits « Obligatoires » parce qu’ils ont un impact sur la TVA : « Déposée » veut dire qu’il y aura un flux 1 et une TVA à déclarer. « Rejetée » veut dire qu’il n’y aura pas ou plus de TVA à déclarer, sachant qu’il faut distinguer « Rejetée à l’émission» (par C2), qui a pour conséquence qu’il n’y a pas de flux 1, de « Rejetée » (en réception), qui signifie que la DGFIP va « annuler » le flux 1.

Vu des Utilisateurs (C1 et C4) :

  • C1 transmet sa facture à C2 et dispose en retour de tous les statuts de transmission. Si la facture est Rejetée, il doit l’annuler en interne (sans la transmettre), et en refaire une nouvelle.
  • C4 reçoit sa facture si elle est conforme (donc si elle n’est pas « Rejetée »), et dispose de tous les statuts de transmission. Il peut savoir si une facture est « Rejetée » en réception, pour information car elle ne doit pas être comptabilisée par C4 normalement.

Il faut noter que dans cette phase de transmission, même s’il y a un ordre chronologique théorique, rien ne garantit que les différents flux vont suivre cet ordre dans les échanges. Il peut en effet y a voir des séquençages différents entre PDP / PPF (tout n’est pas forcément au fil de l’eau). Il peut y avoir des groupages / dégroupages, qui introduisent des désynchronisations. Par conséquent, les PDP et le PPF doivent gérer le fait qu’il arrivera que des statuts arrivent avant les factures ou le flux 1, et que des statuts « Emise » pourraient arriver avant les statuts « Déposée ». Ceci ouvre quelques questions néanmoins : par exemple, que faire lorsque l’on reçoit une facture (un Flux 2) parfaitement conforme, et donc pour lequel on transmet un statut « Reçue », mais pour laquelle on n’a pas reçu de statut « Déposée ».

Lorsque l’on parlera de message et d‘interopérabilité, dans le monde PEPPOL « standard », il existe un message spécifique à cette phase : le MLR, pour Message Level Response, qui permet d’indiquer coté Émetteur qu’un accusé de réception est requis (disons que ça ressemble au « Emise » ou « Déposée »), puis d’indiquer coté destinataire que la facture est « Rejetée » ou « Acceptée », « Acceptée » signifiant « non Rejetée » et pas « Approuvée ». Le CDAR choisit par le PPF et que les PDP devront savoir implémenté permet de coller strictement au besoin et de gérer à la fois la phase transmission et la phase de Traitement et Paiement.

 

2.2        Phase Traitement, puis Paiement

Une fois la transmission passée, l’Acheteur ne peut plus dire qu’il n’a pas reçu la facture, et le Vendeur le sait. On passe alors à la phase de traitement proprement dite :

    • C4 traite la facture et prépare des statuts de traitement qu’il transmet à C3 (y compris via saisie ou action de C4 directement sur la Plateforme C3).
    • C3 transmet les statuts à C2 qui les transmet ou met à disposition de C1. Si le statut est « Refusée », alors C3 le transmet aussi à C5. C4 a aussi accès à l’ensemble des statuts de la facture, y compris ceux qu’il a lui-même posé, ou qu’un tiers a posé pour son compte au travers de C3.

  • Il peut arriver que C1 souhaite transmettre des statuts à C4 (« Complétée », « Encaissée ») et ceci prend le même chemin que les factures. Si le statut est « Encaissée » pour une facture de service à l’encaissement (n’ayant pas opté pour les débits), C2 transmet ce statut à C5.

 

3        Les statuts de cycle de vie d’une facture

Les statuts disposent d’un motif permettant d’en préciser les raisons. Ces motifs sont répertoriés dans une liste en cours de discussion (car celle qui est listée en annexe 2 est aujourd’hui adaptée au fonctionnement B2G, incompatible avec le fonctionnement classique B2B).

Ce cycle de vie n’a rien de révolutionnaire, et est juste le résultat d’un traitement très standard des factures. Ces statuts de traitement disposent donc d‘un MOTIF, et potentiellement d’une ACTION attendue :

  • 1ère question : est-ce une facture pour le destinataire : la facture est-elle bien conforme à la réglementation et provient-elle d’un fournisseur connu, duquel est attendu une facture parce qu’une prestation ou livraison est en cours ou a été effectuée.
  • Si OUI, il faudrait poser le statut Prise en Charge.
  • Si NON, il FAUT alors Refuser cette facture, c’est-à-dire ne pas la comptabiliser. En cas de Refus, le motif doit en signifier la raison, qui ne peuvent être logiquement que « Émetteur inconnu », « Transaction inconnue », « Contrat terminé », « Numéro de commande incorrect ou manquant », « Erreur de livraison », « Facture en doublon » (si déjà facturé), « Facture non conforme » (erreur de calcul, mention légale absente ou erronée, …). Bref, il s’agit de cas où rien ne justifie qu’il y ait une facture, ce qui est différent du fait de recevoir une facture, et de la contester car elle ne correspond pas à ce qui est attendu.
  • 2ème question : validation :
  • La facture est Approuvée totalement
  • La facture est Approuvée Partiellement, ce qui impose de dire pourquoi partiellement et comment règle-t-on le sujet : soit une demande d’envoi d’avoir partiel, soit une demande de complément (par exemple livraison complémentaire) pour finalement approuver totalement.
  • La facture est Suspendue: le traitement s’arrête, pour de bonnes raisons, à qualifier dans le motif, avec une action attendue.
  • La facture est Complétée, statut réservé à l’Émetteur (C1), normalement en réponse à un statut « Suspendue ».
  • La facture est En Litige: ce qui veut dire qu’elle n’est pas approuvée pour l’instant, et qu’elle ne sera pas payée. Ce statut donne un MOTIF et une ACTION (par exemple demande d’AVOIR ou de FACTURE RECTIFICATIVE). C’est le statut qu’il faut utiliser quand la facture est bien adressée mais en désaccord (et donc PAS LE STATUT REFUSÉE).
  • A NOTER : dans cette phase, on a le droit de se tromper ou de revoir sa position : une facture « Approuvée », peut passer en « Litige » ou l’inverse, une facture « Suspendue » peut repasser el « Prise en Charge » ou « Approuvée » …
  • Et pour finir : le paiement : au-delà du paiement lui-même qui est la finitude d’une facture, il est important de rapprocher facture et paiement (on parle de lettrage), pour l’acheteur pour lui permettre d’identifier les factures restant à payer, pour le fournisseur pour se focaliser sur les factures à recouvrir. Pour cela 2 statuts sont nécessaires :
  • Mise en Paiement, émis par l’Acheteur ou celui qui paie pour son compte (le Payeur), qui dit pour une facture donnée, qu’elle est réglée, en indiquant le montant réglé (notamment en cas de paiement partiel). Attention, ceci est différent d’un AVIS DE PAIEMENT, qui annonce un règlement en donnant normalement le détail de ce qui est payé (les factures ou parties de factures, les avoirs).
  • Encaissée, émis par celui qui est payé (donc le Vendeur, ou le tiers Bénéficiaire), qui indique que la facture a été payée par l’Acheteur ou pour son compte (quand c’est un tiers), ce qui normalement indique la fin de son cycle. MAIS ATTENTION, il arrive aussi que les factures soient « Encaissées » sans avoir été validées, par exemple toutes les factures déjà payées, ou les factures faisant l’objet d’un prélèvement automatique. Il est tout aussi possible qu’une facture « Encaissée », soit ensuite « Refusée ». Nous verrons comment gérer ces cas. Il ne faut pas confondre non plus le fait que le Vendeur perçoive un montant pour sa facture dans un cadre de refinancement (par exemple après affacturage), du fait que la facture a effectivement été réglée, qui est le déclencheur de l’exigibilité de TVA (collecte et déductibilité) et donc de statut « Encaissée ».

Pour les factures de service pour lesquelles l’option au débit n’a pas été activée (donc les factures à l’encaissement), ce statut « Encaissée » est transmis à C5 (PPF-Collecteur), par C2.

Les statuts de traitement et de paiement ne sont pas chronologiques, c’est-à-dire qu’il n’y a pas un ordre établi. Le seul statut « terminal », c’est-à-dire qui ne peut pas être suivi d’un autre, est le statut « Refusée ».

Enfin, il existe un statut issu de l’existant B2G, qui est le « Visée ». Il est utilisé en cas de co-traitance ou de sous-traitance en B2G (et potentiellement en B2B sur le PPF, mais nous en reparlerons avec les cas d’usage) pour permettre à un Mandataire ou chef de file de « pré-valider » (on dit donc « Viser ») les factures pour que l’acheteur ou le payeur puisse approuver et / ou payer.

Il existe aussi une autre information importante à échanger sur le cycle de vie : le fait que la facture soit « Affacturée », « Affacturée Confidentielle » (c’est-à-dire qu’il s’agit d’un état partagé uniquement entre le Vendeur et l’Affactureur), ou qu’elle ne soit « Plus Affacturée », car ça arrive. On parle à ce stade d’état, même si l’information sera transmise via un message de statut de cycle de vie. La raison essentielle est qu’on comprend bien que ceci ne doit pas venir impacter le statut de transmission ou de traitement courant de la facture.

De plus, les statuts de cycle de vie sont transmis indépendamment des factures et des autres statuts. Ils peuvent donc être reçus dans un ordre différent de celui de l’émission. C’est pourquoi la date et heure des statuts fait partie du message et est importante, notamment si on cherche à afficher le dernier, donc le plus récent.

Le PPF n’affichera que le dernier statut actif, tout en conservant un historique des statuts. Les PDP pourront faire de même ou considérer qu’il y a plusieurs familles et afficher par exemple distinctement les statuts de la phase de transmission, de ceux de la phase de traitement, de ceux de la phase de Paiement, voire d’autres statuts ou état comme le fait qu’une facture est affacturée.

 

4        Le statut « Refusée »

Le statut « Refusée » a pour conséquence une annulation du flux 1, c’est-à-dire une annulation de la TVA collectable pour le Vendeur, mais aussi déductible pour l’acheteur.

Il a pour objet notamment de lutter contre le spam de factures, c’est-à-dire le fait que certains acteurs mal intentionnés pourraient transmettre des factures à beaucoup d’entreprises, en espérant que certaines les paieront sans trop les regarder. Il est assez naturel de considérer que ces factures peuvent (et même doivent) ne pas être comptabilisées chez l’Acheteur. C’est d’ailleurs accessoirement la pratique des entités publiques pour le B2G, qui s’étend d’ailleurs abusivement à toute facture que l’acheteur considère non conforme à la commande ou la livraison (ce qui relève normalement d‘un litige).

Une fois donné la capacité de « Refuser », c’est-à-dire d’ignorer certaines factures, il faut aussi lutter contre le Refus abusif, qui nécessite de refaire une facture, décalant la date d’échéance. C’est pourquoi tout litige commercial doit donner lieu à un Litige pour permettre une discussion et le cas échéant une résolution au travers d’un Avoir ou d’une Facture Rectificative, avec des flux 1 qui s’annulent ou s’annulent et se remplacent.

C’est la raison pour laquelle il est important d’obliger la fourniture d’un MOTIF de Refus et de cantonner ceux-ci.

Il reste néanmoins un sujet sur le fait qu’un statut « Refusée » peut être émis à tout moment, y compris par erreur. Une piste d’amélioration serait déjà de le limiter dans le temps, notamment pour éviter les conséquences d’un Refus tardif (cf ci-dessous).

 

4.1        Comment « déboucler » une facture « Refusée »

Or, si la facture « Refusée » n’a pas été « Rejetée », ce qui revient quelque part à considérer qu’elle n’a pas existé du point de vue de l’Administration fiscale et du Destinataire, elle serait donc susceptible de faire l’objet d’un AVOIR, voire d’une FACTURE RECTIFCATIVE. Or cet AVOIR ou FACTURE RECTIFICATIVE, qui doivent référencer la facture qu’ils annulent ou remplacent, va faire l’objet d’un flux 1, que l’Administration devra aussi ignorer.

Rien n’empêche non plus de REFUSER un AVOIR, ce qui nécessiterait de transmettre une FACTURE pour l’annuler, sans être bien certain que le PPF pourra le détecter et donc ne pas tenir compte du flux 1.

Par conséquent, POUR RESTER SIMPLE, puisque le statut « Refusée » a pour effet d’annuler le flux 1, et donc la facture vu de la DGFIP, le plus simple est d’aligner le traitement sur ce principe : Toute facture REFUSÉE par un acheteur, ou pour son compte :

  • Ne doit pas être comptabilisée chez l’acheteur ou être annulée du seul fait du statut « Refusée ».
  • Doit faire l’objet d‘un AVOIR INTERNE chez le Vendeur pour l’annuler, SANS qu’elle soit transmise à l’acheteur et donc SANS flux 1 transmis au PPF.

ATTENTION, rien n’interdit à un Vendeur de transmettre un AVOIR ou même une FACTURE RECTIFICATIVE référençant une facture « Refusée ». La bonne pratique est alors :

  • Pour un AVOIR : C2 devrait a minima le signaler à C1 pour confirmer sa transmission. De même pour C3. C4 peut le comptabiliser s’il a comptabilisé la facture refusée, ou le refuser.
  • Pour une FACTURE RECTIFICATIVE : elle devra être traitée normalement, avec son flux 1 transmis à C5, et le destinataire pourra la traiter comme une facture classique, dans la mesure à la facture « Refusée » qu’elle corrige n’a pas été comptabilisée ou a déjà été annulée du fait du statut Refusée.

 

4.2        Un statut « Refusée » après un statut « Encaissée »

Comme le statut « Encaissée » est transmis par l’Émetteur, il peut arriver qu’il soit émis avant que l’acheteur décide de poser un statut « Refusée ». Il est même possible que la facture soit Rejetée car jugée non conforme en réception, car l’Émetteur (C1) ne peut pas poser de statut « Encaissé » sur une facture Rejetée à l’émission).

Si ceci arrive, que se passe-t-il :

  • La facture été échangée et un statut « Encaissée » a été transmis (via un flux 6, message de statut sur facture).
  • Comme la facture est Refusée, ceci annule le flux 1 (donc le pré-remplissage de TVA), et donc aussi le flux 6.
  • L’Émetteur peut transmettre un flux 6 « Encaissée » négatif référençant la facture Refusée, car il peut être le fruit de la correction dans le système de gestion de l’émetteur : puisque la facture est Refusée (ou Rejetée), toute déclaration d’encaissement doit être annulée. Normalement, le PPF devra ignorer aussi ce flux 6 négatif puisqu’il fait référence à une facture « Refusée ».
  • L’Émetteur fait un AVOIR INTERNE pour annuler cette facture, puis une NOUVELLE FACTURE.
  • L’Émetteur transmet alors un flux 6 d’encaissement référençant la NOUVELLE FACTURE.

Ainsi, la Facture déjà payée « Refusée » ou « Rejetée » est oubliée. Et la NOUVELLE FACTURE la remplace, ainsi que son règlement qui lui est désormais affecté. En pratique, il s’est opéré un dé-lettrage, puis un nouveau lettrage.

 

4.3        Le Refus Tardif

Si une facture est émise valablement, le flux 1 est transmis et la TVA est collectable et déductible (ceci étant dépendant d’un statut encaissé pour les factures à l’encaissement). Elle apparaitra dans le pré-remplissage de TVA.

Si la facture est « Refusée » après la période de déclaration TVA, alors « annuler » le flux 1 n’aura plus d’action. On en déduit que l’annulation d’un flux 1 doit plutôt consister à créer un flux 1 inverse, donc à anticiper le flux 1 de l’AVOIR INTERNE qui l’annulera (ceci est à confirmer avec le PPF-Collecteur).

Pour l’Acheteur, il faudra annuler la facture aussi, et donc anticiper un AVOIR qui n’arrivera potentiellement pas.

On perçoit bien quelques conséquences désagréables, qui vont arriver. Il y a donc une vigilance particulière à les éviter, à la fois en n’abusant pas du statut « Refusée » et en se préparant à définir des procédures de gestion de ces évènements.

Et le mieux serait certainement de LIMITER la capacité à poser un statut « Refusée » dans le temps (par exemple sous quelques jours). Cela nécessite malgré tout une étape initiale de traitement qui consiste à Refuser ou bien Prendre en Charge la facture, qui n’est pas dans les habitudes des entreprises, en particulier des PME / TPE. Par contre, c’est une étape qui matérialise très bien le fait que la facture doit être comptabilisée, et donc signifie à un Expert-Comptable par exemple de prendre en charge cette facture.

 

5        Comment déboucle-t-on un LITIGE.

En cas de Litige commercial, le statut « En Litige » est le plus naturel. La façon d’en sortir est soit d’approuver la facture après discussion, soit de demander un AVOIR ou une facture RECTIFICATIVE :

  • En cas d’AVOIR total, l’AVOIR est traité et rapproché avec la facture qu’il annule. Il n’y a pas lieu de le mettre en Litige. La bonne pratique est alors de l’approuver, ainsi que la facture. Ensuite, il pourra être signifier un Paiement de la facture et de l’avoir par compensation (pour les puristes). Le Vendeur pourra soit transmettre alors un statut « Encaissée » pour la facture et le même en négatif pour l’Avoir, ou bien ne rien transmettre du tout, ce qui fera que la TVA correspondante ne sera jamais exigible.
  • En cas d’AVOIR PARTIEL, c’est le même mécanisme, sauf que le Vendeur devra soit transmettre un statut « Encaissée » pour la facture, à hauteur du montant net, soit transmettre un statut « Encaissée » total pour la facture et un autre pour l’Avoir. Pour être strictement conforme à la réglementation, il devrait même transmettre un statut « Encaissée » partiel de la facture à hauteur du montant de l’AVOIR dès la transmission de l’AVOIR (non Refusé), puis le solde quand il est effectivement payé du solde.
  • En cas de FACTURE RECTIFICATIVE, l’Acheteur doit comptabiliser la facture rectificative et annuler la facture qu’elle référence et annule. Pour ne pas laisser la facture en statut Litige, il pourrait être décidé de la REFUSER alors, avec un motif clair indiquant qu’elle est Refusée suite à facture rectificative (à discuter avec la DGFIP / AIFE sur les motifs de refus). Ceci permettrait de traiter la facture qui a été annulée et remplacée comme une facture annulée (et donc Refusée). Parallélisme de traitement.

 

6        Qui a le droit de poser Quel statut.

La réglementation ne régit pas qui peut poser quel statut, mais le PPF décrit ce qu’il fera. Contrairement à la plupart des PDP qui différencient un traitement à l’émission d’un traitement en réception, le PPF est développé sur la base d’un traitement unique dès lors qu’une facture lui est présenté, partagé avec toutes les parties qui disposent d’un compte sur le PPF et qui sont nommées dans la facture. C’est d’ailleurs ce qui explique la spécificité du Circuit B2 où le PPF crée le flux 1 alors qu’il est en réception.

La conséquence de ce principe est qu’il est nécessaire de définir des règles génériques pour dire qui a le droit de faire quoi dans ce traitement partagé. Ainsi (cf matrice des droits de l’annexe 2) :

  • Le Vendeur peut déposer une facture « classique », et l’Acheteur peut déposer une facture affacturée.
  • Le Vendeur ou le Bénéficiaire peuvent déposer un statut « Encaissée ».
  • Le Vendeur ou le Tiers Facturant peuvent poser un statut « Complétée ».
  • L’Acheteur, l’Agent d’Acheteur ou l’Adressé À peuvent poser les statuts « Prise en Charge », « Suspendue », « En Litige », « Approuvée », « Approuvée Partiellement », « Refusée », « Paiement Transmis ».
  • Le Payeur peut poser le statut « Paiement Transmis ».
  • Et plus étonnant, un Agent de Vendeur peut poser un statut « Refusée » ou « Visée » (cas de co-traitance B2G).
  • Enfin, un Vendeur peut poser un statut « Refusée » si la facture est créée par un Tiers Facturant sous mandat de facturation (parce que la réglementation sur les mandats de facturation permet de la faire).

Cette matrice devra probablement être complétée en cas d’autofacturation.

S’agissant des PDP, la gestion des droits peut se faire de façon comparable, à détailler dans les conditions générales de services, ou bien au travers de délégations explicites autorisant un compte tiers à celui du Vendeur ou de l’Acheteur à voir ou agir sur certaines factures en fonction de son rôle. Ce peut être par exemple le cas d’un Expert-Comptable qui peut avoir ainsi accès aux factures de ses clients, et le cas échéant poser des statuts pour son compte, sans forcément être désigné dans les factures.

Dans la mesure où l’état de l’art consiste à différencier le traitement à l’émission du traitement en réception, il faut séparer le monde en 2 équipes :

  • Celle du Vendeur, associé au Tiers Facturant, à l’Agent de Vendeur et au Bénéficiaire (du paiement), pouvant agir sur les statuts « Complétée » et « Encaissée », et le cas échéant :
  • « Refusée » pour le Vendeur en cas de facture créée sous mandat par le Tiers Facturant, sachant que ceci introduit une divergence puisque que l’acheteur pourrait voir une facture reçue en cours de traitement « Refusée » par le camp du Vendeur (et donc Flux 1 annulé, nécessité de faire un AVOIR INTERNE et une nouvelle facture).
  • « Visée », dont on pourrait très bien considérer qu’il s’agit d’une sorte de « pré-validation », au-delà de l’utilisation en B2G.
  • Celle de l’Acheteur, associé à l’Agent d‘Acheteur (potentiellement en charge de la validation), l’Adressé À et le Payeur, pouvant agir sur les statuts de traitement (Prise en Charge, Suspendue, En Litige, Approuvée, Approuvée Partiellement, Refusée), et le statut de « Paiement Transmis ». Il peut être envisagé aussi de permettre un statut « Visée », par exemple en considérant qu’un Agent d’Acheteur Vise la facture pour permettre à l’Acheteur de l’Approuver.

Les droits peuvent être imposés par acteur, comme le propose le PPF, et dans ce cas, ceci doit être décrit dans le conditions générales de services de la PDP, ou bien paramétrable de façon plus fine par le Vendeur et l’Acheteur qui restent respectivement responsables des traitements en émission et réception. Par exemple, il peut être décidé dans certains cas de n’autoriser que l’Agent d’Acheteur à poser certains statuts, et pas d’autres. Idem pour le Payeur.

Le cas de l’Autofacturation doit être aussi détaillé, car on s’attend dans ce cas à ce que ce soit le Vendeur qui puisse Refuser, voire mettre en Litige ou Approuver Partiellement. Dans ce cas d’ailleurs, des AVOIRS peuvent s‘avérer nécessaires en cas de Refus, car les factures et avoirs (y compris avoirs internes) doivent être dans la comptabilité du Vendeur.

 

7        Quelles transitions possibles entre statuts

Il reste des règles déterminant quelles transitions de statuts sont possibles sur le PPF au travers d’un matrice jointe en annexe 2, qui n’est pas facile à bien comprendre. Pour aller à l’essentiel, il faut regarder les croix rouges, qui en colonne indique quels statuts ne peuvent être suivis d’aucun autre. Ils sont « terminaux » et il s’agit de « Rejetée » et « Refusée ».

Ensuite, il faut regarder les croix rouges en ligne qui indiquent quels statuts ne peuvent pas être émis les statuts listés en colonne, à savoir :

  • Le statut « Rejetée » ne peut plus être posé dès lors qu’il y a un statut « Reçue » ou tous les suivants posés par le destinataire (et donc à l’exception de « Visée » qui peut être posé par un Agent de Vendeur).
  • Le statut « Mise à Disposition » ne peut pas être posé si la facture a été Rejetée ou Refusée
  • Le statut « Rejetée à l’émission » (par C2) ne peut être posé qu’au début et pas suite à n’importe quel autre statut puisqu’il est le pendant du statut « Déposée » qui donne suite aux autres.
  • Le Statut « Déposé » est le premier statut possible (à l’instar du « Rejetée à l’émission ») et ne peut donc pas suivre n’importe quel autre.
  • Le statut « Paiement transmis » par un Tiers Payeur ne peut pas se faire sur une facture « Rejetée » ou « Refusée ».

Tout ceci n’est que logique finalement et fait assez peu de règles à respecter. Pour le reste, il est noté quelques incohérences de transitions (en orange), mais qui peuvent être juste le résultat de désynchronisation dans l’ordre de transmission.

A noter aussi un statut « Non Visée » qui n’est pas repris dans la liste des statuts par ailleurs. Il s’agit d’une erreur quelque part, qui ne change rien à l’ensemble (Si maintenu, « Non Visé » signifie donc l’inverse de « Visée » et c’est probablement assez utile).

 

II          Le message cycle de vie, accusé de réception fonctionnel universel

1        Le principe d’accusé de réception fonctionnel élargi

Pour transmettre les statuts, il a été choisi de s’appuyer sur un message générique CDAR (Cross Domain Acknowledgement and Response), qui permet de répondre à tous les besoins de la réforme, y compris reporter des montants (Paiement Transmis, Encaissée), mais aussi des statuts divers, des actions attendues, indiquer des valeurs erronées à corriger ou bien même transmettre des informations complémentaires.

De plus, le PPF a décidé d’utiliser le même message pour tracer la transmission des autres « objets métiers » que sont les Flux 1, Flux 8, 9 et 10, Flux 11 à 14 pour l’annuaire. Bref dès lors qu’un échange de fichier est opéré avec le PPF, des statuts de transmission, d’acceptation ou de refus sont aussi prévus, utilisant le même message CDAR.

Enfin, le PPF impose que les échanges par canal EDI se fasse au travers de « paquets » de fichiers « Objets métiers » de même nature. Malheureusement, ceci est appelé des Flux, ce qui peut porter à confusion avec les Flux 1, 2 , … qui décrivent en fait les objets métiers échangés.

Pour ces Flux-Batch (pour les différencier des Flux 1, Flux 2, …), il y a aussi des messages de cycle de vie spécifiques, car la première étape de réception consiste à contrôler ce fichier Flux-Batch, à essayer de le découper en objets métiers élémentaires (en factures par exemple), à vérifier qu’ils sont correctement structurés (ils respectent l’xsd), le cas échéant à contrôler des signatures électroniques détachées, et à l’issue de toute ceci,

  • soit de juger le Flux-Batch « RECEVABLE », via un message Cycle de Vie, et on passe à alors au traitement unitaire,
  • soit de le considérer « IRRECEVABLE », toujours via un message cycle de vie, dès lors qu’il y a une erreur quelque part. Dans ce cas l’émetteur doit réémettre un Flux-Batch complet corrigé.

Ainsi, le PPF a prévu des statuts aussi pour d’autres objets métiers :

  • Les flux 1 transmis au PPF, qui peuvent être « Déposée » ou « Rejetée », ce qui sera visible des utilisateurs, mais dont le traitement avec l’Administration est ensuite aussi suivi par le PPF et les PDP uniquement (Mise à Disposition, Prise en Compte par l’Administration, Rejetée le cas échéant par l’Administration).
  • Les flux 10 (e-reporting), qui ont des statuts de transmission et d’acceptation / refus par l’Administration.
  • Les flux 8 et 9 servant au e-reporting.
  • Les flux 11 relatifs à l’annuaire.
  • Les flux 6 relatifs aux statuts de cycle de vie de facture, qui peuvent être eux-mêmes rejetés.

Tout ceci peut donner une impression de complexité à la lecture de l’annexe 2 du message CDV dans la mesure où il permet de transmettre tous les statuts et cycle de vie de ces différents Objets métiers et Flux-Batch.

 

2        Le message Cycle de vie des factures

La description du message part du message complet CDAR (UN/CEFACT), qui en pratique permet de transmettre des reporting d’accusés de réception et de cycle de vie pour plusieurs objets métiers (par exemple pour plusieurs factures). Cette possibilité n’a pas été retenue néanmoins. Par conséquent, un message CDAR sera relatif à un seul statut pour une seule facture. Il pourra néanmoins être envisagé de transmettre le cycle de vie d’une facture, a minima entre PDP, par exemple pour transmettre à un Affactureur tout l’historique du cycle de vie dans un seul message au lieu d’en faire autant que de statuts.

Le message se décompose de la façon suivante, appliqué aux statuts de cycle de vie des factures :

  • Un entête, comme tous les messages UN/CEFACT (par exemple les factures en CII), avec des éléments de contexte et :
  • Un numéro de document, un nom, une date et heure.
  • Un « Sender » (MDG-9), qui est la partie qui transmet le message, nommé Émetteur du flux en annexe 2 ; il faut comprendre le flux-batch, donc les Plateformes PDP / PPF.
  • Un « Issuer » (MDG-16), qui est la partie qui a créé le message (donc les Plateformes respectives pour les statuts de transmission ou les Parties à la transaction commerciale pour les statuts de traitement ou de paiement).
  • Un ou plusieurs « Recipient » (MDG-23), qui sont les Parties qui sont destinataires du message, avec la possibilité d’en avoir plusieurs (ce qui est pratique quand un message doit être transmis aussi au PPF, pour les statuts obligatoires, mais ceci permet aussi de désigner tous les destinataires de certains statuts : par exemple un statut « Déposée » est créé et transmis par C2 à l’attention de C1, C4 et C5).
  • Chaque partie est identifiée par un ou plusieurs ID Globaux, avec des qualifiants comme pour la facture (0002 pour le SIREN, 0009 pour le SIRET, 0224 pour un Code_Routage, 0088 pour un GLN …., une raison sociale, un code de Rôle permettant de dire si c’est l’acheteur (BY), le Vendeur (SE), le Bénéficiaire Affactureur (DL), une PDP (WK) le PPF (DFH), …, une adresse électronique, par exemple SIREN_SUFFIXE, avec qualifiant 0225.
  • A NOTER : la réforme est construite pour conserver la confidentialité de quelle est la PDP / PPF utilisée par chaque entreprise. Dès lors, il convient théoriquement d’éviter de nommer les PDP (qui peuvent être les « Sender » ou « Issuer ») dans les messages de statuts. Par exemple, nommer C2, plateforme d’émission dans un statut « Déposée » serait une façon de révéler à C4 l’identité de C2.
  • A NOTER AUSSI : Le PPF a choisi de reconstruire les messages cycle de vie à chaque étape. Ainsi, s’il agit en tant que C3, il reçoit un message de statut de C4, puis en crée un à destination de C2. S’il agit en tant que C2, il reçoit un statut de C3, puis en crée un à destination de C1.

Or, le principe des messages de statuts de traitement et paiement est aussi et surtout qu’ils peuvent être transmis de C4 à C1 sans modification. Les PDP peuvent donc aussi choisir de procéder de cette façon, en évitant de nommer les plateformes C2 et C3, qui sont découvertes dynamiquement en fonction des adresses électroniques de C1 et C4 (en interopérabilité PEPPOL).

  • Un bloc MDB-03, dénommé DOCUMENT REPONSE, qui permettrait de transmettre plusieurs groupes de statuts, ce qui n’est pas utilisé. Ceci oblige donc à renseigner à « False » MDT-74. Ce bloc contient aussi la Date et heure du statut (MDT-78).
  • Ensuite un nouveau bloc MDG-32, qui identifie l’objet sur lequel le statut porte, puis en donne le détail :
  • Des identifiants du document : Numéro (MDT-87), Codetype (MDT-91) de document, une date et heure de réception du document (MDG-34), un identifiant du Vendeur (pour les factures), normalement le SIREN suffit, une code rôle, et la date d’émission de la facture (MDG-35).
  • Une pièce jointe, qui permet de transmettre des éléments complémentaires, mais aussi de transmettre la facture à un tiers affactureur si nécessaire.
  • Un bloc « Destinataire » du Document (MDG-41), utilisé pour signifier un changement de Bénéficiaire, par exemple en cas d’Affacturage après transmission de la facture.
  • Un code statut (MDT-105 : pour les codes donnés dans les spécifications externes : 200 = Déposée, …), et une valeur en texte (MDT-106 : par exemple « Déposée »).
  • Puis un bloc de détail de statut, qui peut être multiple si on veut transmettre plusieurs erreurs ou plusieurs informations sur une facture, et qui comporte un Motif de statut (par exemple Motif de Rejet, de Refus, de Litige, …), en code (MDT-113) et en texte (MDT-114), une action attendue (par exemple demande d’AVOIR), en code (MDT-121) et en texte (MDT-122) et une note en texte libre. Enfin, un sous-bloc MDG–43 permet soit de signifier des données à reporter (pour les statuts « Encaissée », « Paiement Transmis », mais potentiellement pour des approbations ou encaissement partiels), soit pour indiquer des modifications (par exemple un changement d’IBAN), ou des erreurs à corriger.

Laisser un commentaire