Integrare ERP cu o platformă web: produse, clienți, stocuri, comenzi și facturi

Integrarea unui ERP cu o platformă web poate elimina multe operații manuale, dar numai dacă este proiectată pornind de la procesele reale ale companiei. În practică, problema nu este doar să conectezi două API-uri. Trebuie stabilit ce date circulă între sisteme, în ce direcție, cine le poate modifica și ce se întâmplă atunci când cele două sisteme nu mai sunt de acord.

Am întâlnit proiecte în care ERP-ul gestiona produsele, stocurile și facturarea, în timp ce platforma web gestiona comenzile, clienții, aprobările și alte fluxuri operaționale. În alte situații, platforma era sistemul principal pentru o parte dintre date și trimitea către ERP doar informațiile necesare contabilității sau gestiunii.

De aceea, înainte de implementare, încercăm să nu privim integrarea ca pe o simplă listă de endpoint-uri. Mai întâi definim responsabilitatea fiecărui sistem și traseul fiecărui tip de informație.

Ce înseamnă o integrare ERP cu o platformă web?

O integrare ERP permite platformei web și sistemului ERP să schimbe automat informații fără ca utilizatorii să le introducă de două ori.

În funcție de business, pot fi sincronizate produse, clienți, furnizori, stocuri, prețuri, comenzi, încasări, facturi, documente sau alte informații operaționale.

Un exemplu simplu ar fi un distribuitor care își administrează articolele și stocurile în ERP, dar folosește o platformă web custom pentru preluarea comenzilor. Produsele și stocurile ajung din ERP în platformă, iar comenzile confirmate circulă în direcția opusă.

Pe hârtie, fluxul pare simplu. Complexitatea apare în detalii: ce se întâmplă dacă un produs este modificat în ambele sisteme, dacă ERP-ul este indisponibil sau dacă o comandă a fost primită de ERP, dar răspunsul s-a pierdut pe drum.

Începe cu procesul de business, nu cu API-ul

Una dintre cele mai frecvente greșeli este să începi proiectarea integrării uitându-te direct în documentația API și construind funcționalități în jurul endpoint-urilor disponibile.

API-ul ne spune ce ne permite tehnic un sistem să facem. Nu ne spune însă cum ar trebui să funcționeze businessul.

Înainte să stabilim arhitectura, vrem să știm cum este creat un produs, cine îl poate modifica, unde se stabilește prețul, când este considerată o comandă finală, când trebuie trimisă în ERP și ce se întâmplă dacă ulterior este anulată.

Abia după ce aceste reguli sunt clare putem decide ce endpoint-uri folosim și unde sunt necesare mecanisme suplimentare.

Fiecare tip de informație trebuie să aibă un sistem principal

În proiectele cu mai multe aplicații folosim des ideea de source of truth: sistemul care are autoritatea principală asupra unei anumite informații.

De exemplu, într-un proiect putem stabili că produsele și stocurile sunt administrate în ERP, clienții sunt creați în platforma web, iar comenzile pornesc din platformă și sunt trimise către ERP după validare.

Tabelul nu este o regulă universală. Într-o altă companie responsabilitățile pot fi complet diferite. Important este să nu avem două sisteme care modifică aceeași informație fără o regulă de prioritate.

Integrarea produselor

Sincronizarea produselor pare una dintre cele mai simple părți ale proiectului, dar trebuie stabilit ce înseamnă concret un produs în fiecare sistem.

ERP-ul poate avea denumire, cod intern, cod de bare, unitate de măsură, cotă TVA, gestiune și preț. Platforma web poate avea în plus imagini, descrieri comerciale, categorii, specificații tehnice, SEO, variante sau traduceri.

Nu toate aceste date trebuie neapărat administrate în același loc.

O variantă sănătoasă poate fi ca ERP-ul să furnizeze informațiile operaționale, iar platforma web să gestioneze partea de prezentare. Astfel, modificarea unei descrieri SEO nu trebuie să ajungă în ERP, iar actualizarea cotei TVA nu trebuie făcută manual și în platformă.

Identificarea produselor trebuie să fie stabilă

Pentru sincronizare avem nevoie de un identificator care nu se schimbă atunci când se modifică denumirea produsului.

În practică putem păstra atât ID-ul intern al platformei, cât și ID-ul sau codul produsului din ERP. SKU-ul și codul de bare pot fi utile, dar nu trebuie să presupunem că sunt întotdeauna unice sau imuabile fără să verificăm regulile companiei.

