Statusy
Zdarzenia statusu i stany kolejki.
- W sandboxiestruktura zdarzenia
- Jeszcze nie w sandboxiestatusy sieci
Prostymi słowami
Każda faktura ma stan, na przykład „w kolejce” albo „odrzucona”, oraz historię zdarzeń, która pokazuje, co się z nią stało. W ten sposób klient lub partner dowiaduje się, czy faktura dotarła do celu. Hostowany sandbox nie przechowuje jeszcze żadnych danych dostępowych do sieci, więc zdarzenia pochodzące z połączenia z systemem danego kraju pojawią się dopiero po podłączeniu kanału.
Faktura ma dwa rodzaje statusu. Zdarzenia statusu informują, co się z nią stało. Stan w kolejce pokazuje, gdzie faktura jest teraz.
Stan w kolejce
GET /invoices/{id} zwraca stan.
| Stan | Znaczenie |
|---|---|
received | Faktura została przyjęta na wejściu. |
validated | Faktura przeszła wszystkie kontrole. |
validation_failed | Oficjalne reguły odrzuciły dokument. Trafia on na listę do obsługi. |
source_error | Nie udało się odczytać danych z ERP. |
queued | Przyjęta i oczekuje. |
submitting | Wysyłka została podjęta, a jej odpowiedź zaginęła, więc kanał może mieć fakturę. Proces roboczy rozstrzyga to jako submitted albo dead_letter. |
submitted | Kanał otrzymał fakturę. |
ready | Stan końcowy dla Niemiec. XRechnung lub ZUGFeRD jest zwalidowany i zapisany, aby partner mógł go doręczyć. Nic nie zostało wysłane. |
accepted | Kanał ją przyjął. |
delivered | Faktura dotarła na stronę nabywcy. |
rejected | Kanał odrzucił ją na stałe. Trafia na listę do obsługi. |
dead_letter | Po błędach przejściowych wyczerpały się ponowienia. Faktura trafia na listę do obsługi. |
cancelled | Zatrzymana przed przesłaniem (zob. anulowanie). |
queued i submitting to wewnętrzne kroki między validated a submitted i żadne zdarzenie statusu ich nie zgłasza.
Zdarzenia statusu
Wszystkie kanały używają tej samej struktury zdarzenia. Zwraca je GET /invoices/{id}/events, a webhook dostarcza tę samą treść (zob. webhooki).
| Status | Znaczenie |
|---|---|
received | Faktura została przyjęta na wejściu. |
validated | Faktura przeszła wszystkie kontrole. |
source_error | Nie udało się odczytać danych z ERP. Zawiera errors. |
validation_failed | Kontrola się nie powiodła. Zawiera errors. |
submitted | Kanał otrzymał fakturę. |
accepted | Kanał ją przyjął. Zawiera legal_id, własny numer referencyjny kanału. |
rejected | Kanał ją odrzucił. Zawiera errors. |
delivered | Faktura dotarła na stronę nabywcy. |
buyer_status | Nabywca odpowiedział. buyer_status to jedna z wartości acknowledged, in_process, under_query, conditionally_accepted, rejected, approved, disputed lub paid. |
Pola każdego zdarzenia: event_id, sequence, occurred_at, invoice_ref, invoice_number, country_route, environment, status i document_sha256. Niektóre zdarzenia zawierają dodatkowo legal_id, buyer_status, errors (te same elementy co ustalenie z przebiegu próbnego) oraz route, które zawiera submission_id kanału i jego oryginalny status w raw.
Wskazówka
Zdarzenia należy porządkować według sequence, a nie według czasu.
Schemat wymusza trzy reguły: accepted zawiera legal_id, trzy statusy niepowodzenia zawierają errors, a buyer_status zawiera pole buyer_status.
Jakie zdarzenia występują
W sandboxiesandboxWejście zapisuje received, z sequence równym 1. Następnie usługa uruchamia walidatory kanału i zapisuje validated, albo validation_failed, gdy kontrola się nie powiedzie. Potem każdy ruch faktury zapisuje jedno zdarzenie: submitted, accepted, delivered lub rejected. Dla Niemiec po validated nic nie następuje, bo faktura kończy się na ready. Przykład pokazują zarejestrowane zdarzenia.
W hostowanym sandboxie nie ma jeszcze zapisanych danych dostępowych do żadnej sieci. Kanał, który ich wymaga, dochodzi do submitted, nic nie wysyłając, a Niemcy kończą się na ready. W produkcji kanał bez danych dostępowych ponawia wysyłkę, a potem przenosi fakturę do dead letter.
Zdarzenia pochodzące z sieci (accepted, delivered i buyer_status) wymagają podłączonego kanału. Mapowanie własnych statusów każdej sieci jest zbudowane i przetestowane oraz działało w systemach testowych KSeF, punktu dostępowego Peppol i francuskiej platformy. W hostowanym sandboxie nie jest jeszcze podłączone.
Status końcowy według kanału
Jeszcze nie w sandboxiesieci| Kanał | Status końcowy | Co zawiera | Niepowodzenie |
|---|---|---|---|
PL-KSEF | accepted | Numer KSeF jako legal_id. | rejected z kodem KSeF, na przykład KSEF-440 dla duplikatu. |
RO-EFACTURA | accepted, gdy stan w ANAF to ok | Indeks przesłanego pliku w ANAF. | rejected, gdy stan to nok, z kodem błędu ANAF. Przesyłanie opiera się na dokumentacji ANAF i nie zostało wypróbowane; uruchomiono tylko jego walidatory. |
PEPPOL | delivered | Identyfikator dokumentu w punkcie dostępowym. | rejected, gdy punkt dostępowy ją odrzuci lub zgłosi niepowodzenie. |
FR-PA | delivered, a potem zdarzenia buyer_status | Identyfikator faktury na platformie. Francuski kod, jego etykieta i ewentualna uwaga są przekazywane w route.raw. | rejected, gdy platforma ją odrzuci, na przykład fr:213. |
DE-XRECHNUNG | Administracja nie przesyła odpowiedzi. Wynikiem jest utworzony i sprawdzony plik. | Doręczenie zależy od wybranego sposobu: Peppol lub e-mail. | 422 na wejściu. Nie następuje żadna odpowiedź sieci. |
- Przejściowe błędy sieci nigdy nie stają się zdarzeniami. Po nich wysyłka jest ponawiana (zob. limity).
- Francuski kod statusu, którego usługa nie mapuje, nie tworzy zdarzenia i wywołuje alert, więc nie przepada.
- Nabywca, do którego sieć nie może dotrzeć. W przypadku Peppol usługa sprawdza kod schematu identyfikatora nabywcy, a nie to, czy nabywca jest zarejestrowany. Punkt dostępowy może zgłosić nabywcę spoza Peppol jako nieosiągalnego, a mapowanie zamienia to na
rejectedzEI-PEPPOL-NO-ROUTE. Wynika to z dokumentacji punktu dostępowego i nie zostało potwierdzone w działającym punkcie dostępowym. Wysyłka do francuskiego nabywcy bez adresu na platformie powinna zakończyć się niepowodzeniem, a nie doręczeniem; to również nie zostało potwierdzone.