EDI APERAK: ghid complet de implementare în EDIFACT D.96A/D.01B

EDI APERAK este mesajul standard UN/EDIFACT de “Application Acknowledgement” folosit pentru a confirma la nivel de aplicație dacă un document primit (de exemplu ORDERS, DESADV sau INVOIC) a trecut validările de business sau, dimpotrivă, conține erori. Spre deosebire de CONTRL (care confirmă doar conformitatea sintactică EDIFACT), EDI APERAK descrie statusul procesării în ERP/WMS/TMS, inclusiv coduri de eroare, segmente și elemente de date problematice. În retail, FMCG, logistică și automotive, EDI APERAK este parte esențială a buclelor robuste de confirmare, reducând costurile de excepție și timpul de remediere.

Unde se potrivește EDI APERAK în D.96A și D.01B

UN/CEFACT publică anual directoare EDIFACT (de tipul D.96A, D.01B). D.96A rămâne foarte răspândit prin subseturi precum GS1 EANCOM în retail/FMCG, în timp ce D.01B aduce liste de coduri extinse și clarificări pentru segmentele de eroare, fiind preferat în implementări mai noi sau multisector. Ambele versiuni suportă EDI APERAK, iar diferențele practice apar în codelists/qualifiers și în interpretările comunităților (GS1, Odette etc.).

De ce contează EDI APERAK

• Confirmare rapidă: notifică partenerul că o comandă sau o factură a fost acceptată/respinsă de aplicație, nu doar “parsată”.
• Trasabilitate: corelează referința documentului original (număr de comandă/factură, referința UNH) și detaliază erorile.
• Automatizare: declanșează fluxuri de corecție automată în ERP/EDI map, reduce apelurile în suport.

Structura tipică a mesajului EDI APERAK

La nivel de mesaj, EDI APERAK urmează modelul UN/EDIFACT standard:

• UNH – identifică mesajul EDI APERAK (tip, versiune D.96A/D.01B, referință unică).
• BGM – identifică documentul de confirmare și funcția mesajului (de regulă original).
• DTM – date/ore relevante (de ex. data generării confirmării, format 102 yyyymmdd).
• RFF – referințe la documentul original (număr comandă/factură, referința UNH a mesajului sursă – conform convențiilor partenerului).
• NAD/CTA/COM – părți implicate și contacte (de ex. BY/SU; optional pentru routare și suport).
• Detalii de eroare prin grupuri de segmente:

  • ERC – codul de eroare la nivel de aplicație (codelists definite de comunitate/partener, ex. GS1 EANCOM).
  • FTX – text explicativ uman (de ex. “GTIN invalid” sau “linie lipsă”).
  • SEG – identifică segmentul afectat (eticheta, poziția în mesajul sursă).
  • ELM – elementul de date afectat (număr DE/CE și, opțional, valoarea problematică).

• UNT – închide mesajul.

Observație: exactul set de qualifiers/codes (ex. pentru RFF sau ERC) diferă între D.96A și D.01B și, mai important, între subseturi (GS1 EANCOM, Odette) și ghidurile retailerilor sau logisticienilor. Implementați conform specificației partenerului comercial.

Ghid de implementare pas cu pas

1. Definiți “când trimiteți” EDI APERAK: la validare reușită (accepted), respinsă (rejected) sau parțial acceptată (accepted with errors). Multe SLA-uri din retail cer confirmare în 15–60 minute.
2. Corelați corect: stocați UNH.0062 (message reference) al documentului primit și numărul documentului (ex. ORDERS.BGM.1004) pentru a le întoarce în RFF/FTX în EDI APERAK.
3. Standardizați codurile: agreați o listă finită de coduri ERC (de ex. ITEM_UNKNOWN, INVALID_GTIN, PRICE_MISSING, QUANTITY_NEGATIVE) și mapările lor la segmente/elemente ELM.
4. Granularitate: trimiteți câte un bloc ERC–FTX–SEG–ELM pe fiecare problemă detectată; evitați mesaje “monolit” greu de acționat.
5. Idempotentă: dacă generați din nou EDI APERAK pentru același document, păstrați aceeași referință BGM/UNH sau marcați-l explicit ca replace/cancellation conform 1225 Message function.
6. Jurnalizare: salvați payloadul sursă, payloadul EDI APERAK, și decizia (accept/reject) pentru audit și dispută.
7. Testare: rulați seturi de date cu erori controlate (GTIN invalid, NAD lipsă, UOM inconsistent) și validați că EDI APERAK indică segmentul (SEG) și elementul (ELM) corecte.