Sincronizarea după numele produsului este fragilă. O simplă corectare de denumire poate face ca sistemul să considere că are de-a face cu un produs nou.

Integrarea stocurilor

Stocul este una dintre zonele în care apar cele mai multe probleme, pentru că aceeași cantitate poate fi afectată de mai multe canale de vânzare.

Dacă există magazin online, showroom, agenți de vânzări sau marketplace-uri, simpla copiere periodică a stocului din ERP poate să nu fie suficientă.

Platforma poate avea nevoie să țină cont și de produsele deja rezervate pentru comenzi aflate în procesare. Dacă ERP-ul raportează 20 de bucăți, dar 5 sunt deja rezervate în platformă, disponibilitatea reală pentru o comandă nouă poate fi 15.

Am detaliat separat această problemă în articolul despre sincronizarea stocului dintre magazin online și ERP, pentru că necesită reguli proprii privind rezervările, comenzile simultane și reconcilierea.

Integrarea clienților

În cazul clienților trebuie stabilit mai întâi unde este creată înregistrarea inițială.

Dacă un client își face cont într-o platformă B2B, este posibil ca acesta să fie creat mai întâi în platformă și transmis ulterior către ERP. În schimb, într-un sistem folosit în principal de echipa internă, clienții pot exista deja în ERP și pot fi importați în platformă.

Trebuie tratate atent situațiile în care aceeași companie apare în ambele sisteme cu date ușor diferite.

De exemplu, o firmă poate exista în ERP cu denumirea juridică, iar în platformă cu un nume comercial. Dacă încercăm să găsim duplicatele doar după nume, rezultatul poate fi nesigur.

Pentru companii putem folosi identificatori precum CUI-ul, iar pentru persoane sau alte tipuri de clienți trebuie stabilită o strategie potrivită și legală pentru datele disponibile.

Comenzile trebuie trimise în ERP în momentul potrivit

Nu orice comandă creată într-o platformă trebuie trimisă imediat către ERP.

Într-un ecommerce cu plată online putem avea comenzi create, dar încă neplătite. Într-o platformă B2B poate exista un flux de aprobare înainte ca o comandă să fie considerată fermă. În alt proiect, un operator poate valida manual produsele și prețurile înainte ca informația să ajungă în ERP.

De aceea, definim un eveniment clar care declanșează integrarea.

Poate fi momentul în care plata este confirmată, comanda este aprobată sau statusul devine „confirmată”.

La fel de important este să stabilim ce facem dacă după transmiterea către ERP comanda se modifică sau se anulează.

Facturile și documentele fiscale

În multe proiecte preferăm ca ERP-ul să rămână sistemul responsabil de documentele fiscale, deoarece acolo există deja gestiunea contabilă și procesele asociate.

Platforma trimite datele necesare, iar ERP-ul creează documentul conform propriilor reguli.

Dacă platforma trebuie să afișeze factura utilizatorului, putem aduce înapoi numărul, seria, statusul sau fișierul, în funcție de ceea ce permite integrarea.

Este important să nu presupunem că orice ERP oferă prin API toate operațiile disponibile în interfața sa. Uneori există acces doar la un subset de funcționalități, iar arhitectura platformei trebuie adaptată la această limitare.

Sincronizare într-un singur sens sau bidirecțională?

O integrare bidirecțională sună mai complet, dar nu este automat mai bună.

Dacă produsele sunt administrate exclusiv în ERP, nu există un motiv bun pentru ca platforma să poată modifica aceleași câmpuri și să le trimită înapoi.

Cu cât mai multe informații pot fi editate în ambele sisteme, cu atât cresc situațiile de conflict.

De aceea, preferăm de multe ori fluxuri clare, într-un singur sens pentru fiecare categorie de date. Integrarea poate fi bidirecțională per ansamblu, dar asta nu înseamnă că fiecare informație trebuie sincronizată în ambele direcții.

Ce facem când aceeași informație este modificată în ambele sisteme?

Dacă această situație este posibilă, trebuie stabilită o regulă înainte de implementare.

Putem decide că ERP-ul câștigă întotdeauna pentru anumite câmpuri, că cea mai recentă modificare are prioritate sau că diferențele trebuie trimise unui operator pentru verificare.

Varianta „ultima modificare câștigă” pare simplă, dar poate produce rezultate nedorite. Dacă un import întârziat ajunge după o modificare făcută manual, poate suprascrie o valoare corectă.

