EDI: Tot ce trebuie să știi despre segmentul DTM în UN/EDIFACT – formate, calificatori și bune practici

În ecosistemele moderne de integrare, segmentul DTM din UN/EDIFACT este ancoră pentru data și ora din documentele EDI: definește când a fost emis un document, când se pregătește expedierea, care este promisiunea de livrare sau când expiră o promoție. Pentru IT managers, consultanți EDI și furnizori ERP, stăpânirea DTM înseamnă schimb de date coerent, auditabil și interoperabil la scară globală.

Interesul pentru EDI nu scade: piața globală de software EDI a fost estimată la circa 2,2 miliarde USD în 2022 și este proiectată să depășească 4 miliarde USD până în 2030, cu un CAGR de aproximativ 8–9% (estimări publice ale industriei). Rețelele mari precum OpenText Business Network afirmă că interconectează peste 1,1 milioane de parteneri comerciali, iar SPS Commerce raportează peste 120.000 de companii în rețeaua sa. În Europa, subsetul GS1 EANCOM bazat pe UN/EDIFACT este standardul de facto în retail (Carrefour, Metro, Auchan, Kaufland), logistică (DHL, DB Schenker) și maritim (Maersk, MSC), unde DTM apare în aproape fiecare mesaj cheie (ORDERS, DESADV, INVOIC, IFTMIN, IFTSTA).

Anatomia segmentului DTM

DTM este construit pe compozitul C507: 2005 (calificator dată/ora/perioadă), 2380 (valoare), 2379 (format). Sintaxa generică:

DTM+2005:2380:2379'

Exemple uzuale:

DTM+137:20250115:102'        (data documentului: 2025-01-15)

DTM+11:202501151030:203'   (data/ora expedierii: 2025-01-15 10:30)

DTM+63:20250116:102'       (cea mai timpurie livrare)

DTM+64:20250118:102'       (cea mai târzie livrare)

Calificatori (2005) folosiți frecvent

• 137 – Data/ora documentului/mesajului (adesea obligatoriu în header pentru ORDERS, INVOIC).
• 3 – Data/ora facturii (în INVOIC când se distinge de 137).
• 4 – Data/ora comenzii (în ORDERS).
• 11 – Data/ora expedierii (în DESADV, IFTMIN).
• 2 – Data/ora livrării, solicitată (cerința de livrare a cumpărătorului).
• 35 – Data/ora livrării, promisă (angajamentul vânzătorului).
• 63 – Cea mai timpurie dată/ora de livrare acceptabilă.
• 64 – Cea mai târzie dată/ora de livrare acceptabilă.
• 36 – Data expirării (promoții, certificate, loturi).
• 171 – Data/ora de referință (utilitară, definită în ghidul de implementare).

Formate (2379) recomandate

• 102 – CCYYMMDD (doar dată, fără oră). Exemplu: 20260131.
• 203 – CCYYMMDDHHMM (dată + ore și minute). Exemplu: 202601311030.
• 303 – CCYYMMDDHHMMSS (dată + ore, minute, secunde). Exemplu: 20260131103045.

Când partenerii EDI operează transfrontalier, stabiliți în ghid dacă ora este locală a punctului de livrare, a expediției sau UTC. EDIFACT nu codifică fusul orar în DTM; acesta se agrează contractual sau se modelează în alte segmente. În GS1 EANCOM, 102 și 203 acoperă majoritatea scenariilor de business.

Bune practici pentru DTM în proiectele EDI

