Statuts
Événements de statut et états de file d’attente.
- Dans le bac à sablestructure des événements
- Pas encore dans le bac à sablestatuts des réseaux
En termes simples
Chaque facture a un état, comme « en file d’attente » ou « rejetée », et un historique d’événements qui indique ce qui lui est arrivé. C’est ainsi qu’un client ou un intégrateur sait si une facture est passée. Le bac à sable hébergé ne détient encore aucun identifiant d’accès à un réseau : les événements qui viennent d’une connexion à un pays n’apparaissent donc que lorsqu’un canal est raccordé.
Une facture a deux types de statut. Les événements de statut indiquent ce qui lui est arrivé. L’état de file d’attente indique où elle se trouve maintenant.
État de file d’attente
GET /invoices/{id} renvoie l’état.
| État | Signification |
|---|---|
received | La facture a été acceptée à l’entrée. |
validated | La facture a passé tous les contrôles. |
validation_failed | Les règles officielles ont refusé le document. Elle va sur la liste de suivi. |
source_error | Les données de l’ERP n’ont pas pu être lues. |
queued | Acceptée et en attente. |
submitting | Un envoi a été tenté et sa réponse s’est perdue : le canal peut donc détenir la facture. Le processus de traitement la règle en submitted ou dead_letter. |
submitted | Le canal a reçu la facture. |
ready | L’état final de l’Allemagne. Le XRechnung ou le ZUGFeRD est validé et stocké pour que l’intégrateur le livre. Rien n’a été envoyé. |
accepted | Le canal l’a acceptée. |
delivered | La facture est parvenue du côté de l’acheteur. |
rejected | Le canal l’a refusée définitivement. Elle va sur la liste de suivi. |
dead_letter | Les nouvelles tentatives après des échecs temporaires sont épuisées. Elle va sur la liste de suivi. |
cancelled | Arrêtée avant la transmission (voir annuler). |
queued et submitting sont des étapes internes entre validated et submitted, et aucun événement de statut ne les signale.
Événements de statut
Tous les canaux utilisent la même structure d’événement. GET /invoices/{id}/events les renvoie, et un webhook livre le même corps (voir webhooks).
| Statut | Signification |
|---|---|
received | La facture a été acceptée à l’entrée. |
validated | La facture a passé tous les contrôles. |
source_error | Les données de l’ERP n’ont pas pu être lues. Contient errors. |
validation_failed | Un contrôle a échoué. Contient errors. |
submitted | Le canal a reçu la facture. |
accepted | Le canal l’a acceptée. Contient legal_id, la référence propre au canal. |
rejected | Le canal l’a refusée. Contient errors. |
delivered | La facture est parvenue du côté de l’acheteur. |
buyer_status | L’acheteur a répondu. buyer_status vaut acknowledged, in_process, under_query, conditionally_accepted, rejected, approved, disputed ou paid. |
Champs de chaque événement : event_id, sequence, occurred_at, invoice_ref, invoice_number, country_route, environment, status et document_sha256. Certains événements ajoutent legal_id, buyer_status, errors (les mêmes éléments qu’un constat d’essai à blanc) et route, qui contient le submission_id du canal et son statut natif dans raw.
Conseil
Triez les événements par sequence, pas par heure.
Le schéma impose trois règles : accepted contient legal_id, les trois statuts d’échec contiennent errors, et buyer_status contient un buyer_status.
Ce qui se produit
Dans le bac à sablebac à sableL’entrée écrit received, avec sequence 1. Le service exécute ensuite les validateurs du canal et écrit validated, ou validation_failed quand un contrôle échoue. Ensuite, chaque mouvement de la facture écrit un événement : submitted, accepted, delivered ou rejected. Pour l’Allemagne, rien ne suit validated, car la facture s’arrête à ready. Voir les événements enregistrés pour un exemple.
Sur le bac à sable hébergé, aucun identifiant d’accès à un réseau n’est encore stocké. Un canal qui en a besoin atteint submitted sans que rien ne soit envoyé, et l’Allemagne s’arrête à ready. En production, un canal sans identifiant d’accès réessaie, puis place la facture en lettre morte.
Les événements qui viennent d’un réseau (accepted, delivered et buyer_status) nécessitent un canal raccordé. La conversion des statuts propres à chaque réseau est développée et testée, et a fonctionné contre les systèmes de test de KSeF, d’un point d’accès Peppol et d’une plateforme française. Elle n’est pas encore raccordée sur le bac à sable hébergé.
Statut final par canal
Pas encore dans le bac à sableréseaux| Canal | Statut final | Ce qu’il contient | Échec |
|---|---|---|---|
PL-KSEF | accepted | Le numéro KSeF comme legal_id. | rejected avec le code KSeF, par exemple KSEF-440 pour un doublon. |
RO-EFACTURA | accepted quand l’état ANAF est ok | L’index de dépôt de l’ANAF. | rejected quand l’état est nok, avec le code d’erreur de l’ANAF. Le dépôt suit la documentation de l’ANAF et n’a pas été essayé ; seuls ses validateurs ont été exécutés. |
PEPPOL | delivered | L’identifiant de document du point d’accès. | rejected quand le point d’accès la refuse ou signale un échec. |
FR-PA | delivered, puis des événements buyer_status | L’identifiant de facture de la plateforme. Le code français, son libellé et une éventuelle note passent dans route.raw. | rejected quand la plateforme la refuse, par exemple fr:213. |
DE-XRECHNUNG | Aucune administration ne répond. Le fichier produit et contrôlé constitue le résultat. | La livraison suit le mode d’envoi, Peppol ou e-mail. | Le 422 à l’entrée. Aucune réponse de réseau ne suit. |
- Les erreurs temporaires de réseau ne deviennent jamais des événements. Elles donnent lieu à de nouvelles tentatives (voir limites).
- Un code de statut français que le service ne sait pas convertir ne produit aucun événement et déclenche une alerte : il n’est donc pas perdu.
- Un acheteur qu’un réseau ne peut pas joindre. Pour Peppol, le service vérifie le code de schéma de l’identifiant de l’acheteur, et non son enregistrement. Un point d’accès peut signaler un acheteur absent de Peppol comme injoignable, et la conversion le transforme en
rejectedavecEI-PEPPOL-NO-ROUTE. Cela suit la documentation du point d’accès et n’a pas été confirmé sur un point d’accès réel. Un acheteur français sans adresse de plateforme devrait échouer, et non être livré ; cela n’a pas non plus été confirmé.