Sincronizare stoc magazin online cu ERP: arhitectură, erori și bune practici

Sincronizarea stocului dintre un magazin online și un ERP pare, la prima vedere, o problemă simplă: ERP-ul are o cantitate, iar magazinul online trebuie să afișeze aceeași cantitate.

În realitate, lucrurile devin mult mai complicate imediat ce apar comenzi simultane, vânzări într-un showroom, produse rezervate, plăți online în așteptare, anulări, retururi, mai multe gestiuni sau situații în care unul dintre sisteme nu răspunde.

O integrare corectă nu înseamnă doar să transferi periodic o valoare dintr-un sistem în altul. Trebuie să definești cine este sursa adevărului, când se rezervă stocul, cum sunt tratate erorile și cum verifici ulterior dacă cele două sisteme au rămas sincronizate.

În acest articol analizăm arhitectura unei sincronizări de stoc între ecommerce și ERP și principalele probleme pe care trebuie să le iei în calcul înainte de implementare.

Ce înseamnă, de fapt, sincronizarea stocului?

Într-un sistem foarte simplu putem avea:

ERP: 20 bucăți
Magazin online: 20 bucăți

Dar într-un business real pot exista simultan:

• stoc fizic;
• stoc rezervat pentru comenzi online;
• stoc rezervat pentru comenzi din showroom;
• produse aflate în procesare;
• produse deteriorate sau nevandabile;
• comenzi neplătite;
• retururi;
• mai multe depozite sau gestiuni;
• vânzări efectuate direct în ERP;
• comenzi venite din alte marketplace-uri.

De aceea, înainte să scriem primul endpoint sau primul job de sincronizare, trebuie stabilit exact ce reprezintă fiecare valoare de stoc.

Primul pas: stabilește sistemul „source of truth”

Una dintre cele mai importante decizii este stabilirea sistemului care reprezintă sursa principală pentru fiecare tip de informație.

Într-un proiect putem avea, de exemplu:

Nu există o configurație universală. Important este ca responsabilitatea să fie explicită.

Problemele apar atunci când două sisteme pot modifica aceeași informație independent și nu există o regulă clară privind cine are prioritate.

De exemplu, dacă atât ERP-ul, cât și platforma ecommerce pot modifica stocul oficial, trebuie stabilit ce se întâmplă atunci când valorile diferă.

Stoc fizic, stoc rezervat și stoc disponibil

În multe platforme ecommerce este util să separăm cel puțin trei valori:

• stoc fizic – cantitatea care există efectiv;
• stoc rezervat – cantitatea alocată unor comenzi care nu au fost încă finalizate complet;
• stoc disponibil – cantitatea pe care utilizatorul o mai poate cumpăra.

În forma cea mai simplă:

stoc disponibil = stoc fizic - stoc rezervat

Exemplu:

Stoc fizic ERP:       10
Stoc rezervat:         3
Stoc disponibil:       7

Dacă magazinul online ar afișa direct cele 10 bucăți din ERP, ar putea vinde produse care sunt deja rezervate pentru alte comenzi.

De ce apare problema în showroom + magazin online?

Să presupunem că un business vinde același produs atât online, cât și într-un showroom.

ERP-ul raportează:

Stoc: 2 bucăți

În același timp:

1. un client cumpără o bucată în showroom;
2. actualizarea ERP-ului nu a ajuns încă în magazinul online;
3. un client online vede în continuare 2 bucăți disponibile;
4. plasează o comandă pentru 2 bucăți.

În acel moment avem trei produse promise, dar numai două produse fizice.

Aceasta este una dintre formele clasice de overselling.

Sincronizare în timp real sau sincronizare periodică?

Există mai multe strategii posibile.

În multe proiecte, soluția bună este o combinație.

Actualizările importante sunt transmise rapid, iar periodic rulează și o reconciliere completă între sisteme.

Sincronizarea operațională și reconcilierea nu sunt același lucru

Această diferență este importantă.

