compliance

e-Transport: când este obligatoriu și cum îl automatizezi prin API

Ghid e-Transport: ce bunuri sunt vizate, când raportezi, cum integrezi prin API, UIT, dispatch logistic și erori clasice în implementări reale.

Cuprins

e-Transport este sistemul ANAF prin care transporturile bunurilor cu risc fiscal ridicat trebuie raportate în prealabil, primind un cod UIT (Unic de Înregistrare a Transportului) care însoțește marfa și este verificabil în controale1. Introdus prin OUG 41/2022, sistemul vizează combaterea evaziunii fiscale prin trasabilitatea fizică a bunurilor sensibile.

Spre deosebire de e-Factura, care raportează facturile fiscale după emitere, e-Transport raportează intenția de transport înainte de plecare. Diferența temporală schimbă fundamental fluxul operațional: trebuie să integrezi raportarea în procesul de pregătire a expedierii, nu în cel de facturare. Pentru contextul mai larg al raportărilor ANAF, vezi diferența față de SAF-T.

Cine declară în e-Transport și pentru ce bunuri?

Obligația declarării în e-Transport revine, în funcție de fluxul comercial: furnizorului din România pentru tranzacțiile interne și livrările intracomunitare, beneficiarului din România pentru achizițiile intracomunitare, destinatarului sau expeditorului înscris în declarația vamală pentru importuri și exporturi, operatorului economic pentru bunurile proprii transportate între locul de încărcare și cel de descărcare pe teritoriul național, respectiv depozitarului pentru bunurile intracomunitare aflate în tranzit3. Transportatorul nu declară el însuși: utilizatorul care a declarat îi pune la dispoziție codul UIT.

e-Transport se aplică la trei categorii de fluxuri:

  • Achiziții intracomunitare: bunuri achiziționate din alte state membre UE care intră fizic pe teritoriul RO.
  • Livrări intracomunitare: bunuri vândute din RO către alte state membre UE.
  • Circulație internă: pentru bunuri cu risc fiscal ridicat, transportul între operatori economici din RO peste anumite praguri.

Categoriile de produse cu risc fiscal ridicat sunt listate în OUG 41/2022 și actualizate periodic prin acte subsecvente. Inițial sub o sută de coduri NC (Nomenclatura Combinată), lista a fost extinsă progresiv. Categorii reprezentative: băuturi alcoolice, tutun, produse din carne, fructe și legume proaspete, produse de panificație, îmbrăcăminte, încălțăminte, materiale de construcții, mobilă, electrocasnice2.

Praguri practice: valoarea totală a transportului peste 10.000 lei (fără TVA) sau o cantitate care depășește 500 kg, pentru bunuri din lista cu risc fiscal ridicat. Sub aceste praguri, raportarea nu este obligatorie, dar verifică textul OUG 41/2022 pentru excepțiile specifice tipului tău de bun.

Ce este codul UIT și cum îl obții?

Codul UIT (Unic de Înregistrare a Transportului) este codul unic generat de Sistemul RO e-Transport prin care se identifică datele aferente unei partide de bunuri4. Îl obții declarând transportul în sistem, prin portalul SPV sau prin API: trimiți datele transportului, iar după validare ANAF returnează codul UIT împreună cu un PDF de însoțire.

Regulile de timing sunt stricte: poți declara transportul cu cel mult 3 zile calendaristice înainte de data declarată pentru începerea lui, dar obligatoriu înainte de punerea efectivă în mișcare a vehiculului. Odată emis, codul UIT este valabil 5 zile calendaristice de la data declarată pentru începerea transportului, termen extins la 15 zile calendaristice pentru achizițiile intracomunitare. Folosirea unui cod UIT expirat este interzisă și se sancționează.

Operațional: codul UIT ajunge la operatorul de transport și la șofer (electronic sau printat) și este verificabil de organele de control pe traseu. În integrarea prin API, câmpul de referință internă a operațiunii este returnat la generarea codului UIT, ceea ce îți permite să legi codul de comanda din ERP fără tabele de mapare suplimentare.

Cum arată arhitectura unei integrări e-Transport?

