În 2024, odată cu generalizarea RO e-Factura pentru B2B, maparea răspunsurilor ANAF la statusuri interne a devenit critică pentru orice flux EDI stabil. Pentru IT managers, consultanți ERP și dezvoltatori, felul în care traduceți „în prelucrare”, „preluată/validată” sau „respins” în stări operaționale determină nivelul de automatizare, SLA-urile și calitatea datelor din ERP, TMS sau WMS. Obiectivul: să aveți o hartă clară între evenimentele din API-urile ANAF și stările EDI interne, astfel încât echipele să știe când retrimit, când notifică business-ul și când arhivează conform politicilor fiscale.
Context: RO e-Factura, UBL și impactul asupra EDI
Din 1 iulie 2024, transmiterea facturilor B2B prin RO e-Factura este obligatorie în România, după o perioadă de raportare (ianuarie–iunie 2024). Formatul acceptat este UBL 2.1 conform EN 16931, cu profilul național (CIUS RO). ANAF expune servicii prin Spațiul Privat Virtual (SPV) pentru upload, interogare status și descărcare arhive.
Pe fond, digitalizarea fiscală urmărește reducerea gap-ului de TVA. Conform raportului Comisiei Europene privind VAT Gap (edițiile 2023/2024), România a avut cel mai mare decalaj din UE, peste 35%, echivalent cu miliarde de euro anual. e-Factura este una dintre măsurile-cheie pentru a îmbunătăți colectarea și trasabilitatea – iar pentru EDI înseamnă mai multă integrare, mai multe validări și mai multă telemetrie.
Ciclul de viață al răspunsurilor ANAF, tradus în statusuri EDI
Din perspectiva EDI, merită standardizată o schemă de statusuri interne, indiferent de ERP (SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central, Charisma/TotalSoft, SeniorERP, Wizrom, Transart etc.). Un model robust:
- EDI.DRAFT – factură generată, nesemnată/nelivrată.
- EDI.TO_SUBMIT – pregătită pentru e-Factura (UBL validat local, semnătură setată).
- EDI.SUBMITTED – upload reușit către ANAF; starea ANAF: „în prelucrare”. Stocați corelația (messageId) pentru interogări ulterioare.
- EDI.PROCESSING – poll/subscribe până la verdict; uzual câteva minute, dar proiectați pentru latențe mai mari.
- EDI.ACCEPTED – ANAF „preluată/validată”; descărcați arhiva (ZIP) și atașați-o documentului din ERP/ECM.
- EDI.REJECTED – ANAF „respins”; mapați codurile de eroare la categorii (schema/business) și declanșați corecția automată sau task-uri pentru back-office.
- EDI.TRANSPORT_ERROR – erori HTTP/SSL/timeouts; aplicați retry cu backoff și idempotency.
- EDI.EXPIRED/SLA_BREACH – depășirea SLA-ului intern de prelucrare; alertă către NOC/DevOps și business owner.
Taxonomia erorilor utile pentru EDI
- Schema/XSD/Signature – UBL invalid, semnătură lipsă sau incorectă, timestamp invalid.
- Business rules (EN 16931/CIUS RO) – inconsecvențe de TVA, sume care nu bat, coduri fiscale invalide; de ex. reguli tip BR-xx.
- Flux – duplicat, referință lipsă, factură anulată în afara fluxului.
- Platformă – ferestre de indisponibilitate, limitări de rată.
În EDI, diferențiați clar aceste categorii: erorile de schema se pot repara automat (ex. normalizarea zecimalelor), pe când erorile de business cer intervenție (schimbare cod TVA, validare partener).
Mapare practică: din răspuns ANAF în acțiune EDI
- Când ANAF returnează „în prelucrare”, setați EDI.SUBMITTED + job de polling. Persistați corelația (messageId) și checksum pe payload pentru idempotency EDI.
- La „preluată/validată”, treceți în EDI.ACCEPTED, înghețați valorile comerciale, arhivați ZIP-ul oficial și actualizați contabilitatea (blocare la modificări în ERP).
- La „respins”, treceți în EDI.REJECTED, atașați detaliile (cod, mesaj, context), deschideți incident Jira/ServiceNow automat și decideți rută: retry automat (dacă e transport) sau reemitere (dacă e business).
- Dacă interfața dă erori de rețea, rămâneți pe EDI.TRANSPORT_ERROR și aplicați retry cu backoff și jitter. Nu retrimiteți payload-uri diferite sub același messageId.
Observabilitate și SLA: ce măsori în EDI
- Lead time EDI de la generație ERP la EDI.ACCEPTED (P50/P95).
- Rată de respingere pe furnizor, pe categorie de eroare, pe companie.
- Retry budget consumat și timpul în EDI.PROCESSING.
- Integritatea arhivelor descărcate: checksum, semnături.
Incorporați aceste metri în dashboard-uri (Grafana/Power BI) și aliniați SLA-urile EDI cu obligațiile fiscale (de ex. ferestrele de raportare).
Integrarea cu ERP și rolul furnizorilor
Furnizorii de ERP din România au livrat conectori EDI pentru e-Factura în 2024: Microsoft Dynamics 365 (prin ISV-uri locale), SAP (Add-on-uri ABAP sau middleware SAP CPI), Charisma (TotalSoft), SeniorERP, Wizrom, Transart etc. Modelul recomandat este „decuparea” adaptorului EDI de ERP: un microserviciu sau iPaaS care face semnarea, transportul, maparea statusurilor ANAF și notificarea ERP prin webhook/queue. Astfel, când ANAF schimbă reguli CIUS, adaptorul EDI se actualizează fără a bloca upgrade-urile ERP.
Pe piața locală s-au maturizat soluții specializate EDI care includ conectivitate RO e-Factura, journal-ing complet și arhivare legală. De exemplu, DocProcess a anunțat fluxuri dedicate pentru validare și reconciliere, iar integratorii locali au standardizat conectori pentru multiple ERP-uri. În unele implementări, un modul precum EDIconnect.ro (componentă a CRMconnect) este folosit ca adaptor EDI între ERP și ANAF, cu mapare configurabilă a statusurilor.
Bune practici de arhitectură EDI
- Folosiți cozi (RabbitMQ/Kafka/Azure Service Bus) pentru separarea generării facturii de transportul către ANAF.
- Semnați și validați local UBL înainte de upload pentru a reduce respingerile EDI.
- Implementați idempotency keys și corelare strictă între ERP DocId – EDI MessageId – ANAF id.
- Automatizați remedierea pentru erori recurente (ex. normalizare diacritice, coduri de țară).
- Conservați toate versiunile: payload ERP, UBL trimis, răspunsuri ANAF și arhive ZIP.
Concluzie
Cheia unui proiect reușit de e-Factura este maparea inteligentă a răspunsurilor ANAF la un model de statusuri EDI simplu, stabil și bine instrumentat. Cu această hartă, echipele reduc drastic intervențiile manuale, scad rata de respingere și pot garanta un SLA predictibil pentru business. Într-o piață în care conformarea digitală devine normă, un strat EDI modular, observabil și rezilient face diferența între „merge” și „scală”.