oneapiDeclari transportul de marfă, printr-un apel.
Transformă un JSON de business în XML de declarație e-Transport valid (schema v2), îl validează cu XSD-ul și Schematron-ul oficial ANAF și îl randează PDF — totul printr-un API, fără să stochezi nimic.
Nu e un set de date, ci un instrument. Trimiți transportul ca obiect, primești înapoi XML-ul, verdictul de validare și, la cerere, PDF-ul de sinteză. Procesarea e în memorie; conținutul nu atinge un disc de-al nostru.
{
"declarant": { "cui": "RO12345678" }, // obiectul tău de business
"operatiune": "30", // TTN — transport intern
"bunuri": [ { "cod_tarifar": "0409", "cantitate": 500 } ]
}
// → { valid: true, xml: "<eTransport…", meta: { … } }
- Standard
- e-Transport declarație v2
- Namespace
- mfp:anaf:dgti:eTransport
- Operațiuni
- build · validate · parse · render
- Nomenclatoare
- operațiuni, NC, PTF, birou vamal
- Retenție
- niciuna
Conformitatea e-Transport e grea. Și nu e produsul tău.
Între obiectul tău de business și un XML pe care ANAF îl acceptă la declararea transportului se află un strat de reguli care se schimbă și pe care cineva trebuie să-l țină la zi.
Declarație v2
Declarația nu e un JSON, ci un XML cu namespace-ul mfp:anaf:dgti:eTransport:declaratie:v2, cu zeci de elemente ordonate și cardinalități stricte. Un câmp lipsă, o ordine greșită, și fișierul e respins.
Nomenclatoare
Tipuri de operațiune (transport intern, achiziție/livrare intracomunitară, import, export), coduri tarifare NC pentru bunuri, unități de măsură, puncte de trecere a frontierei și birouri vamale. Liste oficiale, cu valori permise.
Zeci de scenarii de transport
Transport intern, AIC și LIC, import și export, tranzit, transfer între gestiuni. Fiecare are propriile reguli despre ce loc de plecare și de sosire apar — locație internă sau punct de frontieră — și ce câmpuri sunt obligatorii.
Schematron
Validarea reală nu e doar împotriva schemei XSD, ci și a regulilor de business ANAF, scrise în Schematron. Zeci de aserțiuni despre coerența datelor — bunuri, partener, transport, locații — care trebuie rulate corect.
Locații și frontieră
Un loc de plecare sau de sosire e ori o locație internă (județ, localitate, stradă), ori un punct de trecere a frontierei cu birou vamal. Regulile despre care variantă e permisă depind de tipul operațiunii.
Reguli care se schimbă
Specificația se revizuiește, nomenclatoarele se completează, aserțiunile se ajustează. Ce era valid anul trecut poate fi respins azi, iar tu afli din refuz, nu din anunț.
Patru operațiuni și un nomenclator.
Fiecare e un apel POST independent. Le folosești pe cea de care ai nevoie; nu ești obligat să treci prin toate.
/build
Construiește
Trimiți transportul ca JSON de business, primești XML de declarație v2 valid. Ordinea elementelor, namespace-ul, bunurile, partenerul, transportul și locațiile sunt puse corect de noi, din obiectul tău.
/validate
Validează
Rulezi un XML existent prin XSD-ul și Schematron-ul oficial local. Primești verdictul, ce s-a verificat (XSD și Schematron), lista de erori și lista de avertismente.
/parse
Parsează
Un XML de declarație primit devine un JSON curat, cu câmpurile despachetate — declarant, operațiune, bunuri, partener, transport, locații, documente — ca să-l poți citi fără să atingi XML-ul.
/render
Randează
Din declarație sau din XML iese un PDF de sinteză lizibil pentru om, generat local. Vizualizarea pentru șofer sau pentru dosarul transportului, fără un serviciu extern de randare.
/codes
Nomenclatoare
Listele oficiale pe care le acceptă declarația — tipuri de operațiune, coduri tarifare NC, unități de măsură, puncte de trecere a frontierei, birouri vamale — servite ca referință, ca să validezi din formular.
Transporturile tale nu ajung nicăieri. Nici la noi, nici la ANAF.
Ăsta e răspunsul la „de ce aș trimite datele transporturilor mele la un terț”. Pentru că, practic, nu le trimiți nicăieri — procesăm și uităm.
Procesare în memorie
Payload-ul nu se scrie niciodată pe disc. Intră în request, e transformat în memorie și dispare când răspunsul pleacă. Nu există un fișier al declarației tale la noi.
Validare locală
XSD-ul și Schematron-ul oficial rulează la noi, pe serverul care ține răspunsul tău. Nu trimitem declarația la ANAF ca să aflăm dacă e validă — regulile sunt aici, verdictul e local.
Loguri fără conținut
Ce reținem e un cod de rezultat și o durată — atât. CUI-ul, marfa, numărul de vehicul, partenerul nu intră în niciun log, nici la noi, nici la un serviciu de observabilitate.
Nici măcar XML-ul
Un header opțional îți spune să nu returnăm nici XML-ul, doar verdictul. Pentru integrări unde vrei validarea, dar preferi ca documentul să nu treacă întreg prin răspuns.
Nu-ți spunem doar „invalid”. Îți spunem exact ce și unde.
Rulăm regulile oficiale, complet, local — XSD plus Schematron — și îți dăm diagnosticul pe câmp pe care validatorul ANAF nu ți-l dă înainte de trimitere.
Schemă XSD oficială
Verificăm întâi structura împotriva XSD-ului oficial al declarației v2: elemente, tipuri, ordine, cardinalități. Dacă lipsește un câmp obligatoriu sau un tip nu se potrivește, îl prindem înainte să ajungă vreodată la SPV.
Schematron oficial
Peste XSD rulăm setul complet de reguli de business ANAF, scrise în Schematron, executate local. Coerența dintre operațiune, bunuri, partener, transport și locații e verificată cu aceleași aserțiuni pe care le folosește ANAF.
Diagnostic, nu doar verdict
Răspunsul îți spune ce s-a verificat — XSD și Schematron —, dacă declarația e validă, plus lista de erori și de avertismente cu regula și câmpul implicat. Diferența dintre a ști că e o problemă și a ști unde e.
Fără trimitere în SPV
Validarea e complet locală: implicit, nimic nu pleacă de la noi către ANAF. Obținerea codului UIT prin SPV rămâne la tine, cu credențialele tale — noi îți dăm XML-ul valid și verdictul înainte de acel pas.
De la transport intern la import cu birou vamal.
Scenariile de transport reale, nu doar exemplul din manual. Fiecare cu tipul de operațiune, locațiile și codurile corecte, gata construite.
Acoperim declarația e-Transport v2 completă, cu locații interne și puncte de frontieră. Dacă întâlnești un scenariu pe care nu-l tratăm corect, scrie-ne — cazurile reale au prioritate în ce construim.
Un obiect de transport intră. XML-ul valid iese.
Trimiți transportul ca JSON de business, primești verdictul și XML-ul de declarație. Fără SDK obligatoriu — clientul HTTP pe care îl ai deja.
# build: un obiect minim de transport → XML e-Transport v2 valid
curl "https://oneapi.ro/api/anaf/v1/etransport/build" \
-H "Authorization: Bearer $ONEAPI_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"declarant": { "cui": "RO12345678" },
"operatiune": "30",
"bunuri": [
{ "scop": "101", "cod_tarifar": "0409", "denumire": "Miere",
"cantitate": 500, "unitate": "KGM", "greutate_bruta": 520, "valoare": 7500 }
],
"transport": { "nr_vehicul": "B123ABC", "data": "2026-09-01" },
"loc_start": { "locatie": { "judet": "CJ", "localitate": "Cluj-Napoca" } },
"loc_final": { "locatie": { "judet": "B", "localitate": "București" } }
}'
# → 200 OK
{
"valid": true,
"xml": "<eTransport xmlns=…>…</eTransport>",
"meta": { "operatiune": "30", "bunuri": 1, "greutate_bruta": 520 }
}
Ce s-a verificat, regula și câmpul
Un răspuns de validare nu-ți dă doar „invalid”. Îți spune ce s-a verificat — XSD și Schematron —, dacă e valid, plus erorile și avertismentele cu regula și câmpul implicat. Suficient ca să corectezi din prima, nu să ghicești.
HTTP/1.1 422 Unprocessable Content
{ "valid": false,
"xsd_checked": true,
"schematron_checked": true,
"errors": [ {
"regula": "ET-CO-12",
"mesaj": "Cod tarifar NC lipsă pentru bun.",
"camp": "bunuri[0].cod_tarifar"
} ], "warnings": [] }
Înainte să declari primul transport.
Restul, în întrebări frecvente și în documentație.