Sincronizarea operațională încearcă să țină sistemele actualizate pe măsură ce se întâmplă evenimentele.

Reconcilierea verifică ulterior dacă valorile au rămas corecte.

De exemplu, putem trimite actualizări la fiecare modificare de stoc, dar o dată pe zi să rulăm și un proces care compară:

stoc platformă
vs
stoc ERP

Dacă apar diferențe, acestea sunt raportate și pot fi corectate automat sau analizate manual.

Când trebuie rezervat stocul?

Aceasta este o altă decizie importantă.

Stocul poate fi rezervat:

• când produsul este adăugat în coș;
• la începutul checkout-ului;
• la plasarea comenzii;
• la inițierea plății;
• la confirmarea plății.

Fiecare variantă are avantaje și dezavantaje.

Rezervare la adăugarea în coș

Reduce riscul ca produsul să fie cumpărat de altcineva, dar poate bloca inutil stocul dacă utilizatorii abandonează coșul.

Rezervare la plasarea comenzii

Este o abordare frecventă. Produsul este rezervat atunci când comanda este creată, iar rezervarea expiră dacă plata nu este finalizată.

Rezervare doar după plată

Este mai simplă, dar pentru produse cu stoc foarte mic există riscul ca două persoane să plătească aproape simultan pentru ultima bucată.

Comenzi simultane și race conditions

Una dintre cele mai importante probleme tehnice apare atunci când două comenzi sunt procesate în același timp.

Să presupunem:

Stoc disponibil: 1

Clientul A și clientul B încearcă să cumpere simultan produsul.

Dacă procesul este:

1. citește stocul;
2. verifică dacă este mai mare decât 0;
3. creează comanda;
4. scade stocul;

ambele requesturi pot citi valoarea 1 înainte ca primul să o modifice.

Rezultatul poate fi:

Client A → comandă acceptată
Client B → comandă acceptată
Stoc real → 1

Pentru a preveni această situație pot fi folosite, în funcție de arhitectură:

• tranzacții de bază de date;
• row locking;
• operații atomice;
• sisteme de rezervare;
• queue-uri;
• alte mecanisme de concurență.

Aceste probleme sunt unul dintre motivele pentru care o integrare ERP nu trebuie tratată doar ca un import CSV mai sofisticat.

Ce facem cu comenzile neplătite?

Într-un magazin online cu plată prin card poate exista următorul flux:

Comandă creată
↓
Stoc rezervat
↓
Utilizator trimis la procesatorul de plăți
↓
Plată finalizată sau abandonată

Dacă plata eșuează sau expiră, stocul trebuie eliberat.

stoc rezervat
→ plată expirată
→ rezervarea este anulată
→ stocul revine disponibil

Este important ca procesul să fie automat. Altfel, comenzile abandonate pot bloca treptat stocul.

Statusurile comenzilor trebuie definite înainte de integrare

Nu este suficient să avem doar:

Nouă
Finalizată

În funcție de proiect putem avea:

• draft;
• pending payment;
• payment processing;
• paid;
• processing;
• ready for pickup;
• cancelled;
• expired;
• refunded.

Trebuie stabilit foarte clar care status rezervă stoc, care îl scade și care îl eliberează.

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

Nicio integrare externă nu trebuie proiectată pornind de la presupunerea că API-ul va răspunde întotdeauna corect.

Pot apărea:

• timeout-uri;
• erori HTTP;
• mentenanță;
• rate limits;
• probleme de autentificare;
• date invalide;
• răspunsuri incomplete.

Un sistem robust trebuie să știe ce face în astfel de situații.

Retry

Dacă eroarea este temporară, requestul poate fi repetat.

Nu recomandăm însă retry fără limită. Trebuie să existe un număr maxim de încercări și, de multe ori, un interval progresiv între ele.

Queue

Operațiile care nu trebuie executate instant pot fi trimise într-o coadă.

De exemplu, comanda poate fi salvată în platformă, iar transmiterea către ERP să fie procesată de un worker separat.

