EDI: Cum proiectezi corect NAD și RFF în structura ORDERS pentru parteneri și referințe

În fluxurile EDI de tip UN/EDIFACT, mesajul ORDERS este inima relației de achiziții. Două segmente aparent “banale” – NAD (Name and Address) și RFF (Reference) – fac diferența între un lanț de aprovizionare care rulează fluid și unul care generează rework în ERP, retururi și dispute de plată. Pentru IT managers, consultanți ERP și dezvoltatori EDI, proiectarea corectă a acestor segmente în ORDERS este o investiție minoră cu impact major în disponibilitate, cash-flow și raportare.

Contextul standardelor și tendințelor de piață

UN/EDIFACT este standardul global întreținut de UNECE/UN/CEFACT, iar GS1 furnizează identificatori-cheie precum GLN (Global Location Number) și GTIN. Marii retaileri europeni – Carrefour, Kaufland, METRO, Auchan, Lidl, Leroy Merlin – se bazează pe EDI pentru comenzi, avize și facturi. Rețelele EDI enterprise sunt masive: OpenText Business Network anunță peste 1,1 milioane de parteneri conectați, iar SPS Commerce raportează peste 120.000 de clienți în rețeaua sa de retail. Piața EDI continuă să crească, susținută de presiunea pentru automatizare, conformitate fiscală și trasabilitate end-to-end.

NAD corect: fundația identificării partenerilor

NAD stabilește rolurile de parteneri (buyer, supplier, ship-to, invoicee) și conectează ordinul la master data-ul ERP. În EDIFACT, NAD are structura:

NAD+BY+1234567890123::9'

NAD+SU+4001234000005::9'

NAD+DP+1234567000008::9'

NAD+IV+4001234000005::9'

• 3035 Party qualifier: BY (Buyer), SU (Supplier), DP (Delivery Party / Ship-to), IV (Invoicee). În retailul european, aceste patru acoperă 90% din cazuri.
• 3039 Party identification: GLN de 13 cifre, când este disponibil.
• 3055 Code list responsible agency: “9” pentru GS1. Usați “92” pentru cod intern doar dacă nu există GLN și ați convenit bilateral.

Recomandări practice pentru EDI în ORDERS:

• Înregistrați în ERP un “Partner Master” cu mapare 1:1 între GLN și entitate (companie/locație). Nu reciclați același cod intern pentru locații diferite.
• Faceți BY obligatoriu și aliniați-l la contul de client din ERP; SU trebuie să identifice unitatea legală care facturează (utile pentru reconcilierea fiscală).
• DP trebuie să fie locația fizică de livrare (magazin, depozit). Pentru Carrefour, Kaufland sau METRO, GLN-ul DP este critic pentru recepție și ASN.
• IV devine necesar când entitatea care plătește diferă de cea care comandă sau recepționează.
• Evitați folosirea liberă a segmentelor de adresă (NAD C080/C059) dacă aveți GLN – adresa textuală crește riscul de erori la matching.

RFF care ține totul laolaltă: referințe coerente, auditate

RFF gestionează referințele documentare și este folosit atât la nivel de antet (header), cât și la nivel de linie (line). În EDIFACT, cele mai des întâlnite calificatoare sunt:

• ON – Order number (numărul comenzii clientului)
• CT – Contract (contract-cadru)
• VA – VAT registration (util în unele piețe pentru clarificări fiscale)
• CR – Customer reference / buyer’s reference (ex. PR/req)

Exemple tipice:

RFF+ON:PO-2026-000123'

RFF+CT:FRAME-24-RO-ENERGY'

RFF+CR:REQ-45877'

La nivel de linie, RFF stabilește legături specifice itemului (campanie, contract per SKU, solicitare internă):

LIN+1++5901234123457:EN'

PIA+1:ABC-001:SA'

RFF+CR:REQ-45877-01'

Asociați RFF cu DTM când referința are valabilitate temporală (ex. contract):

RFF+CT:FRAME-24-RO-ENERGY'

