Ce inseamna, concret, o implementare EDI cu un retailer
Pentru un furnizor care livreaza catre un lant de retail, EDI nu este un proiect IT izolat. Este modul in care comenzile, avizele de livrare si facturile circula intre doua sisteme informatice fara ca un om sa retasteze date. Retailerul impune formatul, codurile si regulile de validare; furnizorul trebuie sa le traduca in structura propriului ERP.
De aceea o implementare EDI cu un retailer se citeste ca un lant de dependinte: daca lipsesc codurile de identificare, nu se poate face maparea; daca maparea nu e completa, testele pica; daca testele pica, Go Live se amana. Ghidul de mai jos parcurge etapele in ordinea in care apar in practica.
Regula practica: nu incepe integrarea tehnica inainte de a avea in scris specificatia retailerului si lista completa de documente pe care le veti schimba.
Duratele mentionate in acest articol sunt intervale orientative. Ele depind de retailer, de numarul de tipuri de documente, de calitatea datelor de articol si de disponibilitatea echipei ERP. Nu tratati niciun calendar ca pe un termen garantat inainte de validarea cerintelor tehnice.
Etapa 1: analiza cerintelor si scopul integrarii
Prima etapa raspunde la patru intrebari, iar raspunsurile devin baza contractuala a proiectului.
- Cu cine schimbam documente? Un singur retailer sau mai multi, fiecare cu propriul set de reguli.
- Ce documente sunt obligatorii? Majoritatea retailerilor cer minimum comanda si factura; multi adauga avizul de livrare si confirmarea de receptie.
- Ce sisteme sunt implicate? ERP, WMS, sistemul de facturare, eventual un portal de comenzi folosit azi manual.
- Cine raspunde de date? Cine actualizeaza catalogul de articole, cine corecteaza o comanda respinsa, cine monitorizeaza fluxul dupa lansare.
Rezultatul etapei este un document de cerinte care listeaza fluxurile, sistemele si responsabilii. Fara el, proiectul se transforma intr-o serie de corectii reactive.
Ce cere de obicei retailerul
Specificatia unui lant de retail contine, in general: identificatorii partilor, tipurile de mesaje acceptate, versiunea standardului, regulile de validare pe campuri, canalul de comunicatie si procedura de certificare. Diferentele intre retaileri sunt reale, chiar si cand toti folosesc acelasi standard de baza. Platformele care mentin conexiuni certificate cu mai multe lanturi reduc acest efort, pentru ca profilul fiecarui retailer este deja implementat si mentinut; arhitectura unei astfel de platforme EDI pentru furnizorii din Romania descrie exact acest strat de traducere intre cerintele retailerului si sistemul furnizorului.
Etapa 2: codurile GLN si identificarea partilor
GLN (Global Location Number) este codul GS1 de 13 cifre care identifica in mod unic o entitate sau o locatie: compania furnizoare, depozitul de expeditie, magazinul care primeste marfa, entitatea care plateste factura. In EDI, adresele nu se scriu in text liber. Ele se transmit ca GLN, iar sistemul destinatar le interpreteaza pe baza propriului nomenclator.
Ce trebuie clarificat inainte de mapping:
- GLN-ul furnizorului, obtinut prin GS1 Romania, si eventualele GLN-uri secundare pentru puncte de lucru.
- GLN-urile retailerului: sediu central, depozite, magazine. Retailerul le furnizeaza in specificatie sau intr-un fisier separat.
- Rolurile: cine este buyer, cine este delivery party, cine este invoicee. Aceeasi companie poate avea GLN-uri diferite pentru roluri diferite.
- Codurile de articol: GTIN (cod EAN) pentru fiecare produs, plus corespondenta cu codul intern din ERP si, unde se cere, cu codul de articol al retailerului.
| Element | Cine il furnizeaza | Unde se foloseste |
|---|---|---|
| GLN furnizor | GS1 Romania | Antetul tuturor mesajelor |
| GLN depozit / magazin | Retailerul | Comanda, avizul de livrare |
| GTIN articol | Furnizorul, prin GS1 | Liniile de comanda, aviz, factura |
| Cod articol retailer | Retailerul | Liniile de comanda si receptie |
Erorile de identificare sunt cea mai frecventa cauza de respingere a mesajelor. Un GTIN lipsa sau un GLN de magazin necunoscut opreste procesarea automata, indiferent cat de bine este configurat restul fluxului.
Etapa 3: tipurile de mesaje si fluxul documentar
In standardul EDIFACT, fiecare document comercial are un tip de mesaj. Setul uzual in relatia furnizor - retail arata astfel:
- ORDERS: comanda transmisa de retailer.
- ORDRSP: raspunsul furnizorului la comanda, cu confirmari, cantitati ajustate sau refuzuri de linie.
- DESADV: avizul de expeditie, cu structura paletilor si codurile SSCC.
- RECADV: confirmarea de receptie emisa de retailer, cu diferentele constatate.
- INVOIC: factura electronica.
- PRICAT: catalogul de preturi si articole.
- SLSRPT: raportul de vanzari, folosit pentru replenishment si analize.
- RETANN: anuntul de retur.
Nu toate se implementeaza simultan. Abordarea pragmatica este sa porniti cu fluxul minim cerut de retailer, apoi sa extindeti. O reprezentare a lantului standard ORDERS, DESADV si INVOIC ajuta echipa comerciala sa inteleaga unde intervine fiecare document si ce se intampla cand unul lipseste.
Legatura cu e-Factura si e-Transport
In Romania, factura catre retail trebuie sa ajunga si in sistemul ANAF, in format RO_CIUS. Practic, aceeasi factura are doua destinatii: retailerul, in format EDI, si ANAF, in format XML conform standardului. Conversia automata intre cele doua elimina dubla emitere si diferentele de continut. Acolo unde marfa intra sub incidenta e-Transport, declararea transportului devine parte din acelasi flux operational.
Etapa 4: maparea campurilor catre ERP
Maparea este exercitiul de traducere intre structura mesajului EDI si structura tabelelor din ERP. Se face camp cu camp, in ambele sensuri.
Pentru o comanda primita, maparea raspunde la intrebari de tipul: unde se scrie numarul comenzii retailerului, cum se identifica clientul pe baza GLN, cum se transforma codul EAN in cod intern de articol, ce se intampla cu o linie al carei articol nu exista in nomenclator, cum se trateaza unitatea de masura si multiplii de ambalare.
Pentru o factura emisa, maparea acopera seria si numarul, cotele de TVA, discounturile pe linie si pe document, referinta catre comanda si catre avizul de livrare, moneda si termenii de plata.
Puncte in care apar cele mai multe intarzieri:
- Nomenclatorul de articole incomplet. Fara GTIN pe fiecare articol activ, maparea nu poate fi finalizata.
- Unitati de masura inconsistente. Retailerul comanda in bucati, ERP-ul lucreaza in bax.
- Reguli de rotunjire si TVA diferite intre sisteme, care produc diferente de cateva bani la totalul facturii si duc la respingere.
- Referinte lipsa. Factura fara referinta la comanda nu poate fi reconciliata automat de retailer.
Un ERP romanesc uzual - SAGA, WinMentor, SeniorERP, ASiS - sau o solutie internationala precum SAP ori Microsoft Dynamics se integreaza prin API, fisiere sau conector dedicat. Alegerea metodei influenteaza direct efortul de intretinere.
Etapa 5: canalul de comunicatie
Canalul decide cum ajung fizic mesajele intre parti. Optiunile uzuale:
- AS2: transmisie directa prin internet, cu semnatura si confirmare de primire.
- SFTP: schimb de fisiere pe un director securizat, simplu de operat.
- OFTP2: frecvent in automotive.
- VAN: retea cu valoare adaugata, care intermediaza intre parteneri.
- Peppol: relevant pentru documente in context european.
Retailerul indica de obicei canalul acceptat. Elementele de configurat sunt certificatele, adresele si porturile, ferestrele de transmisie si politica de retrimitere in caz de esec. Merita stabilit din start ce se intampla cand canalul cade: cate reincercari se fac, cine primeste alerta, cat timp se pastreaza mesajele in coada.
Etapa 6: testarea si certificarea
Testarea se face in mediul de test al retailerului, pe scenarii reale, nu pe date inventate. Un set de teste rezonabil acopera:
- Comanda simpla, acceptata integral.
- Comanda cu articol inexistent sau cu cantitate indisponibila, pentru a valida raspunsul de refuz partial.
- Livrare cu mai multi paleti si coduri SSCC.
- Receptie cu diferenta cantitativa fata de aviz.
- Factura cu discount pe linie si cote de TVA mixte.
- Storno sau retur.
Retailerul valideaza fiecare scenariu si emite acordul de trecere in productie. Aceasta certificare este momentul in care proiectul devine ireversibil: de la acel punct, fluxul manual se inchide.
Etapa 7: Go Live si monitorizare
Go Live nu inseamna oprirea brusca a procesului vechi. Practica sanatoasa este o perioada de rulare in paralel, in care documentele circula electronic dar echipa verifica manual un esantion, pana cand rata de mesaje respinse ajunge aproape de zero.
Ce se monitorizeaza permanent dupa lansare:
- Rata de mesaje respinse, pe tip de document si pe cauza.
- Timpul de la primirea comenzii pana la confirmare.
- Numarul de facturi care necesita interventie manuala.
- Diferentele intre aviz si receptie, indicator direct al calitatii datelor logistice.
- Disponibilitatea canalului si intarzierile de transmisie.
Un flux EDI sanatos se recunoaste dupa un lucru simplu: nimeni nu mai deschide portalul retailerului ca sa copieze comenzi. Cand asta se intampla in continuare, exista undeva un tip de document nemapat sau o categorie de articole care iese din automatizare.
Extinderea catre urmatorul retailer
Prima integrare este cea mai costisitoare, pentru ca in ea se rezolva datele de articol, nomenclatoarele si conectarea la ERP. A doua conexiune reutilizeaza aceeasi baza si se reduce, in cea mai mare parte, la profilul specific al noului partener. Din acest motiv, decizia de arhitectura din prima implementare conteaza mai mult decat pare: un conector construit punctual pentru un singur retailer devine un cost recurent la fiecare extindere.
Ce trebuie sa retina un decident
O implementare EDI cu un retailer reuseste sau esueaza pe date, nu pe tehnologie. Codurile GLN si GTIN corecte, un nomenclator curat si o mapare completa rezolva majoritatea problemelor inainte sa apara. Restul, canalul, testarea si monitorizarea, este munca previzibila de proiect.
Inainte de a semna un calendar, cereti specificatia tehnica a retailerului, faceti inventarul articolelor fara GTIN si evaluati cat de accesibil este ERP-ul pentru integrare. Cele trei raspunsuri determina, mai mult decat orice estimare generica, cat va dura efectiv proiectul.