Statussen
Statusberichten en wachtrijstatussen.
- In de sandboxvorm van de statusberichten
- Nog niet in de sandboxstatussen van netwerken
In gewone woorden
Elke factuur heeft een status, zoals in de wachtrij of afgewezen, en een geschiedenis van statusberichten die vertelt wat ermee is gebeurd. Zo komt een eindklant of partner te weten of een factuur is doorgekomen. De gehoste sandbox bevat nog geen toegangsgegevens voor een netwerk, dus de statusberichten die van een verbinding met een land komen, verschijnen pas wanneer een verzendkanaal is aangesloten.
Een factuur heeft twee soorten status. Statusberichten vertellen wat ermee is gebeurd. De wachtrijstatus geeft aan waar ze nu is.
Wachtrijstatus
GET /invoices/{id} geeft de status terug.
| Status | Betekenis |
|---|---|
received | De factuur is bij de inname geaccepteerd. |
validated | De factuur heeft alle controles doorstaan. |
validation_failed | De officiële regels hebben het document geweigerd. Het gaat naar de opvolgingslijst. |
source_error | De ERP-gegevens konden niet worden gelezen. |
queued | Geaccepteerd en in afwachting. |
submitting | Er is een verzending geprobeerd en het antwoord ging verloren, dus het verzendkanaal heeft de factuur mogelijk. De worker zet ze op submitted of dead_letter. |
submitted | Het verzendkanaal heeft de factuur. |
ready | De eindstatus van Duitsland. De XRechnung of ZUGFeRD is gevalideerd en opgeslagen zodat de partner haar kan afleveren. Er is niets verzonden. |
accepted | Het verzendkanaal heeft ze geaccepteerd. |
delivered | De factuur heeft de kant van de koper bereikt. |
rejected | Het verzendkanaal heeft ze definitief geweigerd. Ze gaat naar de opvolgingslijst. |
dead_letter | Bij tijdelijke fouten zijn alle herhaalpogingen opgebruikt. Ze gaat naar de opvolgingslijst. |
cancelled | Gestopt vóór de indiening (zie annuleren). |
queued en submitting zijn interne stappen tussen validated en submitted, en geen enkel statusbericht meldt ze.
Statusberichten
Alle verzendkanalen gebruiken dezelfde vorm voor statusberichten. GET /invoices/{id}/events geeft ze terug, en een webhook levert dezelfde body af (zie webhooks).
| Status | Betekenis |
|---|---|
received | De factuur is bij de inname geaccepteerd. |
validated | De factuur heeft alle controles doorstaan. |
source_error | De ERP-gegevens konden niet worden gelezen. Bevat errors. |
validation_failed | Een controle is mislukt. Bevat errors. |
submitted | Het verzendkanaal heeft de factuur. |
accepted | Het verzendkanaal heeft ze geaccepteerd. Bevat legal_id, de eigen referentie van het verzendkanaal. |
rejected | Het verzendkanaal heeft ze geweigerd. Bevat errors. |
delivered | De factuur heeft de kant van de koper bereikt. |
buyer_status | De koper heeft geantwoord. buyer_status is een van acknowledged, in_process, under_query, conditionally_accepted, rejected, approved, disputed of paid. |
Velden in elk statusbericht: event_id, sequence, occurred_at, invoice_ref, invoice_number, country_route, environment, status en document_sha256. Sommige statusberichten bevatten daarnaast legal_id, buyer_status, errors (dezelfde items als een bevinding van een proefrun) en route, met daarin de submission_id van het verzendkanaal en de eigen status ervan in raw.
Tip
Sorteer statusberichten op sequence, niet op tijd.
Het schema dwingt drie regels af: accepted bevat legal_id, de drie foutstatussen bevatten errors, en buyer_status bevat een buyer_status.
Welke statusberichten voorkomen
In de sandboxsandboxDe inname schrijft received, met sequence 1. Daarna voert de dienst de validators van het verzendkanaal uit en schrijft validated, of validation_failed als een controle mislukt. Daarna schrijft elke stap van de factuur één statusbericht: submitted, accepted, delivered of rejected. Voor Duitsland volgt er niets na validated, omdat de factuur op ready eindigt. Zie de vastgelegde statusberichten voor een voorbeeld.
In de gehoste sandbox zijn nog geen toegangsgegevens voor een netwerk opgeslagen. Een verzendkanaal dat ze nodig heeft, komt op submitted zonder dat er iets wordt verzonden, en Duitsland eindigt op ready. In productie probeert een verzendkanaal zonder toegangsgegevens het opnieuw en zet het de factuur daarna op de dead-letterlijst.
De statusberichten die van een netwerk komen (accepted, delivered en buyer_status) vereisen een aangesloten verzendkanaal. De mapping van de eigen statussen van elk netwerk is gebouwd en getest, en heeft gedraaid tegen de testsystemen van KSeF, een Peppol-toegangspunt en een Frans platform. In de gehoste sandbox is ze nog niet aangesloten.
Eindstatus per verzendkanaal
Nog niet in de sandboxnetwerken| Verzendkanaal | Eindstatus | Wat het bevat | Bij een fout |
|---|---|---|---|
PL-KSEF | accepted | Het KSeF-nummer als legal_id. | rejected met de KSeF-code, bijvoorbeeld KSEF-440 voor een duplicaat. |
RO-EFACTURA | accepted als de status bij ANAF ok is | De uploadindex van ANAF. | rejected als de status nok is, met de foutcode van ANAF. De upload volgt de documentatie van ANAF en is niet uitgeprobeerd; alleen de validators hebben gedraaid. |
PEPPOL | delivered | De document-ID van het toegangspunt. | rejected als het toegangspunt de factuur weigert of een fout meldt. |
FR-PA | delivered, daarna buyer_status-berichten | De factuur-ID van het platform. De Franse code, het label ervan en een eventuele opmerking reizen mee in route.raw. | rejected als het platform de factuur weigert, bijvoorbeeld fr:213. |
DE-XRECHNUNG | Er antwoordt geen overheidsinstantie. Het aangemaakte en gecontroleerde bestand is het resultaat. | De aflevering volgt het afleverkanaal: Peppol of e-mail. | De 422 bij de inname. Er volgt geen antwoord van een netwerk. |
- Tijdelijke netwerkfouten worden nooit een statusbericht. Ze worden opnieuw geprobeerd (zie limieten).
- Een Franse statuscode die de dienst niet omzet, levert geen statusbericht op maar wel een waarschuwing, zodat ze niet verloren gaat.
- Een koper die voor het netwerk onbereikbaar is. Voor Peppol controleert de dienst de schemacode van de ID van de koper, niet of de koper geregistreerd is. Een toegangspunt kan een koper die niet op Peppol zit als onbereikbaar melden, en de mapping maakt daarvan
rejectedmetEI-PEPPOL-NO-ROUTE. Dat volgt de documentatie van het toegangspunt en is niet bevestigd op een live toegangspunt. Een factuur aan een Franse koper zonder platformadres zou moeten mislukken en niet worden afgeleverd; ook dat is niet bevestigd.