Docs
5

Erori și catalogul

Problem JSON și toate codurile din catalog.

  • În sandbox

În cuvinte simple

Când un apel eșuează, răspunsul arată dacă este greșită cererea sau factura. Pentru o factură, un cod indică câmpul din exportul clientului și cine îl corectează. Partenerul corectează cererile și datele greșite; noi corectăm propria noastră mapare și reîncercăm erorile din partea canalului.

Sfat

400 privește formatul cererii către API-ul nostru. 422 privește factura, iar codul ei din catalog indică câmpul din exportul ERP. Nu le confundați.

Problem JSON

Fiecare răspuns de eroare este problem JSON (RFC 9457): type, title și status, cu detail când mai este ceva de spus. Un 422 adaugă errors, o listă de constatări. Fiecare are un code din catalog, cine o corectează (who_fixes), un fix_hint și un message, plus un field când constatarea privește un singur câmp (consultați pagina 3.2). Linia evidențiată este codul.

curl -X POST "https://api-sandbox-eu.eurinvoice.com/invoices/xml?route=PEPPOL&invoice_ref=INV-2026-0051" \
  -H "Authorization: Bearer <your-api-key>" \
  -H "Content-Type: application/xml" \
  -H "Idempotency-Key: order-2026-0051" \
  --data-binary @not-an-invoice.xml
Răspuns422 Unprocessable Content
{
  "type": "https://eurinvoice.com/problems/validation-failed",
  "title": "The invoice did not pass the checks",
  "errors": [
    {
      "code": "EI-XML-TYPE",
      "fix_hint": "Send the invoice itself, in the format agreed for the route.",
      "who_fixes": "erp",
      "source": "XML-safety",
      "message": "The file is not an invoice in a format this route accepts. Please send the invoice in the agreed format."
    }
  ],
  "status": 422
}
Înregistrat pe 7 oct. 2026. XML bine format care nu este o factură. Apelul complet este pe pagina 3.3.

O cale pe care serviciul nu o are primește 404 cu {"detail": "Not Found"}, JSON simplu.

Ce înseamnă fiecare cod

CodSemnificațieCe faceți
400Cererea nu poate fi citită: nu este JSON, un câmp este greșit sau Idempotency-Key lipsește ori nu are între 8 și 100 de caractere.Corectați cererea.
401Lipsește cheia sau cheia este necunoscută.Corectați cheia.
403Cheia nu are domeniul de care are nevoie apelul sau apelul privește datele altui client (forbidden).Folosiți o cheie cu domeniul potrivit sau clientul potrivit.
404Nu există factura, documentul, intrarea din catalog sau elementul din lista de gestionare pentru acest client.Verificați ID-ul.
409Idempotency-Key a fost folosit cu un corp diferit sau prima lui cerere încă rulează. O anulare a venit prea târziu. Datele de autentificare există deja sau au fost revocate.Corectați apelul.
413Corpul cererii depășește 5 MB (payload-too-large).Trimiteți un fișier mai mic.
415Tipul de conținut nu este XML sau PDF ori un corp declarat PDF nu este un PDF.Corectați tipul de conținut.
422Factura nu a trecut o verificare. Nu s-a pus nimic în coadă.Corectați constatările marcate erp. Cele marcate us ne revin nouă.
429Prea multe cereri pentru cheie.Așteptați secundele din Retry-After, apoi reîncercați.
500Factura nu a putut fi verificată. Ceva a eșuat la noi.Reîncercați același apel cu aceeași cheie.
503Serviciul este ocupat (busy) sau un apel pentru date de autentificare a ajuns la un proces fără cheie principală setată.Reîncercați același apel după numărul de secunde din Retry-After.

Fiecare 409 are propriul type de problemă, sub https://eurinvoice.com/problems/: idempotency-conflict, request-in-progress, already-submitted, send-in-progress, dead-letter, credential-exists și credential-revoked. Citiți type, nu title, pentru a le deosebi. Un 413 nu este stocat pentru Idempotency-Key, așa că aceeași cheie poate fi folosită din nou cu un corp mai mic.

Un 429 vine pentru fiecare client și domeniu, cu Retry-After (consultați limitele). După un 202 nu retrimiteți niciodată. Erorile din partea rețelei care pot trece la o nouă încercare sunt reîncercate după programul nostru, iar o respingere definitivă ajunge pe lista de gestionare.

Cine acționează

Fiecare cod din catalog are un singur responsabil.

ResponsabilCine este
erpPartenerul: exportul ERP sau datele sale de bază.
useurinvoice: mapare, serializator sau configurare.
businessCompania vânzătorului, împreună cu cumpărătorul sau cu contabilul său.
clientClientul, adică vânzătorul: înregistrare, date de autentificare sau autorizare.
buyerPartea cumpărătorului.
routeOperatorul canalului, adică o autoritate, un punct de acces sau o platformă: așteptați și reîncercați.

Partenerul corectează 400, 401, 403, 409, 413 și 415. Un 422 conține constatări și fiecare indică cine o corectează: erp este partenerul, us este eurinvoice.

Catalogul

