EDI și gestionarea excepțiilor: erori de schema ANAF, respingeri și remiteri automate

În 2024, odată cu generalizarea RO e-Factura în B2B (implementată prin OUG 120/2021 și extinsă prin OUG 115/2023), gestionarea excepțiilor în fluxurile EDI a devenit un subiect critic pentru IT managers, consultanți ERP și dezvoltatori. Pe lângă e-Factura pentru ANAF, companiile mari folosesc în paralel EDI clasic (EDIFACT, XML proprietar) pentru comenzi și livrări, ceea ce face ca reziliența, prevalidarea și remiterile automate să fie indispensabile. Într-un ecosistem în care un ERP (SAP, Microsoft Dynamics 365, Oracle NetSuite, SeniorERP, SAGA, SmartBill) se află în centrul schimburilor, arhitectura EDI trebuie să absoarbă diferențele dintre sistemele sursă și cerințele stricte ANAF.

Tipuri de erori ANAF: de la XSD la reguli de business

ANAF validează facturile RO e-Factura folosind atât conformitatea tehnică (XSD UBL 2.1 cu extensiile RO_CIUS), cât și reguli semantice (Schematron) derivate din EN 16931. În practică, în EDI apar trei categorii de probleme:

• Erori de schemă (XSD): lipsă elemente obligatorii (de ex. TaxTotal), formate incorecte (date, zecimale), structuri invalide în UBL. Acestea duc la respingere imediată.
• Erori de reguli (Schematron/RO_CIUS): cote TVA incompatibile cu tipul de linie, diferențe la totaluri din cauza rotunjirilor, unități de măsură neconforme (obligatoriu coduri UNECE, ex. C62, KGM, LTR), identificatori fiscali incorecți.
• Erori operaționale: timeouts, throttling, intermitențe API/serviciu, ferestre de mentenanță anunțate de ANAF.

Din ianuarie 2024, transmiterea în RO e-Factura pentru B2B are termen 5 zile lucrătoare de la emitere, cu amenzi între 1.000 și 10.000 RON (în funcție de mărimea contribuabilului), aplicate etapizat de la 1 aprilie 2024, iar din iulie 2024 regimul devine pe deplin activ. Pentru EDI, înseamnă că un fallback operațional și remiteri automate bine controlate nu mai sunt opționale.

Flux operațional EDI robust pentru ANAF

Un design EDI matur separă clar cele trei etape: prevalidare, transmitere, reconciliere.

1) Prevalidare în EDI, înainte de ANAF

• Validați local XSD și Schematron cu librării consacrate (ex. Saxon-HE pentru Schematron). Nu vă bazați doar pe respingerea ANAF: costă timp, SLA și risc de amendă.
• Mapați master data: unități de măsură în coduri UNECE, cote TVA 0/5/9/19, adresa fiscală și CUI în formatul solicitat. În modern trade, multe ERP-uri stochează UM-uri proprietare – EDI trebuie să le normalizeze.
• Asigurați consistența totalurilor: calculați liniile cu aceleași reguli de rotunjire (2 zecimale la preț, 2 la TVA, concurență între linie și total – evitați recalculări divergente în mai multe microservicii EDI).

2) Transmitere și gestionarea respingerilor

• Implementați idempotency în EDI: chei stabile (Invoice UUID, hash conținut) pentru a evita dubluri dacă nu ați primit confirmarea. EDI trebuie să reziste la retry fără efecte secundare.
• Configurați politica de retry cu backoff și jitter pentru erori tranzitorii (HTTP 5xx, timeouts). Evitați remiterile automate pentru erori de business – acestea cer corecție de date, nu forțare.
• Păstrați cozi dedicate: o coadă „hot” pentru submit și o „dead-letter queue” pentru mesaje EDI cu erori ireparabile automat. Notificările către echipele de suport trebuie să includă payload-ul minimal și harta de mapare EDI → ERP.

3) Reconciliere și trasabilitate

• Corelați fiecare trimitere cu statusurile ANAF (preluat, validat, respins). Stocați recipisa și „sigiliul” ANAF ca dovadă; sunt esențiale în audit.
• Expuneți un dashboard cu indicatori EDI: rata de respingere pe regulă RO_CIUS, TTA (time-to-accept), număr de remiteri automate pe 24h, erori pe partener comercial.
• Activați observabilitate: OpenTelemetry pentru trasabilitate end-to-end, Prometheus/Grafana pentru alerte. SLA realistic: obediență sub 2 ore pentru >99% din facturi în orele de vârf.

Cazuri și practici din piață

Retailerii mari din România (Carrefour România, Auchan, Kaufland, Dedeman) au folosit de ani buni EDI pentru comenzi (ORDERS), avize (DESADV) și facturi (INVOIC). Trecerea la RO e-Factura a însemnat adaptarea mapărilor către UBL 2.1 și consolidarea managementului excepțiilor. Furnizori locali precum DocProcess (platforma DocXchange) sau integratori ERP (Kontron România, fost S&T; Senior Software) au livrat conectori EDI compatibili cu ANAF, iar ecosistemele cloud (SAP, Microsoft Dynamics 365) au accelerat publicarea de pachete de conformitate pentru România.

Din perspectiva dezvoltatorilor, cele mai frecvente cauze de respingere în EDI rămân: UM nealiniate la nomenclatorul UNECE, rotunjiri neconforme pe TVA, lipsa referințelor obligatorii în scenarii speciale (ex. tipuri de scutiri). Un control de calitate pe datele master, rulat zilnic înainte de emitere, reduce respingerile EDI cu 60–80% în primele luni de operare, conform experienței proiectelor enterprise din retail și FMCG.

Pentru companiile cu volume mari, arhitectura EDI eveniment-driven (Kafka/RabbitMQ) aduce elasticitate: microservicii pentru mapare, validare, transmitere, reconciliere și arhivare. Separarea permite scale-out în ferestrele cu vârf, când ANAF poate introduce limitări de trafic. În plus, un sandbox EDI de integrare continuă, alimentat cu seturi reale de date anonimizate, previne regresiile când se actualizează versiunile de regulă RO_CIUS.

Remiteri automate „cu cap”

• Reîncercați automat doar la erori tranzitorii (rețea, 5xx, timeouts). Marcați mesajul EDI cu un TTL: după N încercări, mutați-l în „dead-letter” și alertați echipa.
• La erori de business, propuneți auto-fixuri doar dacă sunt 100% deterministe (ex. mapare UM locală → UNECE). Altfel, deschideți task cu payload minim și reguli încălcate.
• Versionați mapările EDI. Când ANAF ajustează regulile, aveți nevoie de rollout canary la un subset de parteneri, nu big-bang.

Pe piața locală există soluții EDI gata de produs care includ prevalidare, monitorizare și remiteri automate. De exemplu, DocXchange de la DocProcess este utilizat în lanțurile de retail, iar unele platforme CRM/ERP oferă module EDI integrate. În anumite implementări, EDIconnect.ro (ca modul al CRMconnect) este folosit pentru a conecta ERP-urile la ANAF și la partenerii comerciali, cu validări UBL/Schematron out-of-the-box.

Concluzie

În 2024, conformarea e-Factura nu mai este doar o problemă de „conectat la ANAF”, ci de inginerie operațională EDI: prevalidare strictă, auto-remiteri controlate, trasabilitate și SLA-uri clare. Investiția într-o platformă EDI cu validări locale XSD/Schematron, idempotency, cozi robuste și observabilitate reduce dramatic respingerile, riscul de amenzi și timpul de cash. Pentru IT managers și consultanții ERP, acesta este momentul să trateze EDI ca un produs critic, nu ca un „conector”.