O integrare e-Transport leagă trei componente: sistemul tău operațional (ERP, WMS sau magazin online), un generator de XML cu semnătură XAdES și clientul pentru API-ul ANAF. Fluxul tipic într-o implementare reală:

  1. Sistemul tău operațional (ERP, WMS, magazin online) generează un eveniment de „expediție pregătită": comandă confirmată, vehicul alocat, șofer atribuit, dată plecare estimată.
  2. Un job preia evenimentul, construiește XML-ul e-Transport conform schemei ANAF (similar conceptual cu UBL, dar cu profil propriu), îl semnează XAdES și îl trimite la API-ul e-Transport.
  3. ANAF returnează un cod UIT și un PDF de însoțire descărcabil. Codul UIT este atașat la comanda din ERP-ul tău și împărtășit cu departamentul logistic.
  4. Vehiculul pleacă; UIT-ul este disponibil pentru control rutier (electronic, prin codul afișat în cabină sau printat).
  5. După descărcare la destinatar, se confirmă închiderea transportului prin același API, pentru a marca UIT-ul ca finalizat.

Diferența operațională față de e-Factura: termenul de raportare este măsurat în ore, nu în zile. Dacă webhook-ul tău operațional întârzie sau XML-ul este respins, vehiculul nu pleacă (sau pleacă pe răspunderea ta cu risc de amendă). Robustețea sistemului contează aici mai mult decât la e-Factura.

Cum configurezi autentificarea ANAF pentru e-Transport?

e-Transport folosește același mecanism OAuth2 bazat pe certificat eIDAS, identic cu fluxul e-Factura. Dacă ai deja autentificare configurată pentru e-Factura, refoloseși infrastructura: același certificat, același flow de token, doar URL-urile endpoint-urilor diferă. Token-ul de acces poate fi același pentru ambele servicii dacă scope-ul autorizării include și e-Transport.

Endpoint-uri esențiale pentru e-Transport:

  • POST /etransport/upload: declararea unui transport nou.
  • POST /etransport/modify: modificarea atributelor unui transport în curs.
  • POST /etransport/cancel: anularea unui transport neînceput.
  • GET /etransport/stareMesaj?id_incarcare=...: verificarea statusului.
  • GET /etransport/descarcare/{UIT}: descărcarea PDF-ului UIT.

Cum construiești XML-ul pentru e-Transport?

Schema XML pentru e-Transport este publicată de ANAF cu profilul ei propriu (nu UBL, dar conceptual similar). Câmpuri obligatorii la nivel înalt:

  • Identificarea expeditorului (CUI, denumire, adresă, persoană de contact).
  • Identificarea destinatarului (CUI sau identificator extern pentru livrări intracomunitare, denumire, adresă).
  • Detalii vehicul (număr de înmatriculare, tip vehicul, capacitate, alt vehicul de tractare dacă este cazul).
  • Detalii șofer (nume, prenume, CNP sau identificator extern).
  • Lista bunurilor transportate: cod NC, denumire, cantitate, unitate de măsură, valoare unitară, valoare totală.
  • Detalii traseu: punct plecare, punct destinație, dată și oră estimate de plecare și sosire.

Validarea ANAF este strictă pe coduri NC (Nomenclatura Combinată): o eroare de tipăire produce respingere imediată. Stochează codurile NC în catalogul tău de produse o singură dată, validate la introducere, și refoloseși la fiecare transport.

Cum gestionezi răspunsurile asincrone și modificările?

Răspunsul ANAF este asincron, similar e-Factura, dar cu timeline-uri mai strânse (de obicei sub un minut). Codul UIT este returnat după validarea completă a XML-ului. Implementarea practică:

// Simplified flow
const uploadResp = await anafEtransport.post('/upload', signedXml);
const indexIncarcare = uploadResp.indexIncarcare;

// Poll for UIT
let uit = null;
for (let attempt = 0; attempt < 30 && !uit; attempt++) {
  await sleep(2000);
  const status = await anafEtransport.get('/stareMesaj', { id_incarcare: indexIncarcare });
  if (status.stare === 'ok') {
    uit = status.uit;
  } else if (status.stare === 'nok') {
    throw new ValidationError(status.errors);
  }
}

if (!uit) throw new TimeoutError('UIT not assigned in 60s');

await db.transports.update({ orderId, uit, status: 'active' });
await notifyLogistics({ orderId, uit, departureTime });

Pentru modificări de ultim moment (schimbare vehicul, șofer), apelul /modify cu același UIT actualizează datele fără a invalida transportul. Modificarea ARE LIMITĂRI: după plecare, doar anumite câmpuri sunt actualizabile. Anularea totală necesită un alt apel către /cancel înainte de plecare.

Care sunt erorile comune în integrarea e-Transport?