Catalogul conține un cod pentru fiecare constatare. Această pagină arată un eșantion de douăsprezece, unul sau două pentru fiecare familie de reguli. Tastați un cod și apăsați Enter pentru a sări la el. Cu o cheie, GET /catalogue/{code} explică orice cod (consultați căutarea în catalog). Catalogul complet este destinat partenerilor: solicitați-l prin accesul la sandbox.

CodCine acționeazăCe este greșitCe trebuie făcut
EI-ID-IBANVerificările noastre, verificarea identificatorilorPartenerIBAN-ul nu trece verificarea mod-97.Corectați contul bancar în setările companiei.
EI-SCHEMAVerificările noastre, schemăeurinvoiceJSON-ul facturii nu corespunde modelului canonic: un câmp lipsă sau necunoscut, un tip sau un cod greșit ori o regulă de structură a canalului.Citiți calea JSON din eroare și corectați maparea clientului.
EI-TOTALS-MISMATCHVerificările noastre, verificare preliminarăPartenerTotalurile trimise de ERP (erp_totals) diferă de totalurile calculate din linii, așa că documentul nu ar corespunde evidențelor contabile ale ERP-ului.Găsiți diferența (de obicei rotunjirea pe linie față de rotunjirea pe document sau o linie de reducere omisă din export) și corectați exportul sau maparea.
BR-CO-16EN 16931 și sintaxă, validatorul canaluluieurinvoiceSuma de plată (BT-115) nu este egală cu totalul cu TVA (BT-112) minus suma plătită (BT-113) plus rotunjirea (BT-114).Calculăm totalurile din linii, așa că acest cod apare doar când totalurile au venit din exterior (un fișier transmis mai departe neschimbat) sau au fost editate. Recalculați totalurile din linii și retrimiteți.
EI-XML-DTDEN 16931 și sintaxă, validatorul canaluluiPartenerXML-ul declară un DOCTYPE. UBL, CII și FA(3) nu folosesc niciodată așa ceva, iar un DOCTYPE este calea prin care entitățile externe, descărcările de DTD de la distanță și expansiunea entităților pătrund într-un fișier (XXE). Fișierul este refuzat înainte ca vreun validator sau canal să-l citească.Exportați factura fără linia DOCTYPE. Dacă ERP-ul o adaugă intenționat, semnalați acest lucru furnizorului ERP: niciun format de facturare electronică nu o folosește.
EI-XML-SYNTAXEN 16931 și sintaxă, validatorul canaluluiPartenerFișierul nu este un XML bine format: de exemplu este trunchiat, codificarea sa nu corespunde declarației sau un caracter precum & nu este escapat. Niciun validator nu îl poate citi.Exportați din nou fișierul și deschideți-l în orice vizualizator XML. Căutați un fișier trunchiat, o codificare diferită de declarație sau un & neescapat.
EI-XML-TYPEEN 16931 și sintaxă, validatorul canaluluiPartenerXML-ul este bine format, dar nu este o factură pe care o validăm: nu este un Invoice sau CreditNote UBL, o factură CII UN/CEFACT sau o factură KSeF FA(3) (de exemplu un Order UBL sau un fișier FA(2) mai vechi).Trimiteți factura propriu-zisă, în formatul convenit pentru canal.
EI-PEPPOL-NO-ROUTEPeppol, răspunsul rețelei, necesită o rețea conectatăPartenerPunctul de acces nu a găsit niciun destinatar pentru identificatorul cumpărătorului: cumpărătorul nu este înregistrat în Peppol pentru acest tip de document. Definitiv pentru această trimitere.Comparați ID-ul Peppol al cumpărătorului din fișa cumpărătorului din ERP cu directorul Peppol; dacă cumpărătorul nu este în Peppol, conveniți cu el o altă modalitate de transmitere.
PEPPOL-EN16931-R001Peppol, validatorul canaluluieurinvoiceProcesul de afaceri (BT-23) ar trebui să fie prezent. Mustang l-a raportat ca notificare pe fișierul nostru ZUGFeRD EN 16931, care nu este un document Peppol.Nicio acțiune pentru ZUGFeRD; fișierul nostru UBL Peppol scrie întotdeauna procesul.
BR-DE-5Germania, validatorul canaluluiPartenerLipsește numele persoanei de contact a vânzătorului (BT-41).Adăugați în setările companiei o persoană sau un departament de contact pentru facturare.
KSEF-440Polonia, răspunsul rețelei, necesită o rețea conectatăeurinvoiceKSeF deține deja o factură cu același NIP al vânzătorului, același tip de factură (RodzajFaktury) și același număr (P_2); păstrează această cheie timp de 10 ani. Cheia este numărul, nu fișierul: în TEST, un fișier diferit sub un număr acceptat a primit și el 440. Răspunsul indică numărul KSeF și sesiunea exemplarului acceptat primul. Un număr respins de KSeF (430 sau 450) nu este reținut și poate fi folosit din nou.Nu retrimiteți. Înregistrați numărul KSeF original din răspuns și raportați factura ca acceptată sub acel număr.
BR-RO-001România, validatorul canaluluieurinvoiceIdentificatorul specificației (BT-24) nu are valoarea CIUS-RO.Setați profilul ro-cius, care scrie identificatorul CIUS-RO 1.0.1.

Pe această pagină