• Unicitate pe sens: nu repetați același calificator 2005 cu valori diferite în același segment sau context; ghidurile serioase cer un singur DTM+137 per mesaj.
• Consistența formatelor: standardizați pe 102 pentru date și 203/303 pentru date-timp. Evitați formate mixte în același flux EDI.
• Timezone clar: documentați explicit fusul orar în agreement-ul EDI și în ghidul de implementare. Pentru lanțuri globale, utilizați UTC în 203/303 și convertiți în aplicații.
• Validare strictă: 102 trebuie să aibă exact 8 cifre; 203 – 12; 303 – 14. Respingeți valori invalide în gateway-ul EDI înainte de a ajunge în ERP.
• Perechi coerente: când transmiteți ferestre de livrare, trimiteți atât “mai devreme” (63) cât și “mai târziu” (64) pentru planificatori și TMS.
• Evitați suprascrierea semantică: nu puneți “data comenzii” în DTM+137 dacă ghidul partenerului cere DTM+4 pentru aceasta; 137 rămâne antetul mesajului.
• Mapare documentată în ERP: mențineți un catalog de mapping (ex. DTM+11→câmp “DespatchDateTime” în WMS) cu testare E2E. SAP, Oracle și Microsoft Dynamics oferă puncte de extensie pentru conversie DTM.
• Compatibilitate subset: dacă lucrați pe EANCOM, urmați exact regulile GS1 (de ex., DTM obligatoriu în secțiunea nadă/linia articol pentru datele de expirare ale lotului).
• Testare sezonală: validați schimburile EDI în schimbarea orei de vară/iarnă și în perioadele de vârf (Black Friday, Q4 retail), când latențele pot afecta interpretarea DTM.
• Guvernanță: versiunea de coduri (de ex. UN/EDIFACT D.01B vs D.96A) trebuie înghețată pentru fiecare relație EDI și menținută în CMDB.

Din teren: cum folosesc companiile DTM

În retailul european, GS1 EANCOM cere DTM în ORDERS (137 și 2/35 pentru cerințe/promise), DESADV (11 pentru expediere și ferestrele 63/64) și INVOIC (3 pentru data facturii). Carrefour, Metro și Auchan își publică ghidurile EDI cu exemple DTM clare pentru a reduce ambiguitățile dintre ERP-urile partenerilor.

În logistică, transportatorii maritimi precum Maersk și MSC schimbă notificări de staționare și mișcare în IFTSTA/IFTMIN; fiecare milestone are un DTM asociat, ceea ce permite TMS-urilor să facă ETA forecasting. În automotive, furnizorii pentru Volkswagen, Renault sau Stellantis folosesc DELFOR/DELJIT unde ferestrele de livrare DTM sunt critice pentru secvențierea în producție.

La nivel de rețea, OpenText Business Network, IBM Sterling și Descartes GLN pun accent pe validarea DTM la edge, pentru a preveni erori costisitoare în ERP. SPS Commerce raportează creșteri ale volumelor EDI year-over-year, pe fondul extinderii marketplace-urilor, ceea ce face din DTM un câmp frecvent monitorizat în SLA-urile de integrare.

Exemple de pattern-uri recomandate

UNH+1+ORDERS:D:01B:UN:EAN008'

BGM+220+PO12345+9'

DTM+137:20260119:102'   (data mesajului)

DTM+4:20260119:102'     (data comenzii)

DTM+2:20260125:102'     (livrare solicitată)

DTM+63:20260124:102'    (cea mai devreme)

DTM+64:20260126:102'    (cea mai târziu)

...'

Checklist rapid pentru echipele IT

• Stabiliți lista permisă de calificatori DTM per mesaj EDI și per partener.
• Impuneți un singur format 2379 per tip de dată (102/203/303) la nivel de canal.
• Validați și normalizați DTM în gateway (ex. IBM Sterling B2B, OpenText) înainte de mapping în ERP.
• Documentați timezone-ul în contractul EDI și în ghidul de test.
• Automatizați testele unit/integration cu mostre reale din pilotul EDI.

Concluzie: DTM pare un detaliu trivial, dar este coloana vertebrală temporală a fiecărui flux EDI. Un set scurt de reguli – selecție atentă a calificatorilor, standardizare a formatelor, claritate asupra fusului orar și validare strictă – elimină ambiguitățile și reduce semnificativ erorile în ERP, WMS și TMS. Pe măsură ce volumele EDI cresc în retail, logistică și producție, guvernanța segmentului DTM devine un diferențiator operațional real.