EDI: Cum testezi confirmările în medii VAN, AS2, SFTP și AS4

Confirmările corecte fac diferența între un flux EDI sănătos și un val de chargeback‑uri, stoc blocat sau facturi neplătite. În practică, testarea confirmărilor în medii VAN, AS2, SFTP și AS4 cere o abordare specifică fiecărui transport, dar și o viziune end‑to‑end: de la MDN sau Receipt până la 997/999 (X12), TA1, CONTRL sau APERAK (EDIFACT). Pentru IT managers, consultanți și furnizori ERP, acesta este un ghid tehnic, actual și orientat pe rezultate pentru a valida confirmările EDI înainte de go‑live.

De ce confirmările contează în EDI

Confirmările EDI au două straturi: nivel de transport (de ex. MDN în AS2 sau Receipt în AS4) și nivel de aplicație (de ex. 997/999, CONTRL, APERAK). Testarea lor reduce riscul operațional, scade timpul de rezolvare a incidentelor și asigură conformitatea cu SLA‑urile marilor retaileri. OpenText Business Network, cel mai mare VAN din lume, afirmă că deservește peste 1,1 milioane de companii și procesează peste 33 de miliarde de tranzacții anual, astfel încât rigurozitatea confirmărilor nu e un moft, ci o necesitate la scară mare. SPS Commerce raportează peste 120.000 de clienți activi, iar TrueCommerce menționează peste 160.000 de parteneri preconectați—ecosisteme unde confirmările EDI sunt critice pentru audit și non‑repudiere.

Testarea confirmărilor în VAN

Rețelele VAN (OpenText/GXS, IBM Sterling, E2open) oferă confirmări de livrare la nivel de rețea și rutează mai departe mesajele către parteneri. Pentru EDI:

• Configurați o cutie poștală de test și un partener dummy. Verificați existența notificărilor „delivery” la nivel de VAN.
• Trimiteți un 850 sau ORDERS și urmăriți TA1 (interchange ack) și 997/CONTRL. Măsurați latența până la ack funcțional; multe SLA cer sub 24h, iar bunele practici vizează sub 60 de minute.
• Simulați erori: UNB/ISA greșit, control number duplicat, pentru a primi negative acks (999/CONTRL) și a valida fluxul de remediere.
• Verificați corelația: mailbox id, interchange control nr, UNH/UNB/ISA/GS până la documentul aplicativ.

Testarea confirmărilor în AS2

AS2 (RFC 4130) este standardul de facto în retailul nord‑american; Walmart, Amazon și Tesco operează endpoint‑uri AS2 pentru EDI. Cheia este MDN‑ul (Message Disposition Notification), preferabil semnat, care conferă non‑repudiere.

• Solicitați MDN semnat (signed‑receipt‑protocol=pkcs7-signature). Testați atât MDN sincron (în aceeași conexiune HTTP), cât și asincron (return‑to URL).
• Forțați un negative MDN prin trimiterea unui MIC incorect (ex. alterați payload‑ul) și validați tratamentul erorii.
• Rotiți certificatele (RSA 2048/3072, SHA‑256) și verificați că MDN‑urile rămân valide după schimbare.
• Verificați logurile pentru Disposition și MIC. Un header tipic: Disposition: automatic-action/MDN-sent-automatically; processed.
• Confirmați că ack‑urile funcționale EDI (997/999, CONTRL) sosesc ulterior pe același sau alt canal conform design‑ului.

Testarea confirmărilor în SFTP

SFTP este robust și simplu, dar nu oferă confirmări la nivel de protocol pentru livrarea conținutului, deci confirmarea EDI se face prin convenții și ack‑uri funcționale.

• Implementați fișiere „sentinel” (.ok/.done) și hashing (SHA‑256) pentru integritate.
• Simulați duplicate și reconectări. Sistemul trebuie să detecteze duplicatele pe baza ISA13/UNB5 sau MessageId și să fie idempotent.
• Verificați politicile de polling, permisiuni și umask, precum și timpul dintre upload și preluare.
• Urmăriți primirea 997/CONTRL înapoi prin același SFTP sau alt canal, corelând prin control numbers.

Testarea confirmărilor în AS4

AS4 (OASIS ebMS 3.0) este preferat în Europa, mai ales în rețeaua Peppol, care a făcut profilul AS4 obligatoriu pentru Access Points din 2019. Confirmarea se face prin Receipt semnat, cu Non‑Repudiation of Receipt (NRR).

• Configurați PMode‑urile pentru Reliability: duplicate detection, retries, și ack on receipt.
• Testați Receipts semnate și verificați includerea referinței către payload (digests) pentru NRR.
• Folosiți gateway‑uri de referință: Domibus (Comisia Europeană/CEF eDelivery) sau Holodeck B2B pentru testare de conformitate.
• În Peppol, validați SBDH, schemă EN 16931 pentru facturi și Receipt‑ul livrat de AP‑ul partener.

KPI‑uri, instrumente și bune practici

• KPI transport: timp până la MDN (AS2) sau Receipt (AS4) sub 60s pentru fluxurile sincrone.
• KPI funcțional: 997/999/CONTRL sub 1 oră în test, sub 24h în producție—aliniat la cerințele multor retaileri.
• Observabilitate: corelați Message‑ID/Control Numbers în ELK/Splunk, alertați la ack lipsă peste SLA.
• Instrumente: OpenAS2 sau mendelson AS2 pentru test AS2; Domibus/Holodeck B2B pentru AS4; Wireshark pentru TLS/handshake; validatoare X12/EDIFACT (Bots, Stedi, smooks) pentru EDI.
• Securitate: TLS 1.2+, certificate cu rotație automată, verificare CRL/OCSP; test negativ pentru expirare și revocare.

Exemplu de plan de test end‑to‑end

1. Trimiteți un 850/ORDERS prin AS2 către un endpoint de test (ex. Amazon Vendor Central sandbox sau un partener intern).
2. Verificați MDN sincron și logați MIC, timestamp, thumbprint certificat.
3. Primiți 997/CONTRL prin VAN sau SFTP; corelați prin ISA13/UNB5 și măsurați latența.
4. Rulați scenarii negative: payload corupt, control number duplicat, certificat expirat—validați negative MDN/999.
5. Generați un raport cu livrări, ack‑uri, erori și timpi; semnați‑l pentru audit intern.

Concluzie

Indiferent dacă folosiți VAN, AS2, SFTP sau AS4, confirmările EDI trebuie tratate ca un produs: specificații clare, teste automate, observabilitate și audit. Piața arată clar necesitatea disciplinei—rețele ca OpenText, SPS Commerce sau ecosistemul Peppol operează la scară masivă, unde fiecare MDN, Receipt sau 997 contează. Implementând testele de mai sus, echipele IT, consultanții ERP și dezvoltatorii EDI reduc riscurile, accelerează onboarding‑ul partenerilor și asigură conformitatea într‑un peisaj global din ce în ce mai reglementat.