Problema: o tonă de greșeli care costă
Un distribuitor UE tipic are:
- 5.000–50.000 SKU-uri active
- 200–2.000 clienți B2B cu condiții comerciale individuale
- 3–8 nivele de preț (lista, distribuitor, reseller premium, reseller standard, contract anual)
- Prețuri promoționale temporare suprapuse peste cele de mai sus
Dacă portalul B2B afișează prețuri vechi sau stocuri inexistente, fiecare comandă greșită costă: anulare, conflict cu clientul, marjă pierdută, încărcare pe ops. La 1.000 comenzi/lună, 2% rată de eroare = 20 incendii. Acceptabil zero.
Cine ține adevărul despre ce
Best practice care funcționează la scară:
| Date | Source of truth | Citește din | Nu scrie aici |
|---|---|---|---|
| Preț listă SKU | ERP | CRM, portal | CRM |
| Cost SKU | ERP | nimeni (intern) | CRM, portal |
| Discount per client | CRM | ERP la facturare, portal la afișare | ERP |
| Stoc fizic | WMS | ERP, CRM, portal | CRM |
| ATP (disponibil de promis) | calcul ERP | CRM, portal | nicăieri direct |
| Contract cadru | CRM | ERP la confirmare comandă | ERP |
Arhitectura sincronizării
Stratul 1: ERP → CRM (preț listă, stoc, ATP)
- Frecvență: event-driven pe modificare preț, la 5 minute pe stoc/ATP
- Mecanism: webhooks sau message bus
- Volume tipice: 100–500 evenimente/oră pentru un catalog activ
Stratul 2: CRM → portal B2B (condiții comerciale per client)
- Frecvență: la login client + la fiecare modificare manuală de condiții
- Mecanism: API call sincron, cache 15 minute pe nivelul de discount
- Personalizare: portalul aplică formula
pret_listă × (1 − discount_client) + adaosuri contract
Stratul 3: Portal → CRM (comenzi, cereri de ofertă)
- Frecvență: real-time la submit
- Mecanism: webhook în CRM, creează deal automat
- Validare: stoc verificat încă o dată la submit (poate s-a schimbat)
Reguli care previn dezastrele
1. Preț nu se modifică niciodată direct în CRM
Modificările de preț listă pleacă din ERP. Modificările de condiții per client pleacă din CRM. Niciodată un vânzător nu schimbă prețul listă „pentru clientul lui” — schimbă discountul.
2. Cache cu invalidare explicită
Portalul cache-uiește prețurile per client 15 minute. La fiecare modificare de discount în CRM, eveniment de invalidare. Niciodată cache infinit.
3. ATP recalculat la fiecare modificare
ATP = stoc fizic − comenzi confirmate + sosiri în fereastră. Orice modificare în oricare din cele 3 → recalcul. Niciodată ATP cached mai mult de 60 secunde.
4. Audit log obligatoriu
Fiecare modificare de preț (listă sau client) logată cu user, timestamp, valoare veche, valoare nouă. Audit-ul comercial îți va cere asta inevitabil.
Stack-uri uzuale pentru distribuitori UE
- SAP Business One + portal proprietar — solid, scump, cere echipă tehnică
- Microsoft Dynamics 365 BC + Sana Commerce — frecvent în nordul UE
- Odoo cu modul website + B2B — open-source, bun pentru sub 5M EUR cifră
- Stack integrat nativ — pentru companii românești cu reseller-i UE, CRMconnect integrează CRM + OMS + portal B2B într-un singur produs, ceea ce reduce sincronizările la zero (un singur model de date)
SoftOne e prezent în Grecia și extins în România cu funcționalități similare, dar cu documentație publică API mai limitată decât SAP sau Microsoft.
Cum măsori sănătatea sincronizării
- Discrepanțe preț portal vs CRM: sub 0.1% din SKU-uri active
- Comenzi anulate din motiv stoc: sub 1% lunar
- Latență update ATP: sub 60 secunde la 95-ile
- Timpul de la modificare preț ERP la afișare portal: sub 5 minute
Dacă vreuna depășește pragul, integrarea ta nu mai e „best practice”, e datorie tehnică.
