EDI: Implementarea corectă a DTM (C507) – maparea 2005/2379/2380 și capcane frecvente

EDI: Implementarea corectă a DTM (C507) – maparea 2005/2379/2380 și capcane frecvente

În proiectele EDI moderne, segmentul DTM este unul dintre cele mai folosite și, paradoxal, una dintre cele mai frecvente surse de erori. În UN/EDIFACT, segmentul DTM conține compozitul C507, format din: 2005 (Date/time/period qualifier), 2380 (valoarea datei/orei/perioadei) și 2379 (format qualifier). Ordinea corectă în payload este DTM+2005:2380:2379. În ultimii ani, pe măsură ce retaileri și producători mari – precum Carrefour, METRO, Kaufland, Nestlé sau Procter & Gamble – și-au actualizat ghidurile EDI bazate pe EANCOM (subset GS1 al EDIFACT), cerințele pentru DTM au devenit mai strict definite, iar conformitatea a devenit o problemă practică pentru integratori, ERP și furnizorii de EDI.

Ce înseamnă 2005/2380/2379 și cum se mapează în ERP

• 2005 – Qualifier-ul care spune despre ce tip de dată/ora este vorba. Exemple uzuale în retail/logistică EDI: 137 (document/message date/time), 2 (delivery date/time, requested), 11 (despatch/shipment date/time), 64 (delivery date/time, earliest), 63 (delivery date/time, latest).
• 2380 – Valoarea datei/orei, fără separatori, conform formatului indicat în 2379.
• 2379 – Format qualifier. Cele mai folosite în EANCOM: 102 (CCYYMMDD), 203 (CCYYMMDDHHMM) și 204 (CCYYMMDDHHMMSS). Standardele sunt aliniate la ISO 8601-1:2019.

Exemple corecte:

DTM+137:20250121:102'      (data document: 2025-01-21)

DTM+11:202501211030:203'   (data/ora expediere: 2025-01-21 10:30)

DTM+2:20250201:102'        (data livrare solicitată: 2025-02-01)

În ERP, cheia este maparea calitativă a qualifier-ului 2005 la câmpul corect din modelul de date. De exemplu, 137 merge la “Document Date” din comandă/aviz/factură; 2 merge la “Requested Delivery Date”; 11 la “Actual Shipment Date/Time”. Atenție: în EDIFACT, DTM apare atât la nivel de antet, cât și la nivel de linie (în grupurile segmentelor corespunzătoare). Multe implementări EDI greșesc prin a suprascrie data de pe antet cu ultima DTM găsită la linii sau invers. Regula de aur: mapează DTM la nivelul lor de context (header vs line) și aplică priorități conform ghidului partenerului comercial.

Capcane frecvente pe care le vedem în proiecte EDI

• Ordinea componentelor: 2380/2379 inversate. Formatul corect în EDIFACT este 2005:2380:2379; schimbarea ordinii rupe parsere conforme.
• Formatul nepotrivit: 2379=102 dar 2380 conține și timp (ex. 202501211030). Dacă e nevoie de timp, folosiți 203 sau 204.
• Zero-padding și lungimi: 203 cere exact CCYYMMDDHHMM (12 cifre). Lipsa de zero-padding la ore/minute produce erori în validatoarele stricte.
• Timezone nedefinit: EDIFACT nu include fusul orar în 2379=102/203/204. Multe ghiduri EANCOM (Carrefour, METRO) consideră ora “locală”. Dacă partenerii sunt cross-border, documentați explicit fusul orar în Implementation Guideline sau standardizați pe UTC în aplicație.
• Calificatorul 2005 greșit: unii parteneri folosesc 10 (despatch date) vs 11 (despatch date/time). Verificați ghidul fiecărui retailer – EDI nu e “one-size-fits-all”, chiar și în EANCOM.
• Mai multe DTM pentru aceeași semnificație: ex. 2 (requested), 64 (earliest) și 63 (latest) coexistă în ORDERS. ERP-urile trebuie să stocheze o fereastră de livrare, nu un unic câmp “delivery date”.
• Contextul de linie: în DESADV și ORDERS, DTM la nivel de linie poate reflecta date de livrare/expediere specifice itemului, diferite de antet. Nu agregați orbește.
• Conversia între standarde: la maparea EDIFACT DTM către ANSI X12 (segment DTM), calitățile nu sunt 1:1; necesită o tabelă de corespondență și testare cu partenerii din SUA.
• Diacritice/separatori: 2380 nu acceptă “-” sau “:”. Doar cifre, conform 2379. Separatoarele EDIFACT sunt gestionate la nivel de segment/compozit, nu în valoare.
• Versiunea directorului: între D.96A și D.24B există diferențe de codificări și clarificări. Alegeți consistent setul (mulți retaileri EANCOM 2002 încă sunt operaționali) și documentați-l în profilul de implementare. UN/CEFACT a publicat în 2024 directoarele D.24A și D.24B, însă retailul european continuă să folosească EANCOM 2002 din motive de stabilitate.

