Status
Statusereignisse und Zustände in der Warteschlange.
- In der SandboxStruktur der Ereignisse
- Noch nicht in der SandboxStatus der Netze
In einfachen Worten
Jede Rechnung hat einen Zustand, etwa in der Warteschlange oder abgelehnt, und einen Verlauf von Ereignissen, der sagt, was mit ihr geschehen ist. So erfährt ein Kunde oder Partner, ob eine Rechnung durchgegangen ist. Die gehostete Sandbox enthält noch keine Zugangsdaten für ein Netz, deshalb erscheinen die Ereignisse, die von der Verbindung zu einem Land kommen, erst, wenn ein Übermittlungsweg angebunden ist.
Eine Rechnung hat zwei Arten von Status. Statusereignisse sagen, was mit ihr geschehen ist. Der Zustand in der Warteschlange sagt, wo sie gerade steht.
Zustand in der Warteschlange
GET /invoices/{id} liefert den Zustand.
| Zustand | Bedeutung |
|---|---|
received | Die Rechnung wurde beim Eingang angenommen. |
validated | Die Rechnung hat alle Prüfungen bestanden. |
validation_failed | Die offiziellen Regeln haben das Dokument abgewiesen. Es kommt auf die Betreuungsliste. |
source_error | Die ERP-Daten konnten nicht gelesen werden. |
queued | Angenommen und wartend. |
submitting | Ein Versand wurde versucht, und seine Antwort ging verloren, deshalb hat der Übermittlungsweg die Rechnung möglicherweise. Der Worker entscheidet es als submitted oder dead_letter. |
submitted | Der Übermittlungsweg hat die Rechnung. |
ready | Der Endzustand für Deutschland. Die XRechnung oder ZUGFeRD-Datei ist validiert und für die Zustellung durch den Partner gespeichert. Es wurde nichts gesendet. |
accepted | Der Übermittlungsweg hat sie angenommen. |
delivered | Die Rechnung hat die Seite des Käufers erreicht. |
rejected | Der Übermittlungsweg hat sie endgültig abgelehnt. Sie kommt auf die Betreuungsliste. |
dead_letter | Nach vorübergehenden Fehlern sind alle Wiederholungsversuche aufgebraucht. Sie kommt auf die Betreuungsliste. |
cancelled | Vor der Übermittlung gestoppt (siehe Stornieren). |
queued und submitting sind interne Schritte zwischen validated und submitted, und kein Statusereignis meldet sie.
Statusereignisse
Alle Übermittlungswege nutzen dieselbe Struktur für Ereignisse. GET /invoices/{id}/events liefert sie, und ein Webhook stellt denselben Body zu (siehe Webhooks).
| Status | Bedeutung |
|---|---|
received | Die Rechnung wurde beim Eingang angenommen. |
validated | Die Rechnung hat alle Prüfungen bestanden. |
source_error | Die ERP-Daten konnten nicht gelesen werden. Enthält errors. |
validation_failed | Eine Prüfung ist fehlgeschlagen. Enthält errors. |
submitted | Der Übermittlungsweg hat die Rechnung. |
accepted | Der Übermittlungsweg hat sie angenommen. Enthält legal_id, die eigene Referenz des Übermittlungswegs. |
rejected | Der Übermittlungsweg hat sie abgelehnt. Enthält errors. |
delivered | Die Rechnung hat die Seite des Käufers erreicht. |
buyer_status | Der Käufer hat geantwortet. buyer_status ist einer der Werte acknowledged, in_process, under_query, conditionally_accepted, rejected, approved, disputed oder paid. |
Felder in jedem Ereignis: event_id, sequence, occurred_at, invoice_ref, invoice_number, country_route, environment, status und document_sha256. Manche Ereignisse enthalten zusätzlich legal_id, buyer_status, errors (dieselben Einträge wie ein Befund im Probelauf) und route, das die submission_id des Übermittlungswegs und seinen nativen Status in raw enthält.
Tipp
Ordnen Sie Ereignisse nach sequence, nicht nach der Zeit.
Das Schema erzwingt drei Regeln: accepted enthält legal_id, die drei Fehlerstatus enthalten errors, und buyer_status enthält einen buyer_status.
Welche Ereignisse auftreten
In der SandboxSandboxDer Eingang schreibt received, mit sequence 1. Danach führt der Service die Prüfer des Übermittlungswegs aus und schreibt validated, oder validation_failed, wenn eine Prüfung fehlschlägt. Danach schreibt jeder Schritt der Rechnung ein Ereignis: submitted, accepted, delivered oder rejected. Für Deutschland folgt nach validated nichts, weil die Rechnung bei ready endet. Ein Beispiel zeigen die aufgezeichneten Ereignisse.
In der gehosteten Sandbox sind noch keine Zugangsdaten für ein Netz gespeichert. Ein Übermittlungsweg, der welche braucht, erreicht submitted, ohne dass etwas gesendet wird, und Deutschland endet bei ready. In der Produktion versucht ein Übermittlungsweg ohne Zugangsdaten es erneut und schiebt die Rechnung dann auf die Dead-Letter-Liste.
Die Ereignisse, die von einem Netz kommen (accepted, delivered und buyer_status), brauchen einen angebundenen Übermittlungsweg. Die Zuordnung der eigenen Status jedes Netzes ist gebaut und getestet und ist gegen die Testsysteme von KSeF, eines Peppol-Access-Points und einer französischen Plattform gelaufen. In der gehosteten Sandbox ist sie noch nicht angebunden.
Endstatus je Übermittlungsweg
Noch nicht in der SandboxNetze| Übermittlungsweg | Endstatus | Was er enthält | Fehlschlag |
|---|---|---|---|
PL-KSEF | accepted | Die KSeF-Nummer als legal_id. | rejected mit dem KSeF-Code, zum Beispiel KSEF-440 für ein Duplikat. |
RO-EFACTURA | accepted, wenn der Zustand bei ANAF ok ist | Den Upload-Index der ANAF. | rejected, wenn der Zustand nok ist, mit dem Fehlercode der ANAF. Der Upload folgt der Dokumentation der ANAF und wurde nicht ausprobiert; es sind nur seine Validatoren gelaufen. |
PEPPOL | delivered | Die Dokument-ID des Access Points. | rejected, wenn der Access Point sie abweist oder einen Fehlschlag meldet. |
FR-PA | delivered, dann Ereignisse buyer_status | Die Rechnungs-ID der Plattform. Der französische Code, seine Bezeichnung und eine etwaige Notiz stehen in route.raw. | rejected, wenn die Plattform sie abweist, zum Beispiel fr:213. |
DE-XRECHNUNG | Keine Behörde antwortet. Die erstellte und geprüfte Datei ist das Ergebnis. | Die Zustellung läuft über den Kanal, Peppol oder E-Mail. | Das 422 beim Eingang. Es folgt keine Antwort eines Netzes. |
- Vorübergehende Fehler eines Netzes werden nie zu Ereignissen. Sie lösen Wiederholungsversuche aus (siehe Limits).
- Ein französischer Statuscode, den der Service nicht zuordnet, erzeugt kein Ereignis und löst eine Warnmeldung aus, damit er nicht verloren geht.
- Ein Käufer, den ein Netz nicht erreichen kann. Für Peppol prüft der Service den Schema-Code der Käufer-ID, nicht, ob der Käufer registriert ist. Ein Access Point kann einen Käufer, der kein Peppol-Teilnehmer ist, als nicht erreichbar melden, und die Zuordnung macht daraus
rejectedmitEI-PEPPOL-NO-ROUTE. Das folgt der Dokumentation des Access Points und wurde bei einem Live-Access-Point nicht bestätigt. Bei einem französischen Käufer ohne Plattformadresse sollte die Rechnung fehlschlagen und nicht zugestellt werden; auch das wurde nicht bestätigt.