Aceeași factură, în orice format european.
Convertești facturi între e-Factura CIUS-RO (UBL 2.1) și UN/CEFACT CII și extragi XML-ul dintr-un PDF Factur-X sau ZUGFeRD — totul printr-un API, fără să stochezi nimic.
CIUS-RO e dialectul UBL cerut de ANAF; CII e formatul folosit în Franța (Factur-X), Germania (ZUGFeRD) și în multe schimburi B2B din UE. Amândouă pornesc din același nucleu EN16931. Noi traducem între ele și scoatem factura din PDF — în memorie, cu zero retenție.
// corp: factura CIUS-RO (UBL)
// → { data: { standard: "CII",
// guideline: "urn:cen.eu:en16931:2017", xml: "<rsm:CrossIndustryInvoice…" } }
POST /interop/v1/facturx-extract // corp: PDF Factur-X
{ "data": {
"format_detectat": "CII",
"xml": "<?xml version=\"1.0\"?><rsm:CrossIndustryInvoice…"
} }
- Formate
- CIUS-RO UBL 2.1 ⇄ UN/CEFACT CII
- Nucleu
- EN16931 (semantica comună)
- Factur-X · ZUGFeRD · XRechnung
- Operațiuni
- ubl-to-cii · cii-to-ubl · facturx-extract
- Retenție
- niciuna
Aceeași factură, două lumi de format care nu se vorbesc.
Între e-Factura pe care o cere ANAF și factura pe care o așteaptă un partener european se află o traducere de format — aceeași semantică, sintaxe diferite — pe care cineva trebuie s-o facă corect.
UBL vs CII
CIUS-RO e UBL 2.1 (rădăcină Invoice / CreditNote). CII e UN/CEFACT (rădăcină CrossIndustryInvoice). Aceleași câmpuri, alte nume de elemente și altă ordine — strictă în ambele.
Factur-X / ZUGFeRD
În Franța și Germania factura circulă ca PDF cu XML-ul de factură încorporat (PDF/A-3). Ca s-o procesezi structurat, trebuie întâi să scoți XML-ul din PDF.
Ordinea elementelor
Secvența din schema CII e strictă: un element pus greșit și fișierul e respins. Mapping-ul UBL↔CII nu e o simplă redenumire, ci o rescriere în ordinea corectă.
Totaluri și TVA
Bazele, cotele și categoriile de TVA trebuie să se regăsească fidel de o parte și de alta. O rotunjire mutată și totalurile nu mai închid.
Nucleu comun, ambalaje diferite
Ambele derivă din EN16931 — aceeași semantică de bază. Diferența e sintactică, exact felul de muncă repetitivă și fără valoare care se pretează la automatizare.
Nu e produsul tău
Clientul nu te plătește fiindcă știi pe de rost secvența ram:ApplicableHeaderTradeSettlement. Te plătește pentru produsul tău. Traducerea de format e cost pur.
Trei operațiuni. O traducere în fiecare sens și o despachetare.
Fiecare e un apel POST independent. Folosești pe cea de care ai nevoie — conversie într-un sens, în celălalt, sau extragere din PDF.
/ubl-to-cii
UBL → CII
Trimiți o factură CIUS-RO (UBL 2.1) și primești echivalentul UN/CEFACT CII, pe nucleul EN16931 — părți, linii, TVA și totaluri mapate în secvența corectă a schemei CII. Pentru când trimiți către un partener european.
/cii-to-ubl
CII → UBL
Trimiți o factură CII și primești o e-Factura CIUS-RO validă. Conversia trece prin același motor de emisie ca produsul e-Factura, deci moștenește derivarea categoriilor de TVA, totalurile calculate și nomenclatoarele.
/facturx-extract
Extrage din Factur-X
Trimiți octeții unui PDF Factur-X / ZUGFeRD / XRechnung și primești XML-ul de factură încorporat, plus formatul detectat (CII sau UBL). Un prim pas înainte de validare sau conversie.
Factura ta trece prin conversie, nu prin arhiva noastră.
Ăsta e răspunsul la „de ce aș trimite factura mea la un terț ca s-o convertesc”. Pentru că, practic, n-o lași nicăieri — convertim și uităm.
Procesare în memorie
XML-ul și PDF-ul nu se scriu niciodată pe disc. Intră în request, sunt convertite sau despachetate în memorie și dispar când răspunsul pleacă. Nu există o factură a ta la noi.
Conversie locală
Traducerea de format și extragerea din PDF rulează la noi, pe serverul care ține răspunsul tău. Nu trimitem factura la un serviciu extern de conversie.
Loguri fără conținut
Ce reținem e un cod de rezultat și o durată — atât. Numărul facturii, părțile, sumele nu intră în niciun log, nici la noi, nici la un serviciu de observabilitate.
Fără SPV
Nu depunem nimic în locul tău și nu ne conectăm la SPV. Convertim formatul; ce faci cu rezultatul — depui, trimiți, arhivezi — rămâne la tine, cu credențialele tale.
Nu mutăm doar etichete. Păstrăm sensul.
Mapping-ul pornește de la nucleul EN16931 comun ambelor formate, iar sumele se preiau din sursă — fără recalcul care să introducă drift.
Nucleul EN16931
Numărul, datele, tipul documentului, părțile (vânzător/cumpărător cu adresă, cod fiscal, cod de TVA), liniile și totalurile pe categorii de TVA — semantica de bază pe care ambele formate o împart, mapată câmp cu câmp.
Secvența corectă a schemei
La UBL → CII emitem elementele exact în ordinea cerută de schema CII (ExchangedDocument, apoi liniile, apoi acordul, livrarea și decontarea). Un fișier în ordine, nu doar cu numele traduse.
Sume din sursă
La UBL → CII, neturile de linie, subtotalurile și totalurile se citesc direct din UBL-ul sursă, unde sunt autoritative. La CII → UBL, totalurile le recalculează motorul de emisie e-Factura din liniile primite.
CIUS-RO garantat la retur
Conversia CII → UBL nu scrie UBL „de mână”: trece prin motorul e-Factura, deci rezultatul respectă regulile CIUS-RO. Pentru verdictul complet, treci rezultatul prin e-Factura /validate.
Formatele care contează în UE, plus PDF-ul.
Nucleul factură al fiecărui format, mapat în ambele sensuri, plus extragerea din cele trei ambalaje PDF uzuale.
Acoperim nucleul EN16931 al facturii în ambele formate, plus extragerea din Factur-X / ZUGFeRD / XRechnung. Dacă întâlnești un câmp sau un profil pe care nu-l tratăm corect, scrie-ne — cazurile reale au prioritate în ce construim.
O factură intră într-un format. Iese în celălalt.
Trimiți XML-ul (brut sau base64), primești XML-ul convertit. Fără SDK obligatoriu — clientul HTTP pe care îl ai deja.
# cii-to-ubl: o factură CII → e-Factura CIUS-RO validă (via motorul e-Factura)
curl "https://oneapi.ro/api/anaf/v1/interop/cii-to-ubl" \
-H "Authorization: Bearer $ONEAPI_TOKEN" \
-H "Content-Type: application/xml" \
--data-binary @factura-cii.xml
# → 200 OK
{ "data": {
"standard": "CIUS-RO",
"xml": "<Invoice xmlns=…>…</Invoice>",
"meta": { "totals": {…}, "vat_breakdown": […] }
} }
Cod, mesaj și câmpul implicat
Dacă trimiți altceva decât formatul așteptat — un UBL la endpointul CII, un PDF fără XML încorporat — primești un 422 cu un cod stabil (de ex. factura_x_fara_xml), un mesaj și, unde e cazul, câmpul implicat. Suficient ca să corectezi din prima.
HTTP/1.1 422 Unprocessable Content
{ "eroare": {
"cod": "factura_x_fara_xml",
"mesaj": "PDF-ul nu conține un XML de factură încorporat.",
"camp": null,
"request_id": null
} }
Înainte de prima conversie.
Restul, în întrebări frecvente și în documentație.