În majoritatea proiectelor EDI enterprise, tensionarea dintre stabilitate și modernizare se vede clar la nivelul mesajului EDIFACT INVOIC. Discuția EDI INVOIC D.96A vs D.01B nu este doar despre o “versiune mai nouă”, ci despre diferențe fine de segmente, codificări și reguli de validare care au impact direct asupra compatibilității între ERP-uri, traductoare și rețelele B2B. Pentru IT managers, consultanți EDI și furnizori ERP, înțelegerea acestor diferențe scurtează timpii de onboarding și reduce riscul de respingere a facturilor în lanțurile globale.
De ce contează EDI INVOIC D.96A vs D.01B în 2024–2025
În ultimii ani, presiunea reglementărilor de e‑facturare (Italia SDI din 2019, Germania – obligativitate de recepție B2B de la 2025, extinderea RO e‑Factura în România din 2024 cu sancțiuni din iulie 2024, amânarea KSeF în Polonia spre 2026) a forțat companiile să-și “curățe” implementările EDIFACT. Chiar dacă multe administrații adoptă UBL/Peppol BIS, în privat încă domină EDIFACT, iar compatibilitatea EDI INVOIC D.96A vs D.01B rămâne un subiect practic când lucrezi cu retail, auto, FMCG sau logistics.
Segmente cheie: ce se schimbă de la D.96A la D.01B
-
Identificatori și agenții de cod: în segmentul
NAD, identificatorii GLN (GS1) rămân standardul de facto (element 3039, cu 3055=9). D.01B aduce liste de coduri mai bogate în mai multe segmente, ceea ce în practică înseamnă că un partener pe D.01B poate trimite calificatori pe care un map D.96A nu îi “așteaptă”. Consecință: mai multe reguli de normalizare în traductor. -
Referințe:
RFFla header și la linie apare în grupuri renumerotate în D.01B versus D.96A. Multe profile interne (ex. retail) cerRFF+ON(număr comandă) obligatoriu. EDI INVOIC D.96A vs D.01B se traduce aici prin hărți diferite ale segment group‑urilor, nu prin alt conținut semantic. -
Moneda:
CUXeste definit în ambele versiuni, dar implementările reale diferă. În D.01B, partenerii folosesc mai des calificatori adiționali pentru monedă de plată vs monedă de facturare. Recomandare: forțați o singură monedă la linie în ERP, chiar dacă EDI permite multiple, pentru a evita discrepanțe de total. -
Taxe:
TAX+MOArămân perechea clasică. D.01B a extins calificatorii în unele code‑list-uri, iar categoriile de TVA (5305– S/Z/E etc.) sunt identice ca sens, însă validatoarele mai noi sunt mai stricte pe corelarea bazei impozabile cu sumele (MOA). Aici apar diferențele “invizibile” care duc la reject în testare. -
Alocații/discounturi:
ALC+PCD/MOAsunt similare, dar în D.01B se întâlnesc mai frecvent scenarii cu discounturi compuse la linie. Dacă pe D.96A era tolerată agregarea în total, pe D.01B partenerii cer granularitate pe fiecareLIN. -
Descrieri:
IMDvsFTX– D.01B favorizează mai clarIMDpentru atribute de produs, lăsândFTXpentru texte libere. În multe proiecte EDI INVOIC D.96A vs D.01B, acesta este principalul motiv de ajustare a map‑urilor de item master. -
Control și separatori: plicurile
UNB/UNZși antetulUNH/UNTsunt aceleași, dar D.01B cere adesea conformitate strictă cu ISO 9735 actualizat și cu profilele de separatorUNA. Orice conversie de virgulă/zecimală trebuie standardizată.
Impact asupra compatibilității cu ERP și rețele EDI
– SAP: majoritatea clienților SAP ECC/S4 folosesc IDoc‑ul INVOIC02 și un traductor (OpenText, Seeburger, IBM Sterling). În proiectele EDI INVOIC D.96A vs D.01B, diferența reală e în regulile de mapare din traductor, nu în IDoc. Cheia: normalizează calitativ NAD/RFF/CUX/TAX la un model canonic SAP și menține crosswalk‑uri pentru code‑list-uri.
– Microsoft Dynamics 365, Oracle NetSuite: conectorii out‑of‑the‑box suportă ambele directoare, dar validatoarele marketplace‑urilor EDI sunt mai stricte pe D.01B. Evită dublarea liniilor pentru discounturi; folosește ALC consistent.
– Rețele și VAN-uri: OpenText Business Network declară peste 1,1 milioane de parteneri conectați, iar SPS Commerce peste 120.000 de clienți – heterogenitatea de profile înseamnă că vei întâlni simultan D.96A și D.01B în același portofoliu. Standardizează intern pe o singură versiune și convertește la intrare/ieșire.
Guvernanță și “gotchas” în proiecte
-
Documente de conformitate (IC/IG): insistă pe o anexă clară “EDI INVOIC D.96A vs D.01B – maparea calificadorilor”, mai ales pentru
RFF,DTMșiMOA. Multe respingeri apar din calificatori neașteptați, nu din segmente lipsă. -
Unități de măsură și codificări GS1: blochează în validare
NAD+BY/SU/DPfără GLN. Retailerii globali (Carrefour, METRO, Auchan) solicită GLN consecvent; diferențele între D.96A și D.01B nu te scutesc de regulă. -
Totale și reconcilieri: confirmă că
UNS/CNTși totalurileMOAsunt coerente cu linia monetară unică. EDI INVOIC D.96A vs D.01B nu schimbă aritmetica, dar schimbă toleranțele de rotunjire. - Bridge către mandatele naționale: dacă trimiți EDIFACT către client, dar trebuie să raportezi UBL către o platformă guvernamentală (ex. RO e‑Factura), păstrează un model canonic intern și două publish‑uri: EDIFACT către partener, UBL către autoritate.
Strategie de migrare și testare
Pentru un portofoliu mixt, o strategie pragmatică este: 1) alege intern un canonic “D.01B‑like” cu liste de cod extinse; 2) mapează downgrade spre D.96A la partenerii vechi; 3) rulează testare automată pe seturi de regresie (10–20 scenarii: taxe multiple, alocații, monede, linii cu/ fără cod produs) și validează strict UNT și sumele MOA. În EDI INVOIC D.96A vs D.01B, succesul vine din consistență, nu din alegerea “versiunii corecte”.
Exemplu operațional
Un producător auto care facturează atât un OEM german (D.01B, validare strictă pe IMD) cât și un retailer din Europa Centrală (D.96A, toleranță pe FTX) a redus cu 40% erorile prin: aliniere GLN în NAD, trecerea tuturor descrierilor în IMD, consolidarea ALC la linie și verificări de rotunjire pe 2 zecimale. Aceeași hartă canonică a publicat apoi Peppol UBL pentru raportare B2G.
Concluzie
EDI INVOIC D.96A vs D.01B nu este o bătălie a generațiilor, ci un exercițiu de guvernanță a datelor și de mapare robustă. D.96A rămâne omniprezent în retail și distribuție, D.01B aduce claritate și liste de coduri mai bogate. Cheia compatibilității este un model canonic intern bine documentat, validări stricte și o strategie de conversie bidirecțională. În ecosisteme cu mii de parteneri – de la OpenText până la SPS Commerce – această abordare minimizează fricțiunile și scurtează time‑to‑revenue în proiectele EDI.