Rechnungen auflisten und suchen
- In der Sandbox
In einfachen Worten
Ein Kundenschlüssel sieht die Rechnungen seines eigenen Kunden; der Betreiber sieht die aller Kunden, oder mit client die eines Kunden. Die Zeilen enthalten, was GET /invoices/{id} enthält, ohne documents, und keinen Rechnungsinhalt: weder Käufer noch Beträge
und kein Ausstellungsdatum (für Rumänien und Polen folgt daraus deadline_at, auf wenige Tage genau). Ein unbekannter Parameter wird mit 400 beantwortet.
apiKeyAuthorizationBearer <token>Senden Sie Ihren Schlüssel als Bearer-Token: Authorization: Bearer <your-api-key>. Der Systemzustand ist der einzige Aufruf, der keinen Schlüssel braucht.
q?stringEin Teil der invoice_ref oder der Rechnungsnummer, ohne Beachtung der Groß- und Kleinschreibung. Höchstens 100 Zeichen.
length <= 100route?array<>Ein oder mehrere Übermittlungswege, durch Komma getrennt.
state?array<>Ein oder mehrere Zustände, durch Komma getrennt.
client?stringDer Filter des Betreibers auf einen Kunden. Ein Kundenschlüssel darf nur seinen eigenen Kunden nennen; jeder andere wird mit 404 beantwortet. Eine andere Form wird mit 400 beantwortet.
^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$received_from?stringErster UTC-Tag, an dem die Rechnung einging, einschließlich.
datereceived_to?stringLetzter UTC-Tag, an dem die Rechnung einging, einschließlich.
datesort?stringNach dem Eingangszeitpunkt. Bei Gleichstand entscheidet die ID, damit sich eine Seite zwischen Abrufen nie umsortiert.
"newest""newest""oldest"page?integer1 <= value1page_size?integer252550100200Eine Seite mit Treffern.
application/json- response
data*array<>total*integerTreffer vor dem Blättern.
page*integerDie zurückgegebene Seite. Eine Seite hinter dem Ende wird auf die letzte gesetzt.
page_size*integercounts_by_state*Treffer je Zustand mit allen Filtern außer state. Ein Zustand ohne Treffer fehlt.
curl -X GET "https://example.com/invoices" \ -H "Authorization: Bearer <your-api-key>"{ "data": [ { "id": "string", "invoice_ref": "string", "invoice_number": "string", "route": "PEPPOL", "environment": "sandbox", "state": "received", "legal_id": "string", "buyer_status": "string", "document_sha256": "string", "attempts": [ { "id": "string", "state": "received", "created_at": "2019-08-24T14:15:22Z" } ], "errors": [ { "code": "string", "source": "string", "message": "string", "field": "string", "fix_hint": "string", "who_fixes": "us", "related": [ { "code": "string", "source": "string" } ] } ], "documents": [ { "kind": "string", "sha256": "string", "href": "string" } ], "created_at": "2019-08-24T14:15:22Z", "updated_at": "2019-08-24T14:15:22Z", "deadline_at": "2019-08-24T14:15:22Z" } ], "total": 0, "page": 0, "page_size": 0, "counts_by_state": { "property1": 0, "property2": 0 }}Eingegangene und abgelehnte Rechnungen je Tag und Übermittlungsweg GET
Bei jedem Abruf aus dem Speicher berechnet. received zählt Rechnungen nach dem UTC-Tag ihres Eingangs; rejected zählt Rechnungen, die jetzt abgelehnt sind, nach dem UTC-Tag ihrer letzten Änderung. Ein Tag ohne Rechnungen hat Nullen, damit ein Diagramm keine Lücken hat. Im selben Umfang wie GET /invoices.
Eine Rechnung oder Gutschrift als kanonisches JSON übermitteln POST
Der Service prüft das Dokument sofort gegen das kanonische Modell und die Vorprüfungen und antwortet mit 422, wenn eine davon fehlschlägt. Alles danach läuft asynchron (Erstellung, offizielle Validierung, Übermittlung an den Übermittlungsweg, Status) und wird über Statusereignisse gemeldet. Eine korrigierte erneute Übermittlung einer abgelehnten Rechnung verwendet dieselbe invoice_ref und einen neuen Idempotency-Key; der Service verknüpft die Versuche. In der Produktion wird ein ERP-Export nur gelesen, wenn die Connector-Einstellungen des Kunden seinen eigenen Verkäufer und seine eigene Zahlung enthalten, nicht das Beispiel des Mappings: sonst 422 connector-settings-missing, mit dem, was fehlt. Eine Sandbox liest ihn wie bisher mit dem Beispiel.