Răspuns scurt: ERP-ul este sistemul în care compania își ține propria evidență - stocuri, comenzi, livrări, facturi, costuri. EDI-ul este canalul prin care aceleași informații trec, în format standardizat, între compania ta și partenerii comerciali. Sunt două sisteme diferite pentru că rezolvă două probleme diferite: una internă, de gestiune, alta externă, de comunicare. Lucrează împreună doar dacă între ele există o integrare bidirecțională și o mapare corectă a câmpurilor.
Confuzia dintre cele două apare frecvent în discuțiile de proiect, mai ales când un furnizor primește cererea unui retailer de a "trece pe EDI" și presupune că este vorba de o funcție din ERP care trebuie doar activată. În realitate, cele două straturi se ating în puncte precise, iar felul în care sunt legate decide dacă fluxul comercial rulează fără intervenție manuală sau dacă echipa continuă să introducă comenzi de mână, cu documentul EDI doar arhivat undeva alături.
Ce face ERP-ul și unde se termină perimetrul lui
Un ERP este sistemul de evidență. Ține articolele și codurile interne, nivelurile de stoc pe depozite, comenzile de vânzare și de aprovizionare, documentele de livrare, facturile, încasările, costurile și legăturile cu contabilitatea. Fiecare document creat în ERP are consecințe: rezervă stoc, generează o obligație de livrare, produce o înregistrare contabilă.
Perimetrul ERP-ului se termină însă la granița companiei. ERP-ul știe ce a comandat clientul doar după ce cineva sau ceva a introdus acea comandă în el. Nu are, în mod nativ, nici o opinie despre cum arată comanda în sistemul clientului, ce coduri de articol folosește acesta, prin ce canal o trimite sau ce confirmare așteaptă înapoi. Aici începe zona EDI.
Ce face EDI-ul și de ce nu este un simplu export de fișiere
EDI (Electronic Data Interchange) este schimbul de documente comerciale structurate între sisteme informatice, fără reintroducere manuală. Cuvântul cheie este "structurat": nu un PDF trimis pe email, nu un Excel atașat, ci un mesaj cu o gramatică agreată, în care fiecare segment și fiecare câmp au un sens fix, identic pentru emitent și pentru destinatar.
Această gramatică este ceea ce face EDI-ul greu de improvizat. Un standard precum EDIFACT definește tipuri de mesaj și structura lor, dar fiecare partener mare publică propriul profil de implementare: ce câmpuri sunt obligatorii, ce coduri se accepta pentru unitățile de măsură, cum se identifică locația de livrare, ce se întâmplă când o linie de comandă nu poate fi livrată integral. Doi retaileri pot cere același tip de mesaj și totuși pretinde structuri diferite în detaliu.
La asta se adaugă partea de operare pe care un export din ERP nu o acoperă: validarea mesajului înainte de trimitere, confirmările tehnice de primire, reluarea automată în caz de eșec, urmărirea stării fiecărui document, arhivarea și corelarea cu identificatorii GS1 folosiți în relația cu retailul. Din acest motiv, în majoritatea implementărilor apare un strat dedicat, o platformă EDI conectată la ERP, care preia traducerea, transportul și monitorizarea, în timp ce ERP-ul rămâne singura sursă de adevăr pentru date.
Comparație pe roluri
| Criteriu | ERP | EDI |
|---|---|---|
| Rol principal | Evidența internă și execuția operațională | Schimbul standardizat de documente între companii |
| Utilizator direct | Echipele interne: vânzări, logistică, financiar | Sistemele partenerilor, prin conexiune automată |
| Sursa de adevăr | Da, pentru stoc, preț intern, document contabil | Nu, transportă și traduce ceea ce produce ERP-ul |
| Formatul datelor | Structuri proprii ale aplicației | Mesaje standard: EDIFACT, XML, flat file, JSON |
| Ce se schimbă când apare un partener nou | Rar, eventual coduri și date de client | Frecvent: profil de mesaj, mapare, protocol, teste |
| Efectul unei erori | Document intern greșit | Document respins de partener, livrare sau plată blocată |
Tabelul explică și de ce cele două sisteme evoluează în ritmuri diferite. ERP-ul se schimbă când se schimbă modul de lucru al companiei. Configurația EDI se schimbă de fiecare dată când apare un partener nou sau când un partener existent își actualizează cerințele.
Integrarea bidirecțională: cele două direcții nu sunt simetrice
O integrare EDI utilă merge în ambele sensuri, dar cele două direcții au caracteristici distincte.
Dinspre partener spre ERP (inbound). Aici intră comenzile și confirmările de recepție. Provocarea este validarea: mesajul trebuie verificat înainte de a deveni document în ERP, pentru că o comandă acceptată greșit se propagă în rezervare de stoc, în pregătirea livrării și în factură. Un articol necunoscut, o adresă de livrare care nu există în nomenclator sau o unitate de măsură neconvertită sunt cauze tipice pentru care un mesaj corect din punct de vedere tehnic nu poate fi transformat în comandă.
Dinspre ERP spre partener (outbound). Aici pleacă răspunsurile la comandă, avizele de expediție și facturile. Provocarea este momentul și corespondența cu realitatea fizică. Un aviz de expediție are sens doar dacă este trimis înainte ca marfa să ajungă și doar dacă descrie exact ce s-a încărcat, la nivel de linie și, unde se cere, de unitate logistică. Un aviz care nu corespunde livrării generează diferențe la recepție, iar diferențele la recepție se transformă în discuții pe facturi.
Bidirecțional înseamnă, prin urmare, mai mult decât "trimitem și primim". Înseamnă că starea unui document este urmărită pe tot parcursul: comanda primită are un răspuns, livrarea are un aviz, avizul are o recepție confirmată, recepția are o factură care se închide fără corecții.
Mapping: locul în care se câștigă sau se pierde automatizarea
Maparea este corespondența, câmp cu câmp, între mesajul EDI și structura din ERP. Este partea cea mai puțin spectaculoasă a unui proiect și, în practică, cea care consumă cel mai mult timp.
Elementele care apar aproape întotdeauna într-un exercițiu de mapare:
- Identificarea părților. Cine este cumpărătorul juridic, cine este locația de livrare, cine este entitatea care plătește. În relația cu retailul, aceste roluri sunt de obicei identificate prin coduri de locație, nu prin denumiri.
- Codificarea articolelor. Codul intern din ERP nu coincide cu codul folosit de partener. Corespondența trebuie ținută explicit, iar orice articol nou trebuie adăugat în ambele sisteme înainte de prima comandă.
- Unități de măsură și cantități. Comanda poate veni în cutii, bax sau paleți, iar stocul poate fi ținut în bucăți. Conversia trebuie definită, nu presupusă.
- Prețuri și condiții comerciale. Ce se întâmplă când prețul din comandă diferă de prețul din contract: se acceptă, se semnalează, se respinge.
- Referințe încrucișate. Numărul comenzii partenerului trebuie să se regăsească pe aviz și pe factură. Fără această referință, reconcilierea devine manuală.
- Tratarea excepțiilor. Livrare parțială, articol indisponibil, linie anulată. Fiecare caz are un mod de exprimare în mesaj și un efect în ERP.
O mapare bună se recunoaște după un semn simplu: numărul de documente care necesită intervenție umană scade și rămâne scăzut, chiar și când volumul crește.
Mesajele care compun fluxul
Ciclul comercial standard se exprimă prin câteva tipuri de mesaj. Ordinea lor este importantă, pentru că fiecare se sprijină pe precedentul.
- ORDERS - comanda transmisă de client. Conține articolele, cantitățile, locația și data de livrare solicitată.
- ORDRSP - răspunsul la comandă. Confirmă ce se livrează, semnalează liniile care nu pot fi acoperite și eventualele diferențe.
- DESADV - avizul de expediție. Trimis înainte de sosirea mărfii, descrie conținutul livrării și, unde se cere, structura pe unități logistice.
- RECADV - confirmarea de recepție. Arată ce a fost efectiv preluat de partener și este primul loc în care apar diferențele.
- INVOIC - factura. Corectă doar dacă se sprijină pe recepția confirmată și păstrează referințele către comandă și aviz.
În jurul acestui nucleu apar și alte mesaje, în funcție de relație: cataloage de articole și prețuri, rapoarte de vânzări sau de stoc din magazine, anunțuri de retur. O reprezentare vizuală a felului în care se înlănțuie aceste documente ajută mai mult decât o descriere textuală, iar fluxul comandă, livrare, facturare este exact locul unde se vede de ce ordinea și referințele contează.
API, SFTP, AS2: transportul, nu conținutul
O confuzie frecventă amestecă formatul mesajului cu modul lui de transport. Sunt straturi separate, iar decizia pe fiecare se ia din motive diferite.
- AS2 transportă mesaje prin HTTP cu semnătură și criptare, cu confirmare de primire. Apare des în relația cu partenerii mari, unde se cere dovada transmiterii.
- SFTP mută fișiere între directoare, pe canal securizat. Este simplu de operat și frecvent în schimburile programate, pe loturi.
- Rețelele VAN intermediază conexiunea, fiind utile când partenerul lucrează deja printr-un astfel de furnizor.
- API-ul este potrivit acolo unde e nevoie de răspuns imediat, mai ales pe integrarea internă dintre platforma EDI, ERP, magazinul online sau sistemul de depozit.
Alegerea nu ține de preferința furnizorului tău, ci de ce acceptă partenerul și de ce poate opera echipa ta. Un flux poate folosi simultan protocoale diferite pentru parteneri diferiți, păstrând aceeași mapare către ERP.
Cum arată o implementare care nu creează datorie tehnică
Câteva principii se repetă în proiectele care rezistă în timp:
Un singur sistem de evidență. ERP-ul rămâne sursa pentru stoc, articole și documente contabile. Platforma EDI nu ține o a doua versiune a adevărului.
Nomenclatoare curate înainte de primul test. Articole, coduri de partener, locații, unități de măsură. Un nomenclator incomplet transformă orice test într-o discuție despre date, nu despre flux.
Testare în ordinea fluxului, pe documente reale. Comandă, răspuns, aviz, recepție, factură. Fiecare pas validat înainte de a trece la următorul.
Monitorizare cu proprietar. Documentele blocate trebuie să apară într-un loc pe care cineva îl verifică zilnic, cu responsabilitate clară pentru rezolvare.
Extindere partener cu partener. Primul partener consumă cel mai mult efort. Al doilea reutilizează maparea de bază și cere doar ajustări de profil.
Concluzie
EDI și ERP nu concurează și nu se substituie. ERP-ul răspunde la întrebarea "ce se întâmplă în compania mea", EDI-ul la "cum comunic asta partenerilor, în formatul pe care îl cer, fără reintroducere manuală". Integrarea dintre ele nu este un proiect de conectare, ci un proiect de traducere: câmp cu câmp, mesaj cu mesaj, partener cu partener. Companiile care tratează maparea și monitorizarea ca parte a procesului, nu ca sarcină tehnică de o singură dată, ajung la fluxuri care rulează fără supraveghere constantă și scalează pe măsură ce se adaugă parteneri noi.
