Testare automată pentru segmentul DTM în EDIFACT: reguli, scenarii și validatori open-source
În fluxurile EDI enterprise, segmentul DTM (Date/Time/Period) din standardul UN/EDIFACT concentrează una dintre cele mai frecvente surse de erori: formate incorecte, calificatori nepotriviți, inconsecvență temporală între segmente. În retail, producție sau automotive, unde EDI alimentează aprovizionarea și facturarea la scară, automatizarea testelor pentru DTM este esențială pentru a reduce chargeback-urile, a accelera onboarding-ul partenerilor și a menține SLA-urile.
Contextul pieței întărește presiunea pe calitate: OpenText Business Network (fostul GXS) anunță anual zeci de miliarde de tranzacții rulate pe Trading Grid și volume comerciale evaluate la trilioane USD, în timp ce SPS Commerce raportează o bază de peste 120.000 de clienți de retail și furnizori. În același timp, GS1 are peste 2 milioane de companii utilizatoare ale standardelor sale, iar EANCOM (derivat EDIFACT) rămâne implementarea de facto în retail european, inclusiv la lanțuri precum Carrefour România, Auchan sau Kaufland. În acest ecosistem, testarea EDI automatizată pe DTM devine o capabilitate critică.
Structura segmentului DTM și reguli-cheie
DTM este un segment compozit care folosește C507 și include:
- 2005 – Date/time/period qualifier (ex.: 137 = data/ora documentului; 11 = data expedierii; 171 = data/ora estimată sosire). Valorile acceptate depind de MIG-ul partenerului (ex. GS1 EANCOM pentru ORDERS, DESADV, INVOIC).
- 2380 – Date/time/period (valoarea datei/orei/perioadei), de regulă numerică, lungime variabilă în funcție de format.
- 2379 – Format qualifier (ex.: 102 = CCYYMMDD; 203 = CCYYMMDDHHMM; 204 = CCYYMMDDHHMMSS; 303 = YYMMDD).
Exemple valide:
DTM+137:20240131:102'
DTM+11:202401311030:203'
DTM+171:20240201:102'
Reguli de validare frecvente în MIG-uri (GS1 EANCOM, implementări de retail/automotive):
- DTM apare de regulă de mai multe ori în același mesaj, dar fiecare calificator 2005 are cel mult o apariție (unică per document).
- 2380 trebuie să respecte strict formatul dictat de 2379: 8 cifre pentru 102 (CCYYMMDD), 12 pentru 203, 14 pentru 204; fără spații, fără separatori.
- Consistență inter-segmente: data din DTM+137 ar trebui să fie aliniată cu antetul UNB (data YYMMDD, ora HHMM) și cu UNH/BGM (unde se cere).
- Validări de business: DTM de livrare nu poate fi anterior DTM de expediere; DTM de factură nu poate preceda DTM de livrare când MIG-ul partenerului o specifică.
- Fus orar: dacă MIG-ul impune format local fără offset, evitați sufixe neconvenționale; unde offset-ul este cerut, utilizați codurile conform UN/CEFACT.
Notă: UN/CEFACT publică direcțiile EDIFACT de două ori pe an (edițiile A și B). Verificați versiunea (ex. D.23B, D.24A) cerută în contractul EDI și în MIG-ul partenerului.
Scenarii de testare automată pentru DTM
- Validări de schemă și coduri: verificați prezența obligatorie a DTM+137 în INVOIC, DTM legat de livrare în DESADV etc., conform MIG-ului partenerului; validați codurile 2005 și 2379 din categoriile permise.
- Teste de format: generare de cazuri pozitive/negative pentru 102/203/204/303; reject dacă lungimea nu corespunde sau dacă există caractere non-digit în 2380.
- Consistență cronologică: aserțiuni că DTM de document ≤ DTM de livrare ≤ DTM de recepție; comparați cu antetele UNB/UNH.
- Boundary conditions: 29/02 în an bisect, schimbări de oră (DST), trecerea peste miezul nopții (livrări cross-day), week-to-week.
- Property-based testing: generați automat date/ore valide aleatoare și verificați invarianta formatului; injectați erori controlate (format, coduri) pentru a măsura acuratețea validatorului.
- Golden master: capturați mesaje EDI valide din producție (anonimizate), înghețați-le ca set de referință și rulați regression testing la fiecare schimbare de MIG sau versiune EDIFACT.
Validatoare și tool-uri open-source pentru EDIFACT DTM
- Bots Open Source EDI (Python, licență GPL): motor matur de parsing/validare pentru EDIFACT, X12, TRADACOMS. Permite definirea de reguli custom, mapping și validări de coduri de listă; se integrează în CI/CD și poate rula headless pentru test suites.
- Smooks (Java, Apache 2.0): motor de transformare/validare cu suport EDI (EDIFACT/X12) prin cartridge-uri. Bun pentru pipeline-uri unde EDI este transformat în JSON/XML și regulile sunt aplicate declarativ.
- Biblioteci EDIFACT comunitare: organizații precum NHS England publică pe GitHub componente EDIFACT (parse/serialize) folosite în integrarea medicală; pot fi adaptate pentru validări de DTM și reguli MIG.
- OpenAS2 (Java, open-source): pentru transport sigur AS2. Nu validează direct DTM, dar se cuplează bine cu validatoarele de mai sus pentru o linie end-to-end EDI cu reject timpuriu.
Integrare DevOps: rulați validarea EDI în GitHub Actions sau Jenkins, cu rapoarte JUnit. Blocați merge-urile când testele DTM eșuează (ex. formate 2379 inconsistente sau lipsă DTM+137). Asigurați test data versioning per partener EDI (ex. EANCOM vs. Odette/DELJIT) și per director UN/EDIFACT.
Exemplu de reguli automatizate aplicate pe DTM
Mesaj: INVOIC D.24A EANCOM
Reguli:
- DTM+137 obligatoriu; 2379 ∈ {102,203,204}
- Dacă 2379=102 => len(2380)=8
- DTM+137 ≤ DTM+11 (dacă există) ≤ DTM+171 (dacă există)
- Fiecare 2005 apare o singură dată
Beneficii măsurabile
- Reducerea timpului de onboarding EDI cu 30–50% prin test suites livrate furnizorilor înainte de go-live.
- Scăderea erorilor de facturație și a chargeback-urilor generate de DTM invalide, frecvent întâlnite în retail EDI.
- Trasabilitate și audit: loguri standardizate pentru respingeri DTM, utile în SLA și conformitate.
Recomandări pentru echipele IT, ERP și EDI
- Normalizați validările DTM într-o bibliotecă comună, reutilizată în toate fluxurile EDI (ORDERS, DESADV, INVOIC).
- Întrețineți o mapare per partener: calificatori 2005 per mesaj, formate 2379 permise, reguli cronologice.
- Automatizați testele pe fiecare commit de mapping și la actualizările de director UN/EDIFACT (edițiile A/B semestriale).
- Colectați mostre reale cu erori din producție și transformați-le în teste negative reproducibile.
Concluzie
DTM pare un detaliu, dar în EDI el este liantul temporal al întregului document. Cu reguli clare ancorate în UN/EDIFACT și MIG-uri (precum GS1 EANCOM), scenarii de testare bine alese și validatoare open-source precum Bots și Smooks, organizațiile pot obține un salt semnificativ de calitate. Într-o piață unde rețele EDI procesează anual miliarde de mesaje, automatizarea riguroasă a validărilor DTM este diferențiatorul dintre un lanț operațional robust și unul fragil.