Sincronizare stoc și comenzi între eMAG Marketplace și ERP: cum eviți supravânzarea și penalizările

Problema care costă cel mai mult: stocul care nu se potrivește nicăieri

Dacă vinzi pe eMAG Marketplace și ții evidența reală a stocului în ERP, ai două numere care ar trebui să fie mereu egale și aproape niciodată nu sunt. Între momentul în care un produs se vinde în magazinul fizic sau pe site și momentul în care eMAG "află" că nu mai ai bucata aceea, trece timp. În timpul ăsta, cineva o cumpără din nou.

Rezultatul se numește supravânzare (oversell), și pe eMAG nu e o problemă cosmetică. Fiecare comandă pe care o anulezi din lipsă de stoc îți strică indicatorii de performanță — rata de anulare din vina comerciantului este urmărită direct și afectează vizibilitatea ofertelor, eligibilitatea pentru campanii și, în cazuri repetate, poate duce la suspendarea contului.

Cifrele pe care le vedem la comercianți cu 500-5.000 de SKU-uri active pe Marketplace:

• 2-6% din comenzi anulate din cauza stocului desincronizat, în lunile fără integrare automată
• Stoc actualizat manual de 1-3 ori pe zi, prin export-import de fișiere — adică o fereastră de 4-8 ore în care numărul de pe eMAG e greșit
• 15-40 de minute/zi per operator pierdute pe descărcat comenzi, copiat în ERP și reintrodus AWB-uri
• Erori de preț care apar la fiecare campanie, pentru că prețul se schimbă în ERP dar nu și pe ofertă

Toate au aceeași cauză: două sisteme care nu vorbesc între ele în timp real.

De ce fișierele Excel și update-ul manual nu rezolvă nimic

Prima soluție a aproape oricărui comerciant este un fișier: export de stoc din ERP dimineața, import în eMAG, gata. Funcționează exact până în ziua în care ai un vârf de vânzări. Atunci:

• Stocul de dimineață e deja depășit la prânz, iar tu afli abia mâine
• Cineva uită să facă import-ul într-o zi aglomerată — exact ziua în care ai avea nevoie de el
• Fișierul are un SKU scris greșit și 40 de produse rămân cu stoc 0 fără ca nimeni să observe

Update-ul manual scalează invers cu succesul: cu cât vinzi mai mult, cu atât greșești mai des. O integrare prin API eMAG Marketplace rezolvă problema la sursă — stocul se propagă în secunde, nu în ore, iar comenzile intră singure în ERP.

Cum arată o integrare corectă, pe două direcții

O sincronizare serioasă nu e "un buton de sync". Sunt două fluxuri separate, care trebuie tratate diferit:

Direcția 1 — Stoc și prețuri: din ERP spre eMAG. ERP-ul e sursa adevărului pentru câte bucăți ai și la ce preț. Fiecare mișcare de stoc (vânzare, recepție, transfer, rezervare) declanșează o actualizare a ofertei pe eMAG prin API. Ideal, nu la interval fix, ci pe eveniment: s-a vândut o bucată, oferta se ajustează imediat.

Direcția 2 — Comenzi și livrare: din eMAG spre ERP. Fiecare comandă nouă e preluată automat din API, transformată în comandă/aviz în ERP, cu clientul, produsele și adresa completate. La expediere, AWB-ul și statusul se întorc pe eMAG fără ca operatorul să atingă nimic.

Partea pe care majoritatea integrărilor amatoare o ratează e fiabilitatea acestor două fluxuri:

• Idempotență. Dacă preiei aceeași comandă de două ori (și se va întâmpla, la un timeout de rețea), sistemul trebuie să recunoască că a văzut-o deja și să nu creeze un duplicat în ERP. Cheia de idempotență este ID-ul comenzii eMAG, nu ordinea de sosire.
• Retry cu backoff. API-ul eMAG are limite de rată. O integrare corectă nu abandonează la prima eroare 429, ci reîncearcă inteligent, cu pauze crescătoare, și pune în coadă ce nu a reușit.
• Rezervă de siguranță (buffer). La produsele cu rotație mare, e înțelept să publici pe eMAG stocul real minus 1-2 bucăți. Costul e o vânzare ratată ocazional; beneficiul e zero anulări la produsele fierbinți.
• Reconciliere periodică. O dată pe oră, un job compară stocul din ERP cu cel de pe ofertă și corectează diferențele scăpate. Fluxul pe eveniment e rapid; reconcilierea e plasa de siguranță.

Studiu de caz: comerciant cu 2.800 de SKU-uri pe Marketplace