Pentru informații importante preferăm reguli explicite, nu presupuneri.

API-ul ERP-ului influențează mult arhitectura

Nu toate ERP-urile oferă aceleași posibilități.

Unele au API REST modern, webhook-uri și identificatori clari. Altele oferă doar câteva endpoint-uri pentru import și export sau necesită sincronizări periodice.

De aceea, înainte să promitem o anumită automatizare, verificăm documentația și testăm efectiv operațiile disponibile.

Este posibil ca ERP-ul să permită preluarea stocului, dar să nu permită modificarea lui directă. Sau poate permite importarea unei facturi, dar nu și ștergerea acesteia prin API.

În astfel de situații nu încercăm să forțăm integrarea să imite funcții care nu există. Adaptăm fluxul astfel încât responsabilitatea să rămână în sistemul potrivit.

Webhook-uri sau sincronizare periodică?

Dacă ERP-ul poate trimite webhook-uri atunci când apar modificări, platforma poate reacționa aproape imediat.

În lipsa acestora, platforma trebuie să verifice periodic dacă există date noi sau modificate.

Polling-ul nu este neapărat o soluție slabă. Pentru unele businessuri o sincronizare la câteva minute sau chiar la o oră este suficientă. Frecvența trebuie stabilită după impactul real al întârzierii.

Pentru date critice putem combina sincronizarea incrementală cu o verificare completă periodică.

Integrarea nu trebuie să depindă de un singur request

O greșeală frecventă este să construim fluxul astfel încât acțiunea utilizatorului să aștepte direct după ERP.

Dacă un operator salvează o comandă, iar platforma trebuie să aștepte zece secunde după răspunsul ERP înainte să îi confirme acțiunea, fiecare problemă externă devine imediat o problemă de utilizare a platformei.

În multe cazuri salvăm mai întâi informația în sistemul nostru și procesăm integrarea separat, printr-un job sau queue. Utilizatorul își poate continua activitatea, iar platforma urmărește dacă sincronizarea a reușit.

Există și situații în care răspunsul ERP-ului este necesar înainte să permitem continuarea fluxului. Important este ca decizia să fie făcută intenționat.

Retry-urile trebuie controlate

Un request către ERP poate eșua temporar din cauza unei probleme de rețea, a unui timeout sau a unei perioade de mentenanță.

Nu vrem să marcăm operația definitiv eșuată la prima problemă, dar nici să repetăm la infinit același request.

De obicei folosim un număr limitat de încercări și creștem intervalul dintre ele. Dacă după mai multe tentative operația nu reușește, aceasta trebuie să apară într-un sistem de monitorizare sau să genereze o alertă.

Foarte important este și tipul erorii. Un timeout poate justifica retry. Un request respins pentru date invalide nu se va rezolva dacă îl repetăm de zece ori.

Idempotency și operațiile duplicate

Una dintre situațiile clasice într-o integrare apare atunci când platforma trimite o comandă, ERP-ul o procesează, dar răspunsul nu ajunge înapoi.

Din perspectiva platformei, requestul a eșuat. Dacă îl trimitem din nou fără nicio protecție, riscăm să creăm aceeași comandă de două ori.

Pentru operațiile importante folosim identificatori externi sau alte mecanisme prin care aceeași acțiune poate fi recunoscută dacă este repetată.

Același principiu este important pentru facturi, plăți, mișcări de stoc și orice operație care nu trebuie executată de două ori.

Nu ascunde erorile de integrare

O integrare care „merge în majoritatea cazurilor” poate crea probleme serioase dacă nimeni nu știe ce s-a întâmplat cu restul operațiilor.

În platformele custom încercăm să facem starea sincronizării vizibilă acolo unde este relevant.

Un administrator poate vedea, de exemplu, că o comandă a fost creată în platformă, dar transmiterea către ERP a eșuat. Poate exista un buton de retry, detalii despre eroare și momentul ultimei încercări.

Este mult mai ușor să rezolvi o problemă atunci când sistemul spune clar ce operație nu a reușit decât atunci când aceasta este descoperită după câteva zile într-un raport contabil.

Logging și audit trail

Pentru integrările importante păstrăm suficiente informații încât să putem reconstrui ce s-a întâmplat.

Putem salva tipul operației, identificatorii entităților implicate, momentul trimiterii, rezultatul, numărul de încercări și eroarea primită.