Logging

Fiecare eroare importantă trebuie înregistrată împreună cu suficiente informații pentru debugging.

Alertare

Dacă integrarea nu a mai sincronizat nimic de două ore, nu este suficient ca eroarea să existe într-un log pe care nu îl citește nimeni.

Pentru operațiile critice trebuie să existe alerte.

Idempotency: ce se întâmplă dacă requestul se repetă?

Este posibil ca platforma să trimită o comandă către ERP și să primească timeout.

Platforma nu știe dacă ERP-ul:

• nu a primit requestul;
• l-a primit, dar nu l-a procesat;
• l-a procesat, dar răspunsul nu a mai ajuns.

Dacă repetăm pur și simplu requestul, riscăm să creăm aceeași comandă sau factură de două ori.

De aceea operațiile importante trebuie să fie, pe cât posibil, idempotente.

Un mecanism simplificat poate folosi un identificator unic:

external_order_id = WEB-10583

Dacă ERP-ul primește a doua oară aceeași operație, poate identifica faptul că aceasta a fost deja procesată.

Mapping-ul produselor dintre sisteme

O integrare are nevoie de o metodă stabilă prin care să identifice același produs în ambele sisteme.

Pot exista:

platform_product_id
erp_product_id
SKU
cod produs
cod de bare

Nu recomandăm asocierea produselor doar după denumire.

Denumirea:

Hrana premium porumbei 20 kg

poate deveni ulterior:

Hrana Premium pentru Porumbei - 20 kg

Dacă denumirea este cheia de sincronizare, integrarea se poate rupe.

Este mai sigur să existe un identificator stabil între sisteme.

Produsele, prețurile și stocul nu trebuie sincronizate neapărat la fel

O greșeală frecventă este să tratăm toate datele unui produs ca pe o singură sincronizare.

În realitate putem avea:

Trebuie stabilită separat sursa pentru fiecare tip de informație.

Mai multe gestiuni și depozite

Lucrurile devin și mai interesante atunci când ERP-ul are mai multe gestiuni.

Exemplu:

Depozit București: 8
Showroom Cluj:      3
Depozit extern:     5

Magazinul online poate afișa:

Stoc total: 16

dar nu este obligatoriu ca toate cele 16 bucăți să poată fi livrate în aceleași condiții.

Pot exista reguli precum:

• showroom-ul nu livrează prin curier;
• un depozit deservește doar anumite regiuni;
• transferul între gestiuni durează o zi;
• anumite produse sunt rezervate vânzării fizice.

În astfel de cazuri, modelul de stoc trebuie proiectat în jurul procesului real al companiei.

Retururile și anulările nu înseamnă automat +1 la stoc

Atunci când o comandă este returnată, produsul nu trebuie întotdeauna adăugat imediat în stocul vandabil.

Trebuie verificat dacă:

• produsul a ajuns fizic în depozit;
• este intact;
• poate fi revândut;
• a fost recepționat în ERP;
• trebuie mutat într-o gestiune diferită.

Un retur poate genera un proces operațional propriu.

Logging și audit trail

Când două sisteme modifică aceleași procese, devine foarte important să putem răspunde la întrebarea:

De ce are produsul acesta stoc 8 acum, dacă ieri avea 12?

Pentru operațiile importante merită să salvăm:

• data și ora;
• produsul;
• valoarea veche;
• valoarea nouă;
• sistemul care a inițiat schimbarea;
• requestul sau evenimentul;
• răspunsul primit;
• eventuala eroare.

Fără audit trail, debugging-ul unei probleme de stoc poate deveni foarte dificil.

Reconcilierea periodică dintre ERP și magazinul online

Chiar și într-o integrare bine construită recomandăm un proces periodic de verificare completă.

Exemplu:

Produs A
ERP:       15
Platformă: 15
Status: OK

Produs B
ERP:        8
Platformă:  7
Status: DIFERENȚĂ

Sistemul poate genera un raport cu:

