Stări
Evenimente de stare și stări în coadă.
- În sandboxstructura evenimentelor
- Încă nu este în sandboxstările rețelelor
În cuvinte simple
Fiecare factură are o stare, cum ar fi în coadă sau respinsă, și un istoric de evenimente care arată ce s-a întâmplat cu ea. Așa află un client sau un partener dacă o factură a trecut. Sandboxul găzduit nu conține încă date de autentificare pentru nicio rețea, așa că evenimentele care vin de la o conexiune cu o țară apar doar când un canal este conectat.
O factură are două tipuri de stare. Evenimentele de stare arată ce s-a întâmplat cu ea. Starea în coadă arată unde se află acum.
Starea în coadă
GET /invoices/{id} returnează starea.
| Stare | Semnificație |
|---|---|
received | Factura a fost acceptată la preluare. |
validated | Factura a trecut toate verificările. |
validation_failed | Regulile oficiale au refuzat documentul. Ajunge pe lista de gestionare. |
source_error | Datele din ERP nu au putut fi citite. |
queued | Acceptată și în așteptare. |
submitting | O trimitere a fost încercată, iar răspunsul ei s-a pierdut, deci este posibil ca canalul să aibă factura. Procesul de lucru o stabilește ca submitted sau dead_letter. |
submitted | Canalul are factura. |
ready | Starea finală pentru Germania. XRechnung sau ZUGFeRD este validat și stocat pentru ca partenerul să îl livreze. Nu s-a trimis nimic. |
accepted | Canalul a acceptat-o. |
delivered | Factura a ajuns în partea cumpărătorului. |
rejected | Canalul a refuzat-o definitiv. Ajunge pe lista de gestionare. |
dead_letter | Erorile temporare și-au epuizat reîncercările. Ajunge pe lista de gestionare. |
cancelled | Oprită înainte de transmitere (consultați anularea). |
queued și submitting sunt pași interni între validated și submitted, iar niciun eveniment de stare nu îi raportează.
Evenimente de stare
Toate canalele folosesc aceeași structură de eveniment. GET /invoices/{id}/events le returnează, iar un webhook livrează același corp (consultați webhook-urile).
| Stare | Semnificație |
|---|---|
received | Factura a fost acceptată la preluare. |
validated | Factura a trecut toate verificările. |
source_error | Datele din ERP nu au putut fi citite. Conține errors. |
validation_failed | O verificare a eșuat. Conține errors. |
submitted | Canalul are factura. |
accepted | Canalul a acceptat-o. Conține legal_id, referința proprie a canalului. |
rejected | Canalul a refuzat-o. Conține errors. |
delivered | Factura a ajuns în partea cumpărătorului. |
buyer_status | Cumpărătorul a răspuns. buyer_status este unul dintre acknowledged, in_process, under_query, conditionally_accepted, rejected, approved, disputed sau paid. |
Câmpuri prezente în fiecare eveniment: event_id, sequence, occurred_at, invoice_ref, invoice_number, country_route, environment, status și document_sha256. Unele evenimente adaugă legal_id, buyer_status, errors (aceleași elemente ca o constatare dintr-o rulare de probă) și route, care conține submission_id al canalului și starea sa nativă în raw.
Sfat
Ordonați evenimentele după sequence, nu după timp.
Schema impune trei reguli: accepted conține legal_id, cele trei stări de eșec conțin errors, iar buyer_status conține un buyer_status.
Ce evenimente apar
În sandboxsandboxPreluarea scrie received, cu sequence 1. Apoi serviciul rulează validatorii canalului și scrie validated, sau validation_failed când o verificare eșuează. După aceea, fiecare mișcare a facturii scrie câte un eveniment: submitted, accepted, delivered sau rejected. Pentru Germania nu urmează nimic după validated, pentru că factura se încheie la ready. Consultați evenimentele înregistrate pentru un exemplu.
În sandboxul găzduit nu sunt încă stocate date de autentificare pentru rețele. Un canal care are nevoie de ele ajunge la submitted fără să se trimită nimic, iar Germania se încheie la ready. În producție, un canal fără date de autentificare reîncearcă, apoi trece factura în dead-letter.
Evenimentele care vin de la o rețea (accepted, delivered și buyer_status) au nevoie de un canal conectat. Maparea stărilor proprii ale fiecărei rețele este implementată și testată și a rulat pe sistemele de test ale KSeF, ale unui punct de acces Peppol și ale unei platforme franceze. Încă nu este conectată în sandboxul găzduit.
Starea finală în funcție de canal
Încă nu este în sandboxrețelele| Canal | Starea finală | Ce conține | Eșec |
|---|---|---|---|
PL-KSEF | accepted | Numărul KSeF, ca legal_id. | rejected cu codul KSeF, de exemplu KSEF-440 pentru un duplicat. |
RO-EFACTURA | accepted când starea ANAF este ok | Indexul de încărcare ANAF. | rejected când starea este nok, cu codul de eroare ANAF. Încărcarea urmează documentația ANAF și nu a fost încercată; au rulat doar validatoarele ei. |
PEPPOL | delivered | ID-ul documentului la punctul de acces. | rejected când punctul de acces o refuză sau raportează un eșec. |
FR-PA | delivered, apoi evenimente buyer_status | ID-ul facturii pe platformă. Codul francez, eticheta sa și eventuala notă circulă în route.raw. | rejected când platforma o refuză, de exemplu fr:213. |
DE-XRECHNUNG | Nicio autoritate nu răspunde. Rezultatul este fișierul generat și verificat. | Livrarea depinde de calea folosită: Peppol sau e-mail. | 422 la preluare. Nu urmează niciun răspuns de la o rețea. |
- Erorile temporare ale rețelelor nu devin niciodată evenimente. Sunt reîncercate (consultați limitele).
- Un cod de stare francez pe care serviciul nu îl mapează nu generează niciun eveniment și declanșează o alertă, ca să nu se piardă.
- Un cumpărător la care o rețea nu poate ajunge. Pentru Peppol, serviciul verifică codul de schemă al ID-ului cumpărătorului, nu dacă acesta este înregistrat. Un punct de acces poate raporta un cumpărător care nu este în Peppol ca inaccesibil, iar maparea îl transformă în
rejectedcuEI-PEPPOL-NO-ROUTE. Aceasta urmează documentația punctului de acces și nu a fost confirmată pe un punct de acces în producție. Un cumpărător francez fără adresă pe o platformă ar trebui să ducă la un eșec, nu la o livrare; nici acest lucru nu a fost confirmat.