Nu este nevoie să stocăm necontrolat toate payload-urile pentru totdeauna, mai ales dacă acestea conțin date personale. Logging-ul trebuie proiectat și din perspectiva securității și a retenției datelor.

Reconcilierea este necesară chiar și când integrarea pare stabilă

Chiar dacă sincronizarea funcționează în timp real, este util să existe procese care verifică periodic dacă sistemele au rămas consistente.

Putem compara, de exemplu, comenzile confirmate din platformă cu cele existente în ERP sau produsele active dintr-un sistem cu cele din celălalt.

Reconcilierea este mecanismul prin care descoperim problemele care au trecut neobservate: un job care a eșuat, o modificare făcută manual, un produs fără mapping sau o operație externă care nu a fost procesată.

Integrarea ERP cu CRM-ul

În multe companii, ERP-ul nu este singurul sistem cu care trebuie să comunice platforma.

Poate exista și un CRM în care sunt gestionate lead-urile, oportunitățile și activitatea comercială.

În acest caz trebuie să evităm ca fiecare sistem să fie conectat direct cu toate celelalte fără o arhitectură clară. Altfel, ajungem rapid la reguli duplicate și greu de urmărit.

De exemplu, un client poate porni ca lead în CRM, deveni client în platformă după semnarea contractului și fi creat ulterior în ERP atunci când trebuie emis primul document.

Nu toate sistemele au nevoie de toate datele în același moment.

Integrarea ERP într-o platformă SaaS

Pentru produsele SaaS apare o dificultate suplimentară: fiecare client poate folosi alt ERP sau o configurație diferită.

În acest caz este util să separăm logica platformei de logica unui furnizor ERP concret.

Putem avea un strat de integrare intern care definește operațiile de care platforma are nevoie, iar fiecare conector implementează acele operații pentru sistemul respectiv.

Astfel, restul aplicației nu trebuie să știe dacă în spate comunicăm cu ERP-ul A, ERP-ul B sau cu un sistem construit intern de client.

Această separare contează mai ales atunci când produsul trebuie să crească și să suporte mai multe integrări în timp.

Securitatea integrării

O integrare ERP poate avea acces la informații comerciale importante și trebuie tratată ca atare.

Credentialele API nu trebuie păstrate în cod, requesturile trebuie făcute prin conexiuni securizate, iar permisiunile trebuie limitate la operațiile necesare.

Dacă API-ul permite separarea permisiunilor, nu are sens să oferim acces la administrarea completă a ERP-ului unui serviciu care trebuie doar să citească stocul.

Trebuie să ne gândim și la rotația credentialelor, logging-ul accesului și ce se întâmplă atunci când un token expiră.

Testarea trebuie făcută și pe scenarii de eroare

Este ușor să testezi cazul ideal: creezi o comandă, ERP-ul răspunde cu succes și informația apare unde trebuie.

Mai important este să verificăm ce se întâmplă dacă ERP-ul răspunde după 20 de secunde, dacă trimite o eroare, dacă același request ajunge de două ori, dacă un produs nu are corespondent sau dacă platforma este repornită în mijlocul unei sincronizări.

Problemele reale apar rar în cazul ideal.

Staging și lansarea integrării

Ideal, ERP-ul oferă un mediu de testare. Dacă nu există, trebuie stabilit foarte atent cum verificăm integrarea fără să contaminăm datele reale.

La lansare preferăm de multe ori să activăm pe rând fluxurile importante și să monitorizăm rezultatele.

De exemplu, putem începe cu importul de produse și stocuri, apoi activa transmiterea comenzilor și ulterior alte automatizări.

O lansare controlată este mai sigură decât activarea simultană a tuturor fluxurilor după câteva teste locale.

Ce monitorizăm după lansare?

Integrarea nu este terminată în momentul în care primul request funcționează.

În funcție de importanța procesului, urmărim ultima sincronizare reușită, numărul operațiilor eșuate, timpul de răspuns al ERP-ului, joburile blocate, retry-urile și eventualele diferențe găsite la reconciliere.

Pentru un proces critic vrem să aflăm că integrarea nu mai funcționează înainte să ne spună clientul că lipsesc comenzile din ERP.

Când este justificată o integrare custom?

Pentru procese standard poate exista deja un plugin sau un conector suficient de bun. Nu are sens să dezvoltăm custom doar pentru că putem.

Integrarea proprie începe să aibă sens atunci când există reguli specifice de business, mai multe sisteme, fluxuri de aprobare, mai multe gestiuni, prețuri speciale, procesare asincronă, reconciliere, logging avansat sau cerințe pe care un conector generic nu le poate acoperi.