DTM+171:20260131:102'

Unde plasați RFF în ORDERS și cum controlați cardinalitatea

• Header: RFF pentru ON (obligatoriu în majoritatea proiectelor EDI), CT și alte referințe globale documentului. Permiteți repetarea segmentului pentru multiple referințe; impuneți reguli de unicat pentru ON per partener.
• În grupul NAD: dacă un partener transmite numere de cont/abonat per rol (ex. pentru IV), includeți RFF adiacent NAD-ului respectiv, conform versiunii de mesaj acceptate bilateral.
• Line: RFF pentru referințe specifice liniei (recomandabilă o cheie compusă: LIN + RFF pentru audit în ERP).

Compatibilitate ERP și cerințe de rețea

În SAP (IDoc ORDERS05), maparea uzuală este: E1EDKA1 pentru NAD (roluri AG=BY, LF=SU, WE=DP, RE=IV), E1EDK14/E1EDK02 pentru referințe la header, E1EDP02 pentru referințe la linie. În Microsoft Dynamics 365, Oracle NetSuite sau Infor, principiul este același: GLN-ul alimentează tabela de parteneri, iar RFF se mapează în câmpuri de referință document/linie cu indexare pentru căutări rapide.

Marile rețele EDI precum OpenText, IBM Sterling, Descartes și SPS Commerce validează de obicei prezența BY/SU/DP și integritatea GLN (13 cifre). În retail, lipsa DP corect duce la respingerea livrării sau a ASN-ului; la fel, absența RFF+ON poate bloca matching-ul facturii în procesele de 3-way match.

Greșeli frecvente și cum le evitați

• GLN plasat greșit pe NAD (ex. GLN-ul depozitului pe SU în loc de DP). Soluție: validați mapping-ul cu o matrice rol–GLN.
• Folosirea 3055=92 (cod intern) fără acord bilateral. Soluție: standardizați pe GLN (3055=9) acolo unde este disponibil.
• RFF ambiguu sau inconsistent (ex. “PO123” vs “PO-000123”). Soluție: impuneți un pattern de referință și normalizați-l în gateway-ul EDI.
• Lipsa corelării RFF–DTM la contracte. Soluție: validați DTM+171 (data expirării) când RFF+CT este prezent.

Checklist de implementare pentru proiecte EDI ORDERS

• Definiți politicile de parteneri: BY, SU, DP, IV obligatorii? Acceptați roluri adiționale (UD, UC) doar dacă există caz de business.
• Stabiliți codurile RFF permise per nivel (header/linie) și cardinalitatea (ex. maxim 5 la header, 3 la linie).
• Validați GLN-urile cu GS1 (lungime, checksum) și blocați ORDERS fără GLN la DP în retail.
• Documentați mapping-ul ERP și creați teste automate pentru NAD/RFF (golden files per partener).
• Monitorizați în EDI dashboard ratele de respingere pe motivele NAD/RFF, cu SLA-uri corelate.

Concluzie

În EDI, NAD corect înseamnă routing precis al mărfurilor și documentelor, iar RFF coerent înseamnă audit, reconciliere și cash-flow previzibil. Standardele UN/EDIFACT și identificatorii GS1 oferă cadrul; succesul vine din disciplină: GLN-uri curate, roluri NAD consistente și un model de RFF simplu, repetabil. Pentru ecosisteme multi-retailer (Carrefour, Kaufland, METRO, Auchan), aceste reguli reduc semnificativ excepțiile și accelerează time-to-cash. Dacă sunteți la început sau consolidați o integrare, alegeți un gateway EDI care aplică aceste validări by design și expune clar erorile de NAD/RFF înainte ca ORDERS să ajungă în ERP.

Notă: Unele companii din România rulează proiecte EDI prin platforme locale; de exemplu, unii integratori folosesc module precum EDIconnect.ro (parte din CRMconnect) pentru rutare și validare, alături de conexiuni către rețele globale. Indiferent de provider, principiile de mai sus rămân aceleași.