În 2024, RO e-Factura a trecut de la proiect la normă de afaceri: după OUG 120/2021 (care a pus bazele sistemului) și OUG 115/2023 (care a extins obligațiile în B2B), transmiterea facturilor în RO_CIUS conform EN 16931 a devenit obligatorie pentru majoritatea tranzacțiilor dintre plătitori de TVA. În paralel, o parte semnificativă din economie – retail/FMCG, automotive, DIY, pharma – continuă să folosească EDI INVOIC pe EDIFACT (de regulă EANCOM D.96A/D.01B) pentru supply chain. Cheia anului este interoperabilitatea: cum mapezi corect EDIFACT la CII/UBL pentru RO e-Factura, fără pierderi de date, menținând în același timp EDI cu partenerii tradiționali.
Context normativ și tehnic
- Standard european: EN 16931 definește modelul semantic al facturii electronice, cu două sintaxe oficiale: UBL 2.1 și UN/CEFACT CII.
- România: implementare RO_CIUS (CIUS național), publicată de ANAF/MFP. Platforma RO e-Factura operează pe UBL 2.1 aliniat cu EN 16931; companiile care folosesc CII în fluxuri PEPPOL trebuie să asigure conversia la UBL conform RO_CIUS.
- Transport și livrare: RO e-Factura se transmite prin Spațiul Privat Virtual (SPV) cu API dedicate (upload, verificare, descărcare), iar validările CIUS resping automat abaterile de la coduri și cardinalități.
De ce „lossless” contează pentru EDI INVOIC
Lanțurile de retail și distribuție (Carrefour, Kaufland, Auchan, METRO, Hornbach, eMAG/Marketplace, Altex) au investit ani în EDI INVOIC pe EDIFACT pentru reconciliere automată comandă–livrare–factură, condiții comerciale, rabaturi retroactive și clearing. O mapare imperfectă EDIFACT–UBL duce la diferențe de taxe, discounturi sau referințe lipsă, afectând matching-ul 3‑way în ERP (SAP, Microsoft Dynamics 365, Oracle) și penalizările SLA. Obiectivul este ca EDI INVOIC să rămână identic semantic cu factura UBL transmisă în RO e-Factura.
Principii de mapare EDIFACT INVOIC → UBL/CII
- Identitate document:
- UNH/BGM: mapare către cbc:ID (număr factură) și cbc:InvoiceTypeCode (e.g., 380 = Invoice, 381 = Credit Note) cu schemeID „UNCL1001”.
- DTM+137 (data emiterii), DTM+35 (data scadenței) → cbc:IssueDate, cbc:DueDate.
- Referințe de business:
- RFF+ON (comandă) → cac:OrderReference/cbc:ID.
- RFF+DQ (aviz) → cac:DespatchDocumentReference.
- RFF+AAJ/IV (referințe interne) → cac:AdditionalDocumentReference cu cbc:DocumentTypeCode.
- Părți și identificatori:
- NAD+SU/BY/IV/DP → cac:AccountingSupplierParty, cac:AccountingCustomerParty, cac:Delivery/cac:DeliveryLocation.
- GLN/RO e-Factura: păstrați GLN în cac:PartyIdentification/@schemeID=GLN și CUI în cac:PartyTaxScheme/cbc:CompanyID (@schemeID=RO:VAT).
- Adrese structurate (stradă, localitate, cod poștal, țară ISO 3166-1 alpha-2) → cac:PostalAddress.
- Monedă și curs:
- CUX → cbc:DocumentCurrencyCode (ISO 4217). Dacă există curs, utilizați cac:PricingExchangeRate.
- Linii și produse:
- LIN/PIA/IMD → cac:InvoiceLine/cac:Item: GTIN în cac:StandardItemIdentification, cod intern în cac:AdditionalItemIdentification, descriere în cbc:Description.
- QTY/MOA/PRI → cantitate, preț unitar, valori monetare în cbc:InvoicedQuantity, cac:Price/cbc:PriceAmount, cbc:LineExtensionAmount.
- UM conform UN/ECE Rec.20 (ex. C62, KGM) → cbc:InvoicedQuantity @unitCode.
- Discounturi și taxe:
- ALC/PCD/MOA → cac:AllowanceCharge; setați cbc:ChargeIndicator true/false, cbc:Amount, cbc:MultiplierFactorNumeric, cbc:AllowanceChargeReasonCode (UNCL 5189) păstrat în codelist.
- TAX la linie/subtotal → cac:TaxTotal/cac:TaxSubtotal; cbc:TaxCategory/cbc:ID (S, Z, E, O), cbc:Percent, cac:TaxScheme/cbc:ID „VAT”.
- Totaluri:
- MOA totaluri → cac:LegalMonetaryTotal: cbc:LineExtensionAmount, cbc:TaxExclusiveAmount, cbc:TaxInclusiveAmount, cbc:PayableAmount.
- Livrare și transport:
- TDT/LOC → cac:Delivery/cac:Shipment (transportModeCode, locații), dacă sunt relevante pentru matching.
- Incoterms (CPT, DAP) → cac:DeliveryTerms/cbc:ID (@schemeID=INCOTERMS).
- Plată:
- IBAN/BIC → cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID (@schemeID=IBAN) și cac:FinancialInstitutionBranch/cbc:ID (BIC).
- Termene de plată → cac:PaymentTerms/cbc:Note sau structură cu dueDate.
- Anexe și documente suport:
- Referințe către contracte, liste de preț, certificate → cac:AdditionalDocumentReference; atașați PDF/CSV base64 în EmbeddedDocumentBinaryObject dacă partenerii cer oglindire.
Capcane frecvente și cum le eviți
- Rundări diferite: aliniați regulile de calcul la EN 16931 (nivel linie, apoi subtotal taxă, apoi total). În SAP, activați calcule pe 4 zecimale pentru preț și cantitate; rotunjirea finală la 2 zecimale.
- Discounturi multilayer: mapează ALC la linie în UBL AllowanceCharge la linie; rabaturile globale în nivelul documentului. Nu „aplatiza” în total, altfel se rupe reconcilierea la client.
- Mai multe cote TVA pe aceeași linie: separați liniile în UBL dacă EDIFACT grupează condiții cu cote diferite; RO e-Factura cere taxCategory unică per linie.
- Tipuri document: folosește codurile corecte (380 factură, 381 storno/credit) în InvoiceTypeCode; mulți retaileri EDI INVOIC folosesc „storno” negativ – în UBL recomandarea este CreditNote separat.
- Identificatori: păstrați GLN-urile în PartyIdentification; mulți validatori RO e-Factura acceptă doar CUI în TaxScheme, dar partenerii EDI cer GLN pentru matching – aveți nevoie de ambele.
Arhitectură de integrare și piața soluțiilor
În practică, companiile mari rulează un „hub” de transformare între EDIFACT EDI INVOIC și UBL RO e-Factura. Exemple de abordări:
- Adaptor nativ ERP: SAP Document and Reporting Compliance (DRC) pentru România, Microsoft Dynamics 365 e-invoicing add-on, Oracle eBTax + integrare UBL.
- Rețele/peppol & VAN: OpenText, Pagero, Comarch oferă conversie EDIFACT ↔ UBL și conectori RO e-Factura.
- Integrare locală: furnizori români (ex. TotalSoft – Charisma, Senior Software – SeniorERP, asistență prin parteneri) expun conectori SPV/ANAF și mapări EANCOM predefinite.
Pentru IMM-uri și marketplace-uri, un modul EDI la CRM poate reduce timpul de implementare; de exemplu, un serviciu precum EDIconnect.ro (modul al platformei CRMconnect) poate orchestra fluxuri EDI INVOIC cu conversie automată la UBL RO_CIUS și trimitere prin SPV, reducând riscul de inconsecvențe între canale.
Checklist „fără pierderi de date”
- Definește clar mapping-ul EDIFACT → UBL/CII la nivel de câmp, cu codelist-uri documentate (UNCL 1001, 5189, 5305; ISO 3166, 4217; UoM Rec.20).
- Setează corect cbc:CustomizationID: „urn:cen.eu:en16931:2017#compliant#RO_CIUS” și cbc:ProfileID cerut de partenerii PEPPOL, acolo unde e cazul.
- Acoperă scenarii edge: avansuri, autofacturare (self-billing), corecții, retururi, sezonalitate cu cote mixte.
- Validează cu schematron oficial RO e-Factura înainte de upload; rulează și validare de business (matching comandă/aviz) pentru EDI INVOIC.
- Log și audit: păstrează payload-urile EDIFACT originale, UBL generat, recipise ANAF (ACK/erori) și rulează reconciliere zilnică.
Concluzie
EDI INVOIC nu dispare în era RO e-Factura; devine mai disciplinat. O mapare bine gândită EDIFACT → UBL/CII, aliniată la EN 16931 și RO_CIUS, asigură că aceeași tranzacție rulează impecabil atât în ecosistemul fiscal ANAF, cât și în rețelele comerciale tradiționale. Investiția în codelist-uri, schematron, adaptor ERP și testare cu partenerii strategici reduce erorile, accelerează încasările și păstrează „zero pierderi de date” între EDI și RO e-Factura.