Valsts e-rēķinu sistēma caur API

Iepriekšēja pārbaude (Rumānijā – CIUS-RO), iesniegšana sistēmā, normalizēts statuss, parakstīta atbilde un ienākošā piegādātāju kaste.

← Atpakaļ uz API dokumentāciju

Pirmais rēķins 6 soļos

Palaidiet POST /v1/invoices/{id}/efactura/validate. Iepriekšējā pārbaude (Rumānijā – CIUS-RO) neko nenosūta valsts e-rēķinu sistēmai un precīzi pasaka, kas tiktu noraidīts.
Iesniedziet ar POST /v1/invoices/{id}/efactura/submit vienmēr ar Idempotency-Key. Saņemsiet submission_id un statusu.
Vaicājiet GET /v1/efactura/submissions/{id}, līdz statuss kļūst par accepted vai rejected.
Piespiediet jaunu vaicājumu valsts e-rēķinu sistēmai ar POST /v1/efactura/submissions/{id}/refresh — tas patērē 10 minūtē grupu.
Lejupielādējiet valsts e-rēķinu sistēmas parakstīto atbilžu arhīvu ar GET /v1/efactura/submissions/{id}/download.

Visi galapunkti

Metode	Galapunkts	Scope	Idempotency-Key	Pieprasījumi / minūtē
GET	/invoices/{invoice_id}/xml Lejupielādēt UBL XML (Rumānijā – CIUS-RO)	invoices:read	—	120
POST	/invoices/{invoice_id}/efactura/validate Iepriekšēja pārbaude (Rumānijā – CIUS-RO) — pārbaudīt, neko nesūtot	efactura:read	—	120
POST	/invoices/{invoice_id}/efactura/submit Iesniegt rēķinu valsts e-rēķinu sistēmā	efactura:submit	obligāts	10
GET	/efactura/submissions Uzskaitīt iesniegumus e-rēķinu sistēmā	efactura:read	—	120
GET	/efactura/submissions/{submission_id} Iegūt vienu iesniegumu	efactura:read	—	120
POST	/efactura/submissions/{submission_id}/refresh Pajautāt valsts e-rēķinu sistēmai pašreizējo stāvokli	efactura:read	—	10
GET	/efactura/submissions/{submission_id}/download Lejupielādēt parakstīto atbilžu arhīvu	efactura:read	—	120
GET	/efactura/inbox Caur valsts e-rēķinu sistēmu saņemtie piegādātāju rēķini	efactura:read	—	120
GET	/efactura/inbox/{inbound_id} Iegūt vienu ienākošo rēķinu	efactura:read	—	120
GET	/efactura/inbox/{inbound_id}/download Lejupielādēt ienākošā rēķina arhīvu	efactura:read	—	120
POST	/efactura/inbox/sync Ielādēt jaunus sistēmas ziņojumus ienākošajā kastē	efactura:read	—	10

Kas ir 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,
# tāpēc /inbox/sync tiek ieskaitīts 10/min iesniegšanas grupā. Ieplānojiet to ar cron, nevis aptaujājiet.

https://api.4invoices.net/v1 · https://api.4invoices.net/v1/openapi.json

Valsts e-rēķinu sistēma

Kļūdas

Statuss	Tips	Kods
422	invalid_request_error	cius_ro_incomplete

Biežākās kļūdas

Normalizētais cikls: not_sent → validating → queued → sent → processing → accepted | rejected | error.
accepted nozīmē juridiski nosūtīts. rejected nozīmē, ka valsts e-rēķinu sistēma to noraidīja: izlabojiet un iesniedziet atkārtoti. error ir mūsu puses pārraides kļūda, un to drīkst droši atkārtot.
Iesniegšana ir neatgriezeniska: tā paša rēķina otru eksemplāru nevar atsaukt no valsts e-rēķinu sistēmas. Tāpēc Idempotency-Key ir obligāts.
GET /v1/invoices/{id}/xml sniedz UBL XML (Rumānijā – CIUS-RO) bez jebkādas iesniegšanas — jūsu arhīvam vai auditam.
Ienākošā kaste: POST /v1/efactura/inbox/sync iegūst jaunus ziņojumus, GET /v1/efactura/inbox tos uzskaita, bet /download lejupielādē katra ienākošā rēķina arhīvu.
e-Factura galapunkti darbojas tikai Rumānijas tenant; citādi saņemsiet 404.

Izstrādātāju jautājumi un atbildes

Cik ilgā laikā valsts e-rēķinu sistēma pieņem rēķinu?

Tas mainās — no sekundēm līdz stundām. Nebloķējiet pārdošanu: iesniedziet asinhroni un uztveriet accepted un rejected kā notikumus.

Vai varu iegūt XML (Rumānijā – CIUS-RO), neko nenosūtot valsts e-rēķinu sistēmai?

Jā. GET /v1/invoices/{id}/xml ģenerē dokumentu bez iesniegšanas, un /efactura/validate to atgriež base64 kodējumā, ja include_xml=true.

Cik bieži varu palaist inbox/sync?

Ne vairāk kā 10 izsaukumus minūtē, bet praksē Rumānijas ANAF atļauj aptuveni vienu ziņojumu saraksta pieprasījumu minūtē uz nodokļu maksātāja kodu (CIF). Palaidiet to ar cron ik pa dažām minūtēm.

Ko darīt, ja statuss paliek error?

error ir mūsu puses pārraides vai autentifikācijas kļūda, tāpēc to drīkst droši atkārtot. Ja tā saglabājas, nosūtiet request_id atbalstam.

Skatīt arī