• produse cu stoc diferit;
• produse inexistente într-un sistem;
• mapping lipsă;
• sincronizări eșuate;
• ultimul moment în care produsul a fost actualizat.

În funcție de regulile businessului, diferențele pot fi corectate automat sau trimise spre verificare.

Ce trebuie monitorizat?

Pentru o integrare critică nu este suficient să știm că serverul este online.

Putem monitoriza:

• ultima sincronizare reușită;
• numărul joburilor eșuate;
• produse fără mapping;
• diferențe de stoc;
• durata requesturilor către ERP;
• timeout-uri;
• queue-uri blocate;
• numărul de retry-uri;
• comenzi care nu au ajuns în ERP.

Monitorizarea trebuie să fie orientată spre procesul de business, nu doar spre infrastructură.

Un exemplu simplificat de arhitectură

ERP
 │
 │ produse / stoc
 ▼
API / Integration Layer
 │
 ▼
Platformă ecommerce
 │
 ├── stoc ERP
 ├── stoc rezervat
 └── stoc disponibil
 │
 ▼
Comandă
 │
 ▼
Queue / Integration Layer
 │
 ▼
ERP

Avantajul unui integration layer este că logica dintre cele două sisteme nu trebuie împrăștiată în zeci de locuri.

Aici putem gestiona:

• mapping;
• transformarea datelor;
• retry;
• logging;
• idempotency;
• monitorizare.

Webhook sau polling?

Dacă ERP-ul oferă webhook-uri pentru evenimentele relevante, acestea pot permite actualizări foarte rapide.

Exemplu:

Stoc modificat în ERP
↓
Webhook
↓
Platformă ecommerce actualizată

Dacă ERP-ul nu oferă webhook-uri, platforma poate verifica periodic API-ul:

La fiecare 5 minute:
→ cere modificările
→ procesează diferențele
→ actualizează platforma

Uneori folosim o combinație: webhook pentru actualizările rapide și sincronizare completă periodică pentru siguranță.

Integrarea ERP nu trebuie să blocheze inutil checkout-ul

O altă decizie de arhitectură este dacă utilizatorul trebuie să aștepte răspunsul ERP-ului în momentul plasării comenzii.

Un flux de tip:

Client apasă „Plasează comanda”
↓
Platformă așteaptă ERP-ul
↓
ERP răspunde după 8 secunde
↓
Comanda este creată

poate produce o experiență slabă și poate transforma indisponibilitatea ERP-ului într-o indisponibilitate a magazinului online.

În multe cazuri este mai robust:

Client plasează comanda
↓
Comanda este salvată local
↓
Utilizatorul primește confirmarea
↓
Transmiterea către ERP se procesează asincron

Desigur, această abordare trebuie adaptată regulilor comerciale și fiscale ale proiectului.

Când este suficient un plugin și când ai nevoie de integrare custom?

Pentru fluxuri standard, un plugin existent poate fi suficient.

O integrare custom devine justificată atunci când apar cerințe precum:

• mai multe gestiuni;
• stoc rezervat separat;
• showroom + ecommerce;
• reguli B2B;
• prețuri diferite pe clienți;
• fluxuri speciale de facturare;
• ERP cu API particular;
• marketplace-uri multiple;
• automatizări;
• reguli proprii de reconciliere.

Înainte să alegi platforma tehnică, merită să definești procesele. Am discutat mai larg acest subiect în ghidul despre alegerea unei platforme pentru magazin online.

Ce întrebări trebuie puse înainte de implementare?

• Unde este creat produsul?
• Cine poate modifica produsul?
• Cine deține stocul oficial?
• Există mai multe gestiuni?
• Există showroom?
• Când se rezervă stocul?
• Când se eliberează rezervarea?
• Ce se întâmplă la plată eșuată?
• Ce se întâmplă la retur?
• Cum identificăm același produs în ambele sisteme?
• Cine stabilește prețul?
• Cât de rapid trebuie actualizat stocul?
• ERP-ul oferă webhook-uri?
• Ce facem dacă API-ul nu răspunde?
• Cum reluăm operațiile eșuate?
• Cum detectăm diferențele dintre sisteme?
• Cine este notificat când integrarea nu funcționează?