În astfel de proiecte integrarea devine parte din arhitectura aplicației, nu doar o extensie instalată separat.

Întrebări pe care le punem înainte să estimăm o integrare ERP

Înainte de estimare încercăm să clarificăm cel puțin următoarele lucruri:

• Ce ERP este folosit și ce API oferă?
• Ce date trebuie sincronizate?
• În ce direcție circulă fiecare tip de informație?
• Unde se creează produsele și clienții?
• Ce sistem este sursa principală pentru stoc și preț?
• Când trebuie transmisă o comandă?
• Cine emite documentele fiscale?
• Există mai multe gestiuni sau puncte de lucru?
• Cât de repede trebuie să ajungă modificările în celălalt sistem?
• Ce facem când ERP-ul este indisponibil?
• Există posibilitatea de duplicate?
• Cine trebuie notificat când sincronizarea eșuează?
• Avem nevoie de reconciliere periodică?

Răspunsurile la aceste întrebări ne permit să estimăm mult mai realist proiectul decât simpla formulare „avem nevoie să conectăm platforma la ERP”.

Integrarea ERP ca parte din automatizarea companiei

Cea mai mare valoare a unei integrări nu este faptul că două baze de date conțin aceeași informație.

Valoarea apare atunci când putem elimina pași manuali dintr-un proces. O comandă poate ajunge automat din platformă în ERP, documentul rezultat poate fi asociat clientului, un alt sistem poate primi informațiile pentru livrare, iar echipa poate vedea statusul fără să introducă aceleași date în mai multe aplicații.

În momentul acela nu mai vorbim doar despre o integrare tehnică, ci despre automatizarea unui proces de business.

Tocmai de aceea, atunci când dezvoltăm o platformă web custom sau un produs SaaS, încercăm să înțelegem întregul flux înainte să alegem soluția tehnică.

Pentru proiectele aflate încă în etapa de definire, este util și ghidul nostru despre cum planifici o platformă online de la idee la lansare.

Întrebări frecvente

Orice ERP poate fi integrat cu o platformă web?

Nu automat. Depinde de posibilitățile oferite de ERP: API, importuri, exporturi, webhook-uri sau alte mecanisme de integrare. Primul pas este verificarea documentației tehnice.

Integrarea trebuie să fie în timp real?

Nu în toate proiectele. Stocul poate avea nevoie de actualizări foarte rapide, în timp ce alte informații pot fi sincronizate o dată pe oră sau chiar mai rar. Frecvența trebuie stabilită după impactul asupra procesului.

ERP-ul trebuie să fie sistemul principal pentru toate datele?

Nu. Poate fi sursa principală pentru stoc și facturare, în timp ce platforma web este sistemul principal pentru comenzi, workflow-uri sau alte date.

Ce se întâmplă dacă ERP-ul nu răspunde?

În funcție de proces, operația poate fi pusă într-o coadă și reluată ulterior. Pentru fluxurile critice sunt necesare logging, retry și alertare.

Este mai bună o integrare bidirecțională?

Nu neapărat. Pentru fiecare tip de informație este mai important să existe o direcție și o responsabilitate clară decât să poată fi modificată din ambele sisteme.

Cât durează o integrare ERP?

Depinde foarte mult de API și de procese. O sincronizare simplă de produse poate fi relativ rapidă, în timp ce integrarea produselor, stocurilor, clienților, comenzilor și documentelor, cu retry și reconciliere, este un proiect semnificativ mai complex.

Concluzie

O integrare ERP bine construită pornește de la responsabilitatea fiecărui sistem și de la modul în care circulă datele prin companie.

Produsele, clienții, stocurile, comenzile și facturile nu trebuie tratate ca un singur proces de sincronizare. Fiecare are propriile reguli, propria sursă de adevăr și propriile situații de eroare.

Cu cât integrarea este mai importantă pentru activitatea zilnică, cu atât devin mai necesare mecanisme precum queue-uri, retry, idempotency, logging, reconciliere și monitorizare.

Dacă ai un ERP, CRM sau alte sisteme care trebuie conectate într-un singur flux operațional, putem analiza procesul și construi o platformă web adaptată modului în care funcționează businessul. Pentru un proiect concret, ne poți trimite cerințele și putem stabili ce merită automatizat și cum ar trebui împărțită responsabilitatea între sisteme.