Patru categorii de respingeri și blocaje acoperă aproape tot ce apare în practică:

  • Cod NC invalid: cea mai frecventă cauză de respingere. Verifică codurile NC din catalogul tău contra listei oficiale ANAF, actualizată anual.
  • CUI destinatar inactiv: clientul tău intracomunitar are CUI suspendat. Validează prin API-ul de verificare contribuabili înainte de declarare.
  • Timeout la polling status: ANAF poate fi lent la peak-uri (sfârșit de săptămână, perioade fiscale). Crește numărul de încercări și folosește backoff exponențial. Atenție la idempotență: un UIT odată atribuit nu trebuie cerut din nou.
  • UIT activ pentru transport care nu s-a efectuat: ai uitat să raportezi anularea. Risc de control la verificarea retroactivă a UIT-urilor neînchise în sistem.

De ce crawlerra pentru integrarea e-Transport?

e-Transport este unul dintre cele mai delicate proiecte de compliance pentru o firmă cu volum logistic, pentru că eșecul nu este vizibil decât la control rutier sau la audit ANAF, când deja s-a produs daună. Pe crawlerra construim integrările e-Transport ca module robuste: catalog NC versionat, generator XML reutilizabil, polling persistent rezistent la restart-uri, alertare prin Discord la UIT-uri care nu primesc răspuns în interval normal. Pentru cadrul fiscal general al ANAF, vezi e-Factura și SAF-T. Pentru semantica autentificării, semantica JWT ajută.

  1. Cadrul legal al sistemului RO e-Transport: OUG 41/2022 (introducere), modificată succesiv prin OUG-uri ulterioare care extind lista de produse cu risc fiscal ridicat și ajustează pragurile. Documentația tehnică, schema XML și API-ul sunt publicate la mfinante.gov.ro și anaf.ro (secțiunea „Sistem RO e-Transport"). [seo.etransport_legal_framework]
  2. Categoriile de produse cu risc fiscal ridicat sunt listate în Anexa la OUG 41/2022 prin coduri NC (Nomenclatura Combinată). Lista a fost extinsă progresiv prin acte subsecvente, ajungând la peste o sută de categorii la momentul actualizării acestui ghid. Verifică textul curent al OUG 41/2022 pentru lista completă valabilă la data implementării. [seo.etransport_nc_categories]
  3. Atribuirea obligației de declarare pe fiecare tip de flux: art. 8 alin. (1) din OUG 41/2022; sinteza oficială în Ghidul RO e-Transport 2025, secțiunea I.1. [seo.etransport_declaranti]
  4. Definiția codului UIT, fereastra de declarare de 3 zile calendaristice și valabilitatea de 5, respectiv 15 zile calendaristice: art. 11 din OUG 41/2022; Ghidul RO e-Transport 2025. [seo.etransport_uit_validity]

Întrebări frecvente

Toate transporturile interne sunt vizate de e-Transport?

Nu, doar transporturile bunurilor cu risc fiscal ridicat declarate prin OUG 41/2022. Categoria include produse precum băuturi alcoolice, tutun, produse din carne, fructe și legume, îmbrăcăminte, încălțăminte. Pentru aceste bunuri, transportul intern peste un anumit prag valoric sau peste o anumită cantitate trebuie raportat în prealabil în e-Transport, indiferent dacă este import, export, sau circulație internă între operatori.

Când trebuie să raportez transportul?

Înainte de plecarea efectivă a transportului, având codul UIT obținut din e-Transport prezent fizic sau electronic pe transport. Raportarea preventivă este esența sistemului: codul UIT este verificabil de organele de control pe drumuri; transport fără UIT activ este sancționat ca neraportat, indiferent de bună-credință. Declararea se poate face cu cel mult 3 zile calendaristice înainte de data declarată pentru începerea transportului, iar codul UIT rezultat este valabil 5 zile calendaristice (15 pentru achiziții intracomunitare). În practică, integrările declară transportul imediat ce comanda și vehiculul sunt confirmate.

Pot folosi e-Transport doar prin portal sau pot integra prin API?

Ambele căi sunt valide, dar API-ul este obligatoriu peste un anumit volum. ANAF expune un REST API pentru e-Transport, similar arhitectural cu API-ul pentru e-Factura: autentificare OAuth2 prin certificat eIDAS, upload XML, polling status, descărcare răspuns. Pentru volume mici (sub câteva transporturi pe săptămână) portalul SPV este suficient. Peste acest prag, integrarea prin API este singura opțiune sustenabilă operațional.

Ce fac dacă transportul se schimbă după ce am raportat UIT-ul?

Modificarea atributelor de transport (vehicul, șofer, ora) este permisă prin operație de actualizare în e-Transport, dar anularea completă cere proceduri stricte. Schimbarea vehiculului sau a șoferului este o operație standard de update prin API. Anularea totală a transportului (de exemplu, comandă anulată) trebuie raportată separat ca neefectuare, altfel codul UIT rămâne activ și produce alarme la controlul rutier.