Răspunsurile la aceste întrebări trebuie să existe înainte de dezvoltare, nu după prima problemă de stoc.

Integrarea ERP ca parte dintr-o platformă mai mare

În proiectele complexe, magazinul online poate fi doar una dintre componente.

Arhitectura poate include:

• ERP;
• CRM;
• platformă ecommerce;
• showroom;
• curieri;
• procesatori de plăți;
• marketplace-uri;
• facturare;
• sisteme de marketing;
• platforme interne de management.

În acest caz, întrebarea nu mai este doar „cum conectăm ERP-ul la magazin?”, ci cum circulă datele prin întregul ecosistem.

Pentru astfel de proiecte poate fi mai potrivită o platformă web custom sau un integration layer dedicat.

Automatizarea nu înseamnă doar sincronizare

După ce sistemele pot comunica între ele, putem automatiza procese suplimentare.

De exemplu:

Comandă plătită
↓
Rezervare confirmată
↓
Comandă transmisă în ERP
↓
Document generat
↓
Curier notificat
↓
AWB creat
↓
Client notificat
↓
Status sincronizat

Valoarea reală apare atunci când reducem operațiile manuale, nu doar când două baze de date au aceeași valoare.

Dacă proiectul include mai multe procese de acest tip, este util să le analizăm încă din etapa de planificare a platformei online.

Întrebări frecvente

ERP-ul trebuie să fie întotdeauna sursa principală pentru stoc?

Nu obligatoriu. În multe companii ERP-ul deține stocul fizic, dar platforma ecommerce gestionează separat rezervările și disponibilitatea operațională. Arhitectura depinde de procesele companiei.

Cât de des trebuie sincronizat stocul?

Depinde de viteza cu care se vând produsele și de canalele existente. Pentru produse cu rotație mare poate fi necesară o actualizare aproape în timp real. Pentru alte businessuri, sincronizarea periodică poate fi suficientă.

Este suficient să sincronizez stocul o dată pe oră?

Poate fi suficient în anumite businessuri, dar nu dacă același stoc este vândut rapid prin mai multe canale. Trebuie evaluat riscul de overselling.

Ce este stocul rezervat?

Este cantitatea alocată unor comenzi care nu au fost încă finalizate complet. Separarea lui de stocul fizic ajută la calcularea cantității care poate fi vândută altor clienți.

Ce se întâmplă dacă ERP-ul cade?

O integrare bine proiectată trebuie să poată trata indisponibilitatea temporară prin queue-uri, retry-uri, logging și reconciliere ulterioară, fără să piardă operațiile importante.

Este nevoie de dezvoltare custom pentru orice integrare ERP?

Nu. Pentru scenarii standard pot exista pluginuri sau conectori potriviți. Dezvoltarea custom devine justificată atunci când procesele și regulile businessului depășesc capabilitățile unei integrări standard.

Concluzie

Sincronizarea stocului dintre un magazin online și un ERP nu este doar un transfer de cantități.

Trebuie definite clar sursa datelor, stocul fizic, rezervările, comenzile simultane, erorile API, retry-urile, mapping-ul produselor și procesul de reconciliere.

Cu cât businessul are mai multe canale de vânzare și mai multe sisteme, cu atât arhitectura integrării devine mai importantă.

Pentru proiectele în care ecommerce-ul trebuie conectat cu ERP, CRM, gestiuni, plăți, curieri sau procese interne, o integrare proiectată în jurul businessului este de obicei mai valoroasă decât adăugarea succesivă a unor pluginuri independente.

Dacă pregătești un astfel de proiect, poți vedea serviciile noastre de dezvoltare magazin online și dezvoltare platforme web custom și SaaS sau ne poți contacta pentru a analiza arhitectura și integrarea necesară.