Ce cer retailerii și ce așteaptă integratorii EDI

Ghidurile EANCOM publice ale GS1 (GS1 are organizații membre în peste 100 de țări) recomandă 102/203/204 pentru DTM și folosirea qualifier-elor 137, 2 și 11 în majoritatea fluxurilor ORDERS, DESADV și INVOIC. Retaileri precum Carrefour, METRO și Kaufland, în documentațiile lor de implementare EDI, indică explicit aceste convenții și penalizează în testare abaterile de la format. Pentru echipele ERP și furnizorii EDI, asta înseamnă:

• Definirea unui Data Dictionary EDI-ERP în care fiecare 2005 are o destinație clară (câmp ERP și nivel – antet/linie).
• Normalizarea formatelor (mapper care “știe” 102/203/204) și validarea strictă în pipeline.
• Testare pe seturi de mesaje reale (ORDERS/DESADV/INVOIC) pentru fiecare partener, pentru a evita surprizele în producție.

Exemplu de mapping în practică

Să presupunem un ORDERS de la un retailer european:

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

DTM+137:20250121:102'

DTM+2:20250128:102'

DTM+64:20250127:102'

DTM+63:20250129:102'

LIN+1++1234567890123:EN'

DTM+2:20250129:102'

Mapping recomandat în ERP:

• Order Document Date = DTM+137 (header)
• Requested Delivery Window = [DTM+64, DTM+63] (header)
• Requested Delivery Date (line 1) = DTM+2 (line), care suprascrie fereastra de la antet pentru linia respectivă

Guvernanță și calitate a datelor

ISO 8601-1:2019 stabilește convențiile pentru date/timp; aliniați conversiile EDI la aceste norme. Includeți în contractele EDI (sau în anexele tehnice) politica de timezone. În pipeline, aplicați validatori care resping: 2379 nepotrivit, lungimi incorecte la 2380, qualifier 2005 neacceptat de partener, sau DTM la nivel greșit de ierarhie.

Unelte și ecosistem

Majoritatea furnizorilor de ERP/EDI (SAP, Microsoft Dynamics 365, Oracle NetSuite) oferă adaptoare standard pentru DTM, dar mapările reale tot necesită configurare. În România, integratori EDI locali cunosc bine specificul retailerilor din regiune; de exemplu, soluții precum EDIconnect.ro (modul al CRMconnect) expun validatori pentru 2379 și reguli de context header/linie, utile în proiecte multi-partener.

Concluzie

DTM pare simplu, dar implementarea corectă în EDI cere disciplină: mapare atentă a 2005, formatare strictă a 2380 conform 2379, înțelegerea contextului header/linie și o politică explicită de timezone. Respectarea ghidurilor EANCOM și a standardelor UN/CEFACT, dublată de o suită de teste automate, reduce drastic incidentele în producție și accelerează onboarding-ul cu retaileri mari. Pentru IT managers, consultanți ERP și EDI, investiția într-un Data Dictionary și într-o validare puternică a DTM (C507) se amortizează rapid prin mai puține erori operaționale și SLA-uri respectate.