Diferențe practice D.96A vs D.01B

• Liste de coduri: D.01B oferă codificări extinse/actualizate pentru identificarea erorilor; verificați codelists pentru ERC/ELM.
• Date/ore: clarificări de formate și qualifiers suplimentare în DTM.
• Compatibilitate comunități: GS1 EANCOM, bazat în mod tradițional pe D.96A, furnizează reguli stricte pentru EDI APERAK în retail; implementările multi-industrie preferă adesea D.01B pentru flexibilitate.

Integrare cu ERP și rețele EDI

ERP-urile moderne (SAP, Oracle NetSuite, Microsoft Dynamics 365) nu emit nativ EDI; EDI APERAK este generat prin adaptoare/B2B gateways sau rețele. IBM Sterling, OpenText Trading Grid (cu peste 1 milion de parteneri conectați după achiziția GXS), Descartes sau SPS Commerce oferă mapare, validare și monitorizare pentru EDI APERAK out-of-the-box. În retailul bazat pe GS1, EDI APERAK este cerut frecvent împreună cu CONTRL pentru un lanț complet de confirmare.

GS1 raportează că peste 2 milioane de companii folosesc standardele GS1 la nivel global, iar SAP deservește peste 400.000 de clienți în peste 180 de țări – indiciu clar că interoperabilitatea prin EDI APERAK are impact la scară. În România, furnizori locali și regionali integrează EDI APERAK în fluxurile de comandă/livrare/facturare pentru retail, DIY și farma; în unele proiecte, un modul EDI (de exemplu EDIconnect.ro ca modul al CRMconnect) simplifică generarea și consumul de APERAK din ERP existent.

Bune practici operaționale

• Time-to-ACK: măsurați timpul de la recepția documentului până la EDI APERAK; țintiți sub 30 de minute în orele de lucru.
• KPIs: rata de respingere pe tip de mesaj (ORDERS/INVOIC), top 5 coduri ERC, MTTR de remediere.
• Observabilitate: alerte pe praguri (ex. spike de “ITEM_UNKNOWN”) și corelare cu schimbări de master data (articole, prețuri, GLN-uri).
• Guvernanță: controlați versiunile (D.96A vs D.01B), păstrați mappingul în VCS și documentați qualifiers per partener.

Exemplu de conținut informativ într-un EDI APERAK

Fără a impune un anumit subset, un EDI APERAK eficient include:

• RFF care leagă clar comanda/factura sursă și, opțional, referința UNH a mesajului original.
• Cel puțin un bloc de eroare: ERC (cod), FTX (explicație scurtă pentru oameni), SEG (segmentul afectat, de ex. LIN/PRI/NAD), ELM (elementul afectat, de ex. 7140 Item number, 5118 Price).
• Un status agregat (acceptat/respins/parțial) comunicat consistent în BGM/FTX conform ghidului partenerului.

Concluzie

EDI APERAK, implementat corect în EDIFACT D.96A sau D.01B, oferă transparență operațională, scade costurile de excepție și accelerează corecțiile în lanțul de aprovizionare. Diferența față de un simplu CONTRL este substanțială: EDI APERAK vorbește limba aplicațiilor și a oamenilor din operațiuni, nu doar a parserelor. Standardizați codurile ERC, corelați precis cu documentele sursă, măsurați TTA (time-to-ACK) și investiți în observabilitate. Într-o piață în care milioane de companii folosesc standarde GS1 și sute de mii rulează pe ERP-uri enterprise, EDI APERAK este elementul-cheie care transformă schimbul de date în încredere operațională.