Lista i wyszukiwanie faktur
- W sandboxie
Prostymi słowami
Klucz klienta widzi faktury własnego klienta; operator widzi faktury wszystkich klientów albo jednego klienta po podaniu client. Wiersze zawierają to, co GET /invoices/{id}, bez documents, i nie zawierają treści faktury: nie ma nabywcy ani kwot,
ani daty wystawienia (dla Rumunii i Polski wynika z niej deadline_at, z dokładnością do kilku dni). Nieznany parametr daje odpowiedź 400.
apiKeyAuthorizationBearer <token>Klucz należy wysyłać jako token typu bearer: Authorization: Bearer <your-api-key>. Wywołanie stanu usługi jest jedynym, które nie wymaga klucza.
q?stringFragment invoice_ref lub numeru faktury, bez rozróżniania wielkości liter. Najwyżej 100 znaków.
length <= 100route?array<>Jeden lub więcej kanałów, oddzielonych przecinkami.
state?array<>Jeden lub więcej stanów, oddzielonych przecinkami.
client?stringFiltr operatora do jednego klienta. Klucz klienta może podać tylko własnego klienta; każdy inny daje odpowiedź 404. Inny kształt daje odpowiedź 400.
^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$received_from?stringPierwszy dzień UTC, w którym faktura została odebrana, włącznie.
datereceived_to?stringOstatni dzień UTC, w którym faktura została odebrana, włącznie.
datesort?stringWedług czasu odbioru. Remisy rozstrzyga id, więc strona nie zmienia kolejności między wywołaniami.
"newest""newest""oldest"page?integer1 <= value1page_size?integer252550100200Jedna strona wyników.
application/json- response
data*array<>total*integerWyniki przed podziałem na strony.
page*integerZwrócona strona. Strona poza końcem jest zastępowana ostatnią.
page_size*integercounts_by_state*Wyniki według stanu, ze wszystkimi filtrami oprócz state. Stan bez wyników jest pomijany.
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 }}Faktury odebrane i odrzucone według dnia i kanału GET
Obliczane ze zbioru przy każdym wywołaniu. received liczy faktury według dnia UTC ich odbioru; rejected liczy faktury odrzucone obecnie według dnia UTC ich ostatniej zmiany. Dzień bez faktur ma zera, więc wykres nie ma luk. Zakres jak w GET /invoices.
Przesłanie faktury lub noty kredytowej jako kanonicznego JSON POST
Usługa od razu sprawdza dokument z modelem kanonicznym i kontrolami wstępnymi i odpowiada 422, jeśli któraś z nich się nie powiedzie. Wszystko, co dzieje się potem, przebiega asynchronicznie (budowanie, oficjalna walidacja, przesłanie do kanału, statusy) i jest zgłaszane zdarzeniami statusu. Poprawione ponowne przesłanie odrzuconej faktury używa tego samego invoice_ref i nowego Idempotency-Key; usługa łączy te próby. Na produkcji eksport z ERP jest odczytywany tylko wtedy, gdy ustawienia konektora klienta zawierają jego własnego sprzedawcę i płatność, a nie przykład z mapowania: w przeciwnym razie 422 connector-settings-missing ze wskazaniem, czego brakuje. Sandbox odczytuje go z przykładem, jak dotąd.