Un furnizor care intră în relație cu un lanț de retail din România află repede că nu vinde doar produse, ci și acuratețe de date. Comanda vine electronic, livrarea trebuie anunțată electronic, recepția se confirmă electronic, iar factura se emite pe baza a ceea ce a intrat efectiv în depozit. Cele patru mesaje care compun acest traseu sunt ORDERS, DESADV, RECADV și INVOIC. Ghidul de față explică, pe înțelesul unui director comercial sau financiar, ce conține fiecare mesaj, în ce ordine circulă și cum se leagă de ERP, WMS și CRM.
Ce este de fapt un mesaj EDI
EDI înseamnă schimb electronic de date între două sisteme informatice, fără intervenție umană și fără PDF-uri trimise pe e-mail. Documentul comercial este structurat într-un format standard, cel mai frecvent EDIFACT în retailul european, și este citit direct de sistemul partenerului.
Diferența față de un portal de retailer este simplă: portalul cere unui om să introducă date, EDI cere unui sistem să transmită date. Aceeași comandă ajunge în ERP fără tastare manuală, cu același cod de produs, aceeași cantitate și același termen de livrare pe care le vede și cumpărătorul din retail.
"Erorile de comandă în retail nu apar pentru că oamenii sunt neatenți, ci pentru că aceeași informație este retastată de patru ori pe traseu."
Cele patru mesaje discutate aici acoperă ciclul comercial de bază: comanda, livrarea, recepția și facturarea. În practică mai apar și altele, precum ORDRSP pentru confirmarea comenzii, PRICAT pentru catalogul de prețuri sau SLSRPT pentru raportul de vânzări, însă fără cele patru de bază nu există relație EDI funcțională. O prezentare completă a lanțului de documente și a ordinii lor este disponibilă în fluxul EDI standard dintre furnizor și retailer.
ORDERS: comanda care pornește tot lanțul
ORDERS este mesajul prin care retailerul transmite comanda de achiziție. Este documentul care declanșează celelalte trei.
Ce conține un ORDERS
Un mesaj de comandă transportă, în esență, următoarele blocuri de informație:
- identificarea părților prin coduri GLN, adică adresa unică a fiecărui punct de lucru, magazin sau depozit;
- numărul comenzii și data emiterii, care devin cheia de urmărire pentru tot restul traseului;
- liniile de comandă, fiecare cu cod GTIN sau EAN, cantitate, unitate de măsură și preț negociat;
- locul și intervalul de livrare, uneori cu fereastră orară pentru rampa de descărcare;
- condiții comerciale specifice, cum ar fi promoții sau termene diferite de cele standard.
Ce se întâmplă în sistemul furnizorului
Când ORDERS ajunge în platforma EDI, este validat sintactic și semantic: se verifică dacă structura respectă standardul convenit cu retailerul și dacă produsele comandate există în nomenclatorul furnizorului. Comanda validată este apoi transformată în comandă de vânzare în ERP.
Aici apar cele mai frecvente blocaje operaționale: un GTIN care nu există în nomenclator, o unitate de măsură diferită, un preț care nu coincide cu cel din catalogul transmis anterior. Rezolvarea nu este tehnică, ci de disciplină a datelor de bază.
| Element din ORDERS | Corespondent în ERP | Risc frecvent |
|---|---|---|
| GLN punct de livrare | Adresa de livrare | Magazin nou, neconfigurat |
| GTIN linie comandă | Cod articol | Produs relistat cu alt cod |
| Cantitate și UM | Cantitate comandată | Bax față de bucată |
| Preț unitar | Preț contractual | Promoție neactualizată |
| Dată livrare | Termen de expediere | Fereastră orară ignorată |
DESADV: avizul de expediție trimis înainte de camion
DESADV, cunoscut și ca ASN, este avizul electronic de expediție. Se transmite după ce marfa a fost pregătită și înainte ca aceasta să ajungă la depozitul retailerului.
Rolul lui este să anunțe exact ce pleacă: ce produse, în ce cantități, pe câți paleți și sub ce identificatori. Fiecare unitate logistică primește un cod SSCC, un număr unic tipărit pe eticheta paletului. Când paletul ajunge la recepție, operatorul scanează un singur cod, iar sistemul retailerului știe deja întregul conținut.
De ce contează pentru costuri
Un DESADV corect scurtează timpul de descărcare, reduce cozile la rampă și elimină numărarea manuală. Un DESADV incorect produce efectul invers: paletul este numărat bucată cu bucată, camionul staționează, iar în unele contracte apar penalizări pentru neconformitate.
Trei reguli practice reduc majoritatea problemelor:
- DESADV se generează din WMS, după colectare și ambalare, nu din comanda inițială.
- Conținutul avizului trebuie să reflecte marfa reală, inclusiv livrările parțiale.
- Mesajul trebuie transmis înaintea sosirii fizice a mărfii, nu simultan cu ea.
RECADV: confirmarea recepției, momentul adevărului
RECADV este mesajul prin care retailerul comunică ce a recepționat efectiv. Este documentul care spune dacă ce s-a comandat, ce s-a expediat și ce a intrat în depozit coincid.
În multe cazuri nu coincid. Apar cantități lipsă, produse deteriorate, refuzuri pentru termen de valabilitate insuficient sau recepții parțiale. RECADV transformă aceste diferențe din discuție telefonică în date structurate.
Cele trei comparații care contează
- ORDERS față de DESADV: cât s-a comandat față de cât s-a expediat, adică nivelul de serviciu al furnizorului.
- DESADV față de RECADV: cât s-a expediat față de cât s-a recepționat, adică pierderile de pe traseu și diferențele de numărare.
- RECADV față de INVOIC: baza reală de facturare.
Cine ignoră RECADV facturează cantitatea expediată și descoperă diferența abia la scadență, sub forma unei facturi neachitate integral. Cine îl folosește facturează cantitatea confirmată și își păstrează fluxul de numerar.
INVOIC: factura care se potrivește din prima
INVOIC este factura în format EDI. Se emite după RECADV și preia cantitățile confirmate, prețurile din comandă și eventualele discounturi negociate.
În România, mesajul INVOIC coexistă cu obligația de raportare în sistemul e-Factura al ANAF. Sunt două trasee diferite cu scopuri diferite: INVOIC este documentul comercial către partener, iar raportarea către ANAF este obligația fiscală. O platformă matură generează ambele din aceeași sursă de date, ca să nu existe divergențe între ce vede retailerul și ce vede autoritatea fiscală. Cerințele de conformitate și modul în care se leagă cele două fluxuri sunt detaliate în ghidul complet despre implementarea EDI.
De ce se blochează facturile
Blocarea unei facturi în retail are, de regulă, una dintre următoarele cauze:
- cantitate facturată diferită de cea recepționată, pentru că nu s-a folosit RECADV;
- preț diferit de cel din comandă, pentru că promoția nu a fost sincronizată în catalog;
- referință comandă lipsă sau greșită, ceea ce face imposibilă reconcilierea automată;
- unitate de măsură inconsistentă între comandă și factură.
Fiecare dintre aceste cauze este o problemă de date, nu de contabilitate. Motivul pentru care apar constant este că datele traversează mai multe sisteme.
Traseul complet, pas cu pas
Succesiunea logică a celor patru mesaje este următoarea:
- Retailerul emite ORDERS către furnizor.
- Furnizorul validează comanda și o înregistrează în ERP ca ordin de vânzare.
- WMS pregătește marfa, generează paleții și codurile SSCC.
- Furnizorul transmite DESADV înainte de plecarea camionului.
- Marfa ajunge la depozit, recepția scanează etichetele.
- Retailerul transmite RECADV cu cantitățile confirmate.
- Furnizorul emite INVOIC pe baza RECADV și raportează factura în e-Factura.
Timpul dintre pasul 1 și pasul 7 este, în relațiile bine puse la punct, de câteva zile. În relațiile gestionate manual, același ciclu poate depăși două săptămâni din cauza corecțiilor.
Cum se leagă mesajele de ERP, WMS și CRM
Cele patru mesaje nu trăiesc singure. Fiecare are un sistem sursă și un sistem destinație:
| Mesaj | Sursa datelor | Destinație principală |
|---|---|---|
| ORDERS | Sistemul retailerului | ERP furnizor, comandă de vânzare |
| DESADV | WMS furnizor | Sistemul de recepție al retailerului |
| RECADV | Sistemul retailerului | ERP și WMS furnizor |
| INVOIC | ERP furnizor | Contabilitatea retailerului și ANAF |
ERP-ul deține comanda, stocul valoric și factura. WMS-ul deține stocul fizic, loturile și unitățile logistice. Un soft CRM deține relația comercială: cine negociază, ce promoții sunt agreate, ce reclamații există și care este istoricul discuțiilor cu categoria de cumpărare.
Confuzia frecventă este că un CRM ar putea acoperi acest traseu. Nu poate, pentru că un CRM nu emite avize de expediție și nu confirmă recepții. În schimb, CRM-ul devine mult mai util când primește înapoi datele din EDI: un director de vânzări care vede nivelul de serviciu pe fiecare retailer, rata de refuz la recepție și valoarea facturilor blocate poartă o discuție complet diferită cu clientul său.
Ce să verifici înainte de a semna un proiect EDI
Înainte de implementare, câteva întrebări separă proiectele reușite de cele care se blochează:
- Ce mesaje cere efectiv fiecare retailer și în ce versiune de standard?
- Cine generează DESADV și de unde ia codurile SSCC?
- Se folosește RECADV ca bază de facturare sau se facturează pe expediție?
- Cum se leagă INVOIC de raportarea e-Factura, ca să nu existe dublă introducere?
- Cine monitorizează mesajele respinse și în cât timp se rezolvă?
Ultima întrebare este cea mai importantă. Un flux EDI nu se termină la go-live, ci este un proces operațional cu erori zilnice care trebuie tratate în ore, nu în zile.
Concluzia practică
ORDERS, DESADV, RECADV și INVOIC nu sunt patru abrevieri tehnice, ci patru puncte de control comercial. Comanda spune ce s-a cerut, avizul spune ce s-a trimis, confirmarea de recepție spune ce a intrat, iar factura spune ce se plătește. Când cele patru se potrivesc, relația cu retailerul devine previzibilă. Când nu se potrivesc, discuția se mută de la creștere la reconciliere.
Pentru un furnizor care vrea să scaleze în retail, cea mai bună investiție nu este un raport suplimentar, ci o disciplină a datelor de bază și o platformă care leagă ERP, WMS și CRM în același traseu al comenzii.