EDI: Cum depanezi erorile “segment count mismatch” generate de UNT în producție

“Segment count mismatch” la UNT în EDIFACT: cum îl depanezi rapid în producție fără să rupi lanțul de aprovizionare

În producție, erorile de tip “segment count mismatch” generate de segmentul UNT în mesajele EDIFACT apar exact când te dor cel mai tare: când o comandă mare trebuie confirmată sau o factură trebuie procesată imediat. Pentru echipele de IT, consultanți EDI și furnizori ERP, această eroare de integritate este un semnal clar că ceva s-a pierdut sau s-a transformat greșit între UNH și UNT. Mai jos, un ghid pragmatic de analiză și corecție, cu bune practici dovedite din ecosistemul EDI global.

Context: de ce contează UNT

În EDIFACT, UNT închide mesajul și conține două informații critice: numărul de segmente din mesaj (inclusiv UNH și UNT) și referința mesajului. Un “segment count mismatch” indică neconcordanță între numărul declarat și segmentele efective parcurse de parser. În producție, retailerii mari (Walmart, Carrefour, Lidl, Kaufland) sau jucători logistici (DHL, DB Schenker) resping automat mesajele cu UNT invalid, ceea ce poate conduce la întârzieri operaționale și chargeback-uri.

De ce apare eroarea

• Delimitatori EDIFACT nealiniati (confuzie în UNA vs. așteptările parserului; caractere de terminare CRLF vs. LF).
• Transformări care adaugă/șterg segmente după calculul inițial (de ex., o regulă care omite segmente goale FII, CNT, ALC sau introduce UNS pentru secțiuni).
• Re-batching sau re-enveloping de către gateway EDI fără recalcularea corectă a numărului de segmente din UNT.
• Condiționări în mapare (de ex., agregare de linii care comasează LIN/QTY și schimbă structura).
• Caractere speciale sau escaping greșit al semnului de release (?).

Checklist de depanare în producție

1. Normalizează delimitatorii înainte de analiză. Verifică UNA (separatori de elemente, componente, decimal, release, terminator) și linia de final (CRLF/LF). Orice nealiniere poate induce un parser EDI să “vadă” alt număr de segmente.
2. Recitește standardul: UNT-1 trebuie să includă toate segmentele de la UNH până la UNT, inclusiv aceste două segmente. Mulți mappers greșesc excludând UNH sau UNT din count.
3. Rulează o recalculare scriptată a numărului de segmente. Contează segmentele delimitate de terminatorul de segment din UNA. Exclude orice empty line care nu se termină în terminatorul de segment.
4. Compară payload-ul “pe sârmă” cu cel din staging. Dacă folosești IBM Sterling B2B Integrator, SAP Integration Suite sau Cleo Integration Cloud, extrage atât mesajul înainte de mapare cât și după mapare. Caută diferențe de segmente adăugate/șterse.
5. Verifică logica de split/batch. Re-încapsularea UNB/UNZ sau UNG/UNE fără update la UNT minuscul dar fatal.
6. Evaluează regulile de “trim” pentru elemente/segmente goale. Unele motoare EDI (inclusiv configurații din OpenText Trading Grid sau Generix) pot elimina segmente considerate redundante după ce UNT a fost calculat.
7. Validează cu un parser independent. Folosește un validator open-source (Bots EDI, Smooks) pentru a confirma că eroarea este reproducibilă în afara platformei tale.

Exemplu minim de verificat

UNH+000000123+INVOIC:D:96A:UN'

BGM+380+INV12345+9'

DTM+137:20240115:102'

NAD+BY+123456789::9'

NAD+SU+987654321::9'

LIN+1++SKU-001:IN'

QTY+47:10'

PRI+AAA:12.34'

UNT+9+000000123'

În acest exemplu, se numără 9 segmente de la UNH la UNT, inclusiv cele două. Orice transformare care adaugă un ALC sau elimină PRI trebuie să actualizeze UNT+count.

Monitorizare și prevenție

• Introduceți “pre-send guards”: un pas de validare care recalculează automat count-ul UNT înainte de livrare, blocând mesajul dacă diferă.
• Observability: indexați UNH.0062 (Message reference) în log management (Elastic, Splunk) pentru a corela rapid mesajul respins cu pipeline-ul de transformări.
• Contracte de integritate: definți în SLA că orice modificare de mapare EDI include test de paritate UNH/UNT pe un set de mesaje reale.

Impact de business și piață

Piața globală EDI continuă să crească pe fondul modernizării lanțurilor de aprovizionare. Allied Market Research estimează o piață de circa 2,1 miliarde USD în 2021, proiectată să atingă 4,5 miliarde USD până în 2031 (CAGR ~8,6%). Rețele precum OpenText Trading Grid susțin peste un milion de parteneri comerciali, iar adoptarea în retail și logistică rămâne critică. În regiune, directivele de e-facturare (ex. RO e-Factura, obligatorie în România pentru B2B din 2024) accelerează modernizarea fluxurilor, deseori coexistând cu mesaje EDIFACT tradiționale în aceeași integrare.

Bune practici în platforme comerciale

• IBM Sterling B2B Integrator: activați validation step post-map și asigurați-vă că “recalculate segment counts” este on în envelopes dacă aplicați post-processing.
• SAP Integration Suite / SAP PO: utilizați test case-uri cu assert pe UNT; evitați XSLT care manipulează delimitatori fără a re-rula validatorul EDIFACT.
• Cleo Integration Cloud / OpenText: creați pipelines cu “canonical -> EDIFACT render -> validate -> send”, fără transformări suplimentare după randare.
• Retail EANCOM (GS1): respectați ghidurile locale (de ex. EANCOM 2002) care specifică segmente opționale; activarea/dezactivarea lor afectează UNT.

Plan de acțiune când eroarea lovește în producție

1. Identifică rapid batch-ul și UNH.0062 din mesajul respins.
2. Extrage payload-ul exact transmis partenerului (nu varianta “vizualizată”) și normalizează-l.
3. Rulează numărătoarea segmentelor; compară cu UNT.
4. Găsește ultima transformare care a schimbat structura; repară maparea sau activează recalcul UNT.
5. Reprocesează controlat mesajele impactate și monitorizează acknowledgements (CONTRL/APERAK).

În proiecte locale, unele echipe folosesc conectori românești integrați în CRM/ERP. De exemplu, EDIconnect.ro ca modul al CRMconnect poate aplica validări suplimentare pe UNT înainte de expediere către rețelele retail, reducând respingerile pentru parteneri precum Carrefour sau Metro.

Concluzie

“Segment count mismatch” pe UNT este mai puțin o “eroare misterioasă” și mai mult un simptom al unei ordini greșite a pașilor în pipeline-ul EDI: transformi, apoi validezi, apoi semnezi/envelopezi — nu invers. Cu delimitatori corecți, recalcul automat al UNT și validare independentă, ecosistemul EDI devine rezilient, iar operațiunile tale nu mai depind de noroc, ci de disciplină tehnică.