Un comerciant de produse pentru casă și grădină cu care am lucrat la NEXVA SYSTEM vindea pe eMAG și în două magazine fizice, cu un ERP local ca sursă de stoc. Actualiza stocul prin fișier de două ori pe zi. Într-o lună de campanie, rata de anulare din lipsă de stoc a ajuns la 5,4%, iar doi oameni pierdeau împreună aproape 2 ore/zi pe procesat comenzi și introdus AWB-uri.

Ce am construit:

• Conector pe API-ul eMAG Marketplace, cu sincronizare de stoc pe eveniment din ERP (sub 20 de secunde de la mișcare până la ofertă actualizată)
• Preluare automată a comenzilor în ERP, cu deduplicare pe ID-ul comenzii și un job de reconciliere orar
• Trimiterea automată a AWB-urilor și a statusurilor înapoi pe eMAG, integrată cu contul de curier
• Buffer configurabil pe categorie și alerte pentru produsele care scad sub pragul de stoc
• Un dashboard cu anulările, timpii de procesare și diferențele stoc ERP–eMAG

Rezultate după 3 luni:

• Rata de anulare din lipsă de stoc: de la 5,4% la 0,7%
• Timp de procesare comenzi: de la ~2 ore/zi la sub 25 de minute/zi
• Ferestre de stoc greșit: de la 4-8 ore la sub 1 minut pe produsele cu rotație mare
• Zero comenzi pierdute sau introduse greșit în ERP pe durata a trei campanii
• Un efect neașteptat: cu ofertele mereu corecte, scorul comerciantului a crescut, iar o parte din produse au reintrat în campaniile la care nu mai erau eligibile

Cât costă și când se întoarce investiția

Pentru un comerciant cu 500-5.000 de SKU-uri active:

| Componentă | Cost |

|-----------|------|

| Analiză flux + maparea câmpurilor ERP ↔ eMAG | 1.500-3.000 EUR |

| Conector API: stoc + prețuri (ERP → eMAG) | 4.000-7.000 EUR |

| Conector API: comenzi + AWB (eMAG → ERP) | 4.000-7.000 EUR |

| Reconciliere, buffere, alerte, dashboard | 3.000-5.000 EUR |

| Costuri lunare (hosting + monitorizare + mentenanță) | 200-500 EUR/lună |

Calculul de ROI e direct. La un comerciant cu 3.000 de comenzi/lună și o valoare medie de 180 EUR, o scădere a ratei de anulare de la 5% la 1% înseamnă ~120 de comenzi salvate lunar — peste 21.000 EUR/lună în comenzi care nu se mai pierd. Adaugă 1,5-2 ore/zi de muncă manuală eliminate și investiția se recuperează, tipic, în 4-7 luni.

Greșelile care scufundă aceste proiecte

• Sync pe interval fix, nu pe eveniment. Un update la fiecare 30 de minute e mai bun decât Excel, dar tot lasă o fereastră de supravânzare în vârfurile de trafic.
• Fără idempotență. La prima problemă de rețea vei avea comenzi duplicate în ERP și livrări duble. Deduplicarea nu e opțională.
• Ignorarea limitelor de rată. Fără retry și cozi, o campanie mare îți umple integrarea de erori 429 și pierzi actualizări tocmai când contează cel mai mult.
• Un singur canal luat în calcul. Dacă vinzi și pe site sau pe alt marketplace, stocul trebuie gândit centralizat de la început, altfel construiești a doua oară aceeași integrare.

Cum începi

1. Măsoară situația actuală: rata de anulare din lipsă de stoc, câte update-uri manuale faci pe zi, minutele pierdute pe procesare

2. Mapează câmpurile dintre ERP și eMAG: SKU, stoc, preț, categorie, câmpurile comenzii și ale AWB-ului

3. Începe cu direcția stoc → eMAG pe eveniment — aici e cea mai mare pierdere și cel mai rapid câștig

4. Adaugă preluarea comenzilor și AWB-urile, apoi reconcilierea orară ca plasă de siguranță

5. Extinde spre multichannel doar după ce prima integrare rulează stabil două-trei campanii

Marketplace-ul iartă greu o rată de anulare mare, iar concurența pe eMAG se joacă la nivel de scor și vizibilitate. Diferența dintre comercianți nu mai e cine are stoc, ci cine reușește să-l arate corect, în timp real, fără să arunce oameni pe problemă.

Vrei să vezi câte comenzi pierzi lunar din stoc desincronizat și cât din fluxul eMAG–ERP se poate automatiza? Programează o consultanță gratuită.