Romániában: CIUS-RO előellenőrzés, SPV-beadás, normalizált státusz, aláírt válasz és beérkező szállítói számlák.
← Vissza az API dokumentációhoz
Az első számla 6 lépésben
- Futtassa a POST /v1/invoices/{id}/efactura/validate hívást. Az előellenőrzés (Romániában: CIUS-RO) semmit nem küld a nemzeti e-számlázási rendszernek, és pontosan megmondja, mit utasítanának el.
- Nyújtsa be a POST /v1/invoices/{id}/efactura/submit hívással, mindig Idempotency-Key fejléccel. Egy submission_id és egy status értéket kap.
- Kérdezze le a GET /v1/efactura/submissions/{id} végpontot, amíg el nem éri az accepted vagy rejected értéket.
- Friss lekérdezést a nemzeti e-számlázási rendszertől (Romániában: ANAF) a POST /v1/efactura/submissions/{id}/refresh hívással kényszeríthet ki — ez a percenkénti 10-es keretbe számít.
- Az ANAF (Románia) aláírt válaszát tartalmazó archívumot a GET /v1/efactura/submissions/{id}/download hívással töltheti le.
Minden végpont
| Metódus | Végpont | Scope | Idempotency-Key | Kérés / perc |
|---|---|---|---|---|
| GET | /invoices/{invoice_id}/xml UBL / CIUS-RO XML (Románia) letöltése | invoices:read | — | 120 |
| POST | /invoices/{invoice_id}/efactura/validate Előellenőrzés (Romániában: CIUS-RO) — érvényesítés küldés nélkül | efactura:read | — | 120 |
| POST | /invoices/{invoice_id}/efactura/submit A számla beküldése az ANAF-hoz (SPV, Románia) | efactura:submit | kötelező | 10 |
| GET | /efactura/submissions ANAF-beküldések (Románia) listázása | efactura:read | — | 120 |
| GET | /efactura/submissions/{submission_id} Egy beküldés lekérése | efactura:read | — | 120 |
| POST | /efactura/submissions/{submission_id}/refresh Kérdezze le az ANAF-tól (Románia) az aktuális állapotot | efactura:read | — | 10 |
| GET | /efactura/submissions/{submission_id}/download Az aláírt válasz archívumának letöltése | efactura:read | — | 120 |
| GET | /efactura/inbox Szállítói számlák, amelyeket SPV-n (Románia) kaptak | efactura:read | — | 120 |
| GET | /efactura/inbox/{inbound_id} Egy bejövő számla lekérése | efactura:read | — | 120 |
| GET | /efactura/inbox/{inbound_id}/download A bejövő számla archívumának letöltése | efactura:read | — | 120 |
| POST | /efactura/inbox/sync Új SPV-üzenetek (Románia) lekérése a postaládába | efactura:read | — | 10 |
Mi a 4invoices API
bash
# CIUS-RO preflight. Sends NOTHING to ANAF.
curl -sS -X POST "https://api.4invoices.net/v1/invoices/inv_01J7ABC/efactura/validate?include_xml=true" \
-H "Authorization: Bearer $ACCESS_TOKEN"
# → {"invoice_id":"inv_01J7ABC","valid":false,
# "errors":["buyer.county is required for RO buyers"],
# "xml_base64":"PD94bWwg..."}bash
curl -sS -X POST https://api.4invoices.net/v1/invoices/inv_01J7ABC/efactura/submit \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H 'Idempotency-Key: efactura-inv_01J7ABC-1'
# → {"submission_id":"sub_01J7XYZ","status":"queued"}python
import time, requests
BASE = "https://api.4invoices.net/v1"
TERMINAL = {"accepted", "rejected"}
H = {"Authorization": f"Bearer {token}"}
def wait_for_anaf(submission_id, timeout=900):
deadline = time.time() + timeout
delay = 15
while time.time() < deadline:
r = requests.get(f"{BASE}/efactura/submissions/{submission_id}", headers=H, timeout=30)
r.raise_for_status()
status = r.json()["status"]
if status in TERMINAL:
return r.json()
# /refresh asks ANAF directly and shares the 10/min submit bucket.
requests.post(f"{BASE}/efactura/submissions/{submission_id}/refresh", headers=H, timeout=30)
time.sleep(delay)
delay = min(delay * 2, 120)
raise TimeoutError(submission_id)bash
# Pull new SPV messages, then read the inbound supplier invoices.
curl -sS -X POST https://api.4invoices.net/v1/efactura/inbox/sync \
-H "Authorization: Bearer $ACCESS_TOKEN"
curl -sS "https://api.4invoices.net/v1/efactura/inbox?limit=50" \
-H "Authorization: Bearer $ACCESS_TOKEN"
# ANAF allows roughly ONE message-list call per minute per CIF,
# ezért a /inbox/sync a 10/perc beküldési keretet terheli. Cronnal ütemezze, ne lekérdezgesse.https://api.4invoices.net/v1 · https://api.4invoices.net/v1/openapi.json
Nemzeti e-számlázás (ANAF e-Factura, Románia)
Hibák
| Státusz | Típus | Kód |
|---|---|---|
| 422 | invalid_request_error | cius_ro_incomplete |
Gyakori hibák
- Normalizált életciklus: not_sent → validating → queued → sent → processing → accepted | rejected | error.
- Az accepted jogilag érvényes továbbítást jelent. A rejected azt jelenti, hogy a nemzeti e-számlázási rendszer (Romániában: ANAF) elutasította: javítsa és küldje be újra. Az error a mi oldalunkon fellépő átviteli hiba, és biztonságosan újrapróbálható.
- A beküldés visszafordíthatatlan: ugyanannak a számlának egy második példányát már nem lehet visszavonni a nemzeti e-számlázási rendszerből. Ezért kötelező az Idempotency-Key.
- A GET /v1/invoices/{id}/xml mindenféle beküldés nélkül adja meg az UBL / CIUS-RO XML-t (Románia) — a saját archívumhoz vagy egy audithoz.
- Postafiók: a POST /v1/efactura/inbox/sync lekéri az új üzeneteket, a GET /v1/efactura/inbox listázza őket, a /download pedig letölti minden bejövő számla archívumát.
- Az e-Factura végpontok csak román tenantok esetén működnek; egyébként 404-et kap.
Kérdések és válaszok fejlesztőknek
Mennyi idő alatt fogad el az ANAF (Románia) egy számlát?
Változó, másodpercektől órákig. Ne blokkolja az értékesítést: küldje be aszinkron módon, és kezelje az accepted és rejected állapotot eseményként.
Megkaphatom a CIUS-RO XML-t (Románia) anélkül, hogy bármit küldenék az ANAF-nak?
Igen. A GET /v1/invoices/{id}/xml beküldés nélkül állítja elő a bizonylatot, a /efactura/validate pedig include_xml=true paraméterrel base64 kódolással adja vissza.
Milyen gyakran futtathatom az inbox/sync hívást?
Legfeljebb percenként 10-szer, de a gyakorlatban Romániában az ANAF nagyjából percenként egy üzenetlista-hívást enged CIF-enként. Futtassa cronból, néhány percenként.
Mit tegyek, ha az állapot error marad?
Az error a mi oldalunkon fellépő átviteli vagy hitelesítési hiba, így biztonságosan újrapróbálható. Ha tartósan fennáll, küldje el a request_id értéket a támogatásnak.