Pentru echipele IT care implementează EDI în retail, FMCG, automotive sau farma, segmentul DTM este unul dintre cele mai frecvent întâlnite și, paradoxal, dintre cele mai des folosite greșit. În UN/EDIFACT, DTM/C507-2005 definește “calificatorul de dată/oră/perioadă”, iar valorile 137, 2, 4 și 11 apar în aproape toate fluxurile clasice ORDERS, DESADV și INVOIC. Un EDI corect pornește de la înțelegerea acestor calificatori și de la folosirea consistentă a formatelor. Mai jos, o sinteză practică, cu exemple, aliniată la ghidurile GS1 EANCOM și la așteptările comerciale din piață în 2024–2025.
Ce reprezintă DTM 2005 și de ce contează în EDI
În EDIFACT, DTM are structura C507: 2005 (qualifier), 2380 (valoare dată/oră), 2379 (qualifier de format). Pentru EDI B2B, standardele GS1 EANCOM (utilizate pe scară largă în retailul european) recomandă folosirea formatelor 102 (CCYYMMDD) și 203 (CCYYMMDDHHMM). Implementările robuste de EDI păstrează un mapping clar între aceste câmpuri și sistemele ERP (ex. SAP S/4HANA, Microsoft Dynamics 365, Oracle NetSuite) pentru a evita conflictele între “document date”, “order date”, “delivery requested” și “despatch date”.
Calificatorii DTM 2005 care apar cel mai des
2005 = 137 (Document/message date/time)
Semnifică data documentului EDI (ex. data comenzii în ORDERS, data avizului în DESADV sau data facturii în INVOIC). Este “ancora” temporală a mesajului EDI.
DTM+137:20250203:102'
2005 = 4 (Order date/time)
Data comenzii propriu-zise, așa cum a fost generată în ERP. În practică, mulți parteneri folosesc doar 137 în ORDERS, dar atunci când 137 este utilizat pentru un alt scop contextual, 4 clarifică explicit “order date”. În EDI pentru retail, separarea celor două reduce ambiguitățile în reconciliere.
DTM+4:20250203:102'
2005 = 2 (Delivery date/time, requested)
Data solicitată pentru livrare. Esențială în EDI pentru planificare logistică și SLA-uri. Este mapată adesea pe “Requested delivery date” din ERP/WMS. În retailul modern (Carrefour, Kaufland, Auchan, Mega Image), neconcordanțele între 2 și sloturile de livrare agreate duc la respingeri automate.
DTM+2:20250205:102'
2005 = 11 (Despatch date and/or time)
Data la care marfa părăsește depozitul. În DESADV (aviz EDI), 11 este vital pentru a sincroniza recepția fizică în DC și pentru calculul DIFOT. În EDI, 11 este diferit de “shipment date requested”; este data reală/planificată a expediției de la furnizor.
DTM+11:20250204:102'
Exemplu EDI concis, aliniat EANCOM
UNH+1+ORDERS:D:01B:UN:EAN010'
BGM+220+PO123456+9'
DTM+137:20250203:102' (data mesajului)
DTM+4:20250203:102' (data comenzii)
DTM+2:20250205:102' (livrare solicitată)
NAD+BY+...'
NAD+SU+...'
LIN+1++...'
QTY+21:100'
UNT+...'
Observați că fiecare calificator DTM apare pe o linie separată. În EDI, repetarea DTM-urilor cu același calificator dar cu valori diferite generează inconsistențe și respingeri la validare.
Bune practici în proiecte EDI din ultimele 12 luni
- Folosiți sisteme de timp coerente: 102 pentru date, 203 pentru date+ora, dacă partenerul EDI cere oră pentru recepție/expediție.
- Stabiliți în caietul de sarcini EDI diferența dintre 137 și 4 în ORDERS; 137 va fi “document date”, 4 “order date” din ERP.
- În DESADV, utilizați 11 pentru expediție și, dacă este cazul, 2 pentru livrarea solicitată din comanda inițială, astfel încât WMS-ul clientului să poată compara planul cu execuția.
- Evitați amestecul de DTM-uri la nivel de header și la nivel de linie. Dacă o linie are calendar propriu (ex. produse cu livrări eșalonate), puneți DTM la nivel de LIN.
- Documentați mapping-ul EDI–ERP: în SAP, câmpuri precum EKKO-AUDAT (order date) mapate pe DTM+4, iar BKPF-BLDAT (document date) mapat pe DTM+137 în INVOIC.
Context de piață și conformitate în România
În 2024, România a introdus obligativitatea generalizată a e-Factura pentru B2B, ceea ce a accelerat maturizarea proceselor digitale. Chiar dacă e-Factura (UBL/CIUS RO) nu este EDI în sensul clasic EDIFACT, multe companii au investit în platforme ce gestionează atât EDI (ORDERS, DESADV, INVOIC EDIFACT), cât și e-Factura. Retailerii mari din România și CEE continuă să solicite EDI pentru fluxurile operaționale non-fiscale (comenzi, avize, status logistic), păstrând interoperabilitatea cu parteneri internaționali. GS1 România promovează EANCOM drept subset recomandat, iar directoriile EDIFACT D.96A și D.01B rămân cele mai întâlnite în producție.
Capcane frecvente în folosirea DTM 2005
- Suprapunerea 137 cu 4: dacă folosiți doar 137 în ORDERS, asigurați-vă că partenerul EDI nu map-ează aceeași dată în două câmpuri ERP diferite.
- Ignorarea 2 în lanțuri cu sloturi stricte: “delivery requested” este criteriu de respingere în multe gateway-uri EDI ale retailerilor.
- Transmiterea de “ora locală” fără acord: dacă unul dintre parteneri folosește 203, agreați fusul orar la nivel de specificație și mențineți consecvența între EDI și ASN-urile WMS.
- Mesaje mixte între linii: amestecarea DTM la linie fără un motiv clar (ex. livrări fazate) crește complexitatea validărilor.
Testare și observabilitate EDI
Pentru a garanta calitatea datelor EDI, utilizați seturi de test cu variații pe 137/2/4/11 și validatori EDIFACT conform EANCOM. În pilot, măsurați rata de respingere pe motive de dată/oră și corelați-o cu regulile de business ale partenerului. Soluții consacrate precum OpenText Trading Grid, IBM Sterling, Cleo, Descartes sau integratori locali oferă dashboard-uri de tracking. În ecosisteme românești, unii furnizori EDI integrează module de mapare rapidă și monitorizare a DTM-urilor pe fluxurile retail.
Exemplu de checklist de implementare
- ORDERS: DTM+137 (obligatoriu), DTM+4 (recomandat), DTM+2 (dacă există lead-time/slot).
- DESADV: DTM+11 (obligatoriu), DTM+2 (cross-check cu comanda).
- INVOIC: DTM+137 (data facturii), plus date scadență/discount conform politicilor de plată (ex. 13/12, unde sunt aplicabile).
Concluzie: Folosirea corectă a DTM 2005 cu 137, 2, 4 și 11 face diferența între un EDI “care merge” și un EDI predictibil, scalabil și ușor de auditat. Într-o piață în care digitalizarea accelerează, iar cerințele de conformitate cresc, standardizarea acestor detalii reduce costurile operaționale și crește calitatea proceselor inter-company.