Stoc, preț și indicatori de vânzător pe eMAG: ce urmărești

Ai zece bucăți în depozit, magazinul propriu afișează zece, iar eMAG afișează tot zece. Nu ai, de fapt, douăzeci de bucăți. Ai zece promisiuni posibile publicate simultan în două locuri. Dacă ultima unitate se vinde în ambele canale înainte ca sistemele să se actualizeze, una dintre comenzi nu mai poate fi onorată.

Răspunsul scurt la întrebarea „cum sincronizez corect?” este acesta: alegi o singură sursă de adevăr, separi stocul fizic de cel deja rezervat și de cel publicabil, calculezi un buffer pe SKU, apoi stabilești câtă întârziere poate tolera fiecare produs. Indicatorii eMAG îți arată unde se vede efectul. Jurnalul comenzilor, stocului și integrării îți arată cauza.

Acest ghid pornește din documentația publică eMAG și din principii verificabile de gestiune a inventarului. Nu presupune acces la contul tău și nu publică praguri private pentru sănătatea contului. Când un tutorial cere autentificare, folosim numai rezumatul public. Pentru contextul mai larg — magazin, marjă, achiziție și retenție — pagina Amplify despre creșterea unui business eCommerce arată de ce un canal nu poate fi operat separat de restul afacerii.

Contul se rupe înainte ca vânzarea să dispară

Un seller observă de obicei problema târziu. Vede o comandă pe care nu o poate trimite, un client nemulțumit sau un indicator care s-a degradat. Defectul a început însă mai devreme: o recepție neînregistrată, o unitate deteriorată rămasă vandabilă, o comandă din magazinul propriu nerezervată ori un import care a eșuat fără alertă.

Citirea de control are patru reguli:

• eMAG definește Sănătatea Contului ca un raport calitativ al valorilor obținute pentru indicatorii de performanță și spune că statusul este afișat în Dashboard; Manualul public precizează că indicatorii sunt monitorizați zilnic, iar rezultatul se vede la finalul perioadei de referință, deci dashboardul este un sistem de semnalizare, nu înregistrarea completă a operațiunilor;

Un tablou de control util leagă fiecare semnal de procesul care îl poate produce:

• Zona Ofertele Mele separă General, Prețuri, Stocuri, Calitate conținut și Review-uri, iar Dashboardul are statistici pentru produse fără stoc și produse cu vânzare; aceste suprafețe răspund la „unde să mă uit?”, nu singure la „de ce s-a întâmplat?”;

• nu începi ziua cu media vânzărilor, ci cu excepțiile care pot rupe promisiunea făcută clientului: stoc negativ sau suspect, comenzi aproape de termen, actualizări respinse, oferte cu preț în afara regulii și colete fără dovadă de predare; venitul este rezultatul, excepțiile sunt munca de astăzi;

• serviciul Amplify de măsurare și tracking pornește din aceeași disciplină: un număr devine util când are definiție, proprietar și decizie asociată; „Sănătatea contului este slabă” este o stare, iar „Trei comenzi nu au primit rezervare după importul de la 09:00” este o cauză asupra căreia poți interveni.

Stoc disponibil, rezervat și publicat: trei adevăruri care trebuie reconciliate

Stocul fizic spune câte unități există într-o locație. Nu spune câte pot fi promise acum. O parte poate fi deja alocată unor comenzi, blocată pentru control de calitate, deteriorată, mutată între depozite sau păstrată drept protecție până la următoarea sincronizare.

Documentația Shopify despre stările inventarului separă on hand, committed, unavailable, available și incoming. Nu este o regulă eMAG, ci un vocabular bun pentru problemă. Pentru un seller român, formula minimă poate fi:

stoc publicabil = stoc fizic − rezervări deschise − unități indisponibile − stoc de siguranță

Să presupunem că depozitul numără 12 unități. Două aparțin deja unor comenzi neexpediate, una este blocată după controlul calității, iar bufferul SKU-ului este două. Stocul publicabil este 12 − 2 − 1 − 2 = 7. Dacă publici 12 în fiecare canal, nu sincronizezi; supra-promiți.

Momentul rezervării este la fel de important ca formula. Dacă magazinul propriu scade stocul abia la facturare, iar eMAG primește comanda cu câteva minute înainte, ambele canale pot considera ultima unitate liberă. Documentația Microsoft despre Inventory Visibility descrie exact riscul de double booking când mai multe sisteme preiau comenzi și arată rolul unei surse comune și al rezervării. Nu trebuie să folosești acel produs; trebuie să rezolvi aceeași problemă.

Pentru fiecare canal, trasează șase evenimente:

1. comanda este creată;
2. unitatea este rezervată în sursa principală;
3. cantitatea publicabilă este recalculată;
4. noua cantitate este trimisă canalelor;
5. canalul confirmă sau respinge actualizarea;
6. rezervarea este consumată la expediere ori eliberată la anulare.

O integrare care execută doar pasul patru poate arăta sofisticat și totuși poate vinde stocul de două ori. Lipsesc rezervarea și confirmarea. La fel, un fișier XLS încărcat corect dimineața poate deveni greșit până la prânz dacă alte canale vând repede.

Reconcilierea nu este același lucru cu sincronizarea. Sincronizarea încearcă să ducă valoarea A în sistemul B. Reconcilierea compară după aceea ce crede fiecare sistem și deschide excepții pentru diferențe. Fără al doilea pas, un job poate raporta „executat” după ce a trimis un fișier, chiar dacă două rânduri au fost respinse și alte trei au ajuns cu întârziere.

Construiește un raport de reconciliere cu o linie pe SKU și cu cel puțin aceste câmpuri: cantitatea vandabilă în sursă, cantitatea trimisă, ora trimiterii, răspunsul canalului, cantitatea observată în eMAG și diferența. Nu este nevoie să verifici manual fiecare produs în fiecare ciclu. Filtrezi diferențele, valorile negative, răspunsurile lipsă și actualizările mai vechi decât bugetul de latență.

Există trei direcții diferite de eroare:

• sursa este corectă, eMAG este vechi — investighezi trimiterea, coada și răspunsul;

• eMAG reflectă ultima trimitere, dar sursa este greșită — oprești propagarea și corectezi inventarul sau rezervările;

• ambele coincid, dar raftul diferă — ai o problemă de inventar fizic, recepție, picking sau pierdere.

• această separare împiedică reflexul de a „mai da o dată sync”: retrimiterea unei valori greșite o face doar mai recentă.

Un tutorial video de listare eMAG arată câmpurile de preț și stoc și menționează alerta de aprovizionare. Îl folosim doar ca demonstrație de interfață veche, nu ca dovadă a algoritmului actual. Controlul final este documentația eMAG: secțiunea Stocuri permite actualizare rapidă, afișează activitatea ultimelor 30 de zile și oferă sugestii de gestiune și aprovizionare.

O comandă anulată propagă costul dincolo de produs

Tutorialul eMAG despre anulare tratează explicit situația în care sellerul nu are stoc sau întâmpină altă problemă și nu poate trimite produsul. Existența unui buton de anulare nu transformă anularea într-o corecție fără cost.

Costul minim al unui stoc fantomă are mai multe componente:

• contribuția pe care comanda ar fi lăsat-o dacă produsul exista;
• timpul consumat de operator pentru verificare, mesagerie, anulare și corectarea stocului;
• costul oportunității: aceeași echipă nu procesează alte comenzi în acel interval;
• efectul posibil asupra indicatorilor și experienței clientului;
• riscul ca defectul să se repete pe alte SKU-uri sau canale.

Nu toate componentele pot fi transformate onest în lei la prima apariție. Asta nu justifică valoarea zero. Ține separat costul direct, timpul și expunerea operațională.

Exemplu ipotetic: o comandă ar fi lăsat 32 lei contribuție înainte de costurile echipei. Verificarea și comunicarea consumă 18 minute, evaluate intern la 45 lei/oră. Costul imediat observabil este 32 + 18/60 × 45 = 45,50 lei. Nu include un presupus „cost de cont” și nu pretinde că fiecare client pierdut valora o anumită sumă. Arată doar de ce anularea nu este gratuită.

Mai important decât totalul unei comenzi este multiplicarea. Dacă aceeași discrepanță apare la cinci SKU-uri alimentate de același feed, nu ai cinci accidente independente. Ai un defect de proces. Fișa de incident trebuie să lege cazurile prin versiunea importului, conector, depozit, regulă sau interval orar.

Pagina eMAG despre procesarea comenzilor arată că lista include data și ora înregistrării și data maximă de finalizare. Acestea sunt repere de execuție. Nu aștepta ca un indicator agregat să-ți spună că o comandă individuală este aproape de termen.

Într-un magazin propriu, disponibilitatea greșită lovește și conversia: clientul vede o promisiune pe care businessul nu o poate ține. Ghidul despre de ce nu convertește un site explică rolul încrederii și al fricțiunii; stocul fantomă transformă problema de conversie într-una de reputație și suport.

Manual, fișier sau API: alegi nivelul de sincronizare

Nu orice seller are nevoie de integrare API în prima zi. Dar orice seller are nevoie de un proces pe care volumul său îl poate susține. Alegerea nu se face după prestigiul tehnologiei, ci după numărul de SKU-uri active, viteza schimbărilor, numărul canalelor, toleranța la întârziere și capacitatea de a urmări erorile.

După comparația metodelor, păstrează trei limite de interpretare:

• eMAG confirmă public că importul XLS are fișiere dedicate pentru oferte, prețuri și stocuri, iar Integrarea API este destinată încărcării produselor și ofertelor și procesării comenzilor; la data documentării, pagina indică versiunea 4.5.1 ca valabilă din 2 martie 2026, o notă de actualitate, nu motivul alegerii API;

• un video despre listare printr-un sistem extern arată maparea inventarului și a parametrilor spre eMAG; este util pentru a vedea că integrarea presupune corespondențe, nu doar un buton „sync”, dar transcriptul este automat și exemplul e fictiv, deci nu preluăm valori sau promisiuni;

• în alt ecosistem, un tutorial despre feedul Google Merchant Center recomandă schimbarea prețului și disponibilității la sursa de date, nu direct în destinație, pentru a evita discrepanțele; principiul este bun, dar nu îl prezentăm ca regulă eMAG, iar intervenția de urgență rămâne excepția în care oprești oferta în canal, repari sursa și explici abaterea.

Pentru API, cere integratorului răspunsuri concrete:

• care sistem deține stocul vandabil;
• la ce eveniment se rezervă unitatea;
• ce latență există în condiții normale și în vârf;
• ce se întâmplă când eMAG respinge o actualizare;
• de câte ori se reîncearcă și când intervine un om;
• unde vezi valoarea trimisă, răspunsul primit și ID-ul corelat;
• cum reconciliezi zilnic cantitățile dintre sursă și canal.

„Sincronizare automată” fără aceste răspunsuri este o promisiune comercială, nu un control.

Înainte de lansare, testează integrarea cu scenarii, nu numai cu un catalog importat cu succes. Alege SKU-uri de test și execută controlat:

1. scădere de stoc după o comandă din magazin;
2. scădere după o comandă eMAG;
3. anularea unei comenzi și eliberarea rezervării;
4. stoc ajuns la zero în timp ce rulează o altă actualizare;
5. preț sub podeaua permisă;
6. token expirat sau răspuns de eroare al destinației;
7. două actualizări consecutive, primite în ordine inversă;
8. SKU nemapat sau identificator schimbat.

Pentru evaluarea fiecărui scenariu:

• notezi starea inițială, evenimentul, valoarea așteptată, valoarea observată, timpul până la confirmare și alerta produsă;
• accepți rezultatul când sistemul a păstrat invarianta și a semnalat excepția, nu doar când „ai văzut produsul în eMAG”;
• verifici că suma promisă nu depășește cantitatea vandabilă după rezervări și buffer și că nicio transformare de preț nu coboară sub podeaua aprobată.

După lansare, păstrează un mecanism de oprire. Dacă diferențele depășesc capacitatea echipei de a le verifica, dezactivezi temporar actualizarea automată pentru familia afectată sau publici un buffer mai conservator. Continuitatea unui job nu este mai importantă decât corectitudinea promisiunii.

Stocul de siguranță se calculează din viteză și latență

Bufferul nu este „10% din tot stocul”. Același procent poate bloca inutil un produs lent și poate fi insuficient pentru unul care vinde rapid într-o campanie. Stocul de siguranță trebuie calculat pe SKU sau pe grupuri cu comportament apropiat.

Pentru problema sincronizării între canale, o regulă operațională simplă este:

buffer de publicare = vânzarea maximă observată în fereastra de risc + unități blocate probabile

Fereastra de risc include intervalul dintre două actualizări, timpul de procesare al cozii și timpul până când destinația confirmă schimbarea. Dacă actualizarea rulează la 20 de minute, coada poate adăuga 10 minute, iar în 30 de minute SKU-ul a vândut cel mult două unități în perioade comparabile, pornești de la două. Dacă inventarul arată recurent o unitate blocată sau deteriorată, bufferul de lucru devine trei. Nu publici formula drept regulă eMAG și o recalculezi după schimbarea vitezei.

Pentru reaprovizionare, problema este mai largă. Documentația Oracle NetSuite despre inventory optimization leagă stocul de siguranță de variația cererii, variația lead time-ului și nivelul de serviciu. Tot ea avertizează că rezultatele sunt aproximative pentru cerere intermitentă, promoțională, sezonieră sau asimetrică. Tocmai acestea sunt situațiile în care o medie simplă poate minți.

eMAG publică două semnale utile în Dashboard: stoc epuizat în ultimele 7 zile și epuizare estimată în următoarele 7 zile. Cele șapte zile fac parte din denumirea instrumentelor. Nu înseamnă că furnizorul tău livrează în șapte zile sau că fiecare SKU trebuie să aibă acoperire identică.

Folosește cele două KPI-uri împreună:

• retrospectivul arată unde ai pierdut deja disponibilitate la produse cu vânzare;
• prospectivul arată unde trebuie să intervii înainte de ruptură;
• registrul intern explică dacă soluția este reaprovizionare, transfer, buffer mai mare, actualizare mai rapidă sau oprirea temporară a ofertei.

Un buffer bun reduce riscul, dar scade stocul expus la vânzare. De aceea trebuie măsurat și revizuit. Dacă nu ai avut nicio discrepanță timp de opt săptămâni, latența a scăzut și inventarul este precis, poți testa reducerea. Dacă apar vârfuri, recepții greșite sau actualizări respinse, îl mărești temporar. Cele opt săptămâni sunt un exemplu de cadru intern, nu o perioadă eMAG.

Nu administra toate produsele cu aceeași intensitate. Grupează-le după riscul de supravânzare, nu doar după cifra de afaceri:

• SKU rapid, cu puține unități și reaprovizionare lentă: buffer mai atent și reconciliere frecventă;
• SKU stabil, cu stoc adânc și lead time predictibil: control automat pe excepții;
• SKU lent sau sezonier: buffer calculat separat, fiindcă istoricul mediu poate fi irelevant;
• produs unicat, resigilat sau cu serie: rezervare imediată și, adesea, expunere într-un singur canal.

Revizuirea bufferului trebuie să păstreze motivul schimbării. Dacă îl crești de la două la patru unități după un incident, notează incidentul, fereastra observată și data la care îl reevaluezi. Altfel, protecțiile temporare se transformă în stoc blocat permanent și nimeni nu mai știe de ce.

Același produs, două prețuri și o singură limită economică

Sincronizarea prețului nu înseamnă că toate canalele trebuie să afișeze aceeași sumă. Marketplace-ul și magazinul propriu au structuri diferite de cost, servicii diferite și uneori campanii diferite. Înseamnă că fiecare preț publicat provine dintr-o regulă cunoscută și nu coboară sub limita economică aprobată.

Secțiunea Prețuri din Ofertele Mele permite modificarea rapidă a prețului ofertelor și afișează informații despre performanță. Importul XLS poate actualiza separat prețurile. Aceste funcții schimbă valoarea publicată; nu calculează toate costurile interne ale sellerului.

Podeaua pe canal poate fi exprimată astfel:

preț minim fără TVA = marfă + comision + logistică + cost variabil al returului + alte costuri variabile + contribuția minimă cerută

Un tutorial despre contribution margin în ecommerce separă costul produsului de fulfillment și urmărește ce rămâne după livrare. Folosim această disciplină, nu cifrele exemplului și nu afirmația că recurența ar fi „profit pur”. Pentru MKT-07, întrebarea este mai îngustă: ce valoare nu are voie automatizarea să depășească în jos?

Presupune un preț fără TVA de 100 lei, marfă de 54 lei, comision de 15 lei, logistică și ambalare de 11 lei, provizion variabil de retur de 4 lei și contribuție minimă cerută de 8 lei. Spațiul rămas este 100 − 54 − 15 − 11 − 4 − 8 = 8 lei. O regulă automată care scade prețul cu 10 lei trece sub limita internă, chiar dacă încă produce vânzări. Toate valorile sunt ipotetice.

Controlează prețul prin patru câmpuri, nu printr-un singur număr:

1. prețul de bază din sursă;
2. ajustarea permisă pe canal;
3. podeaua economică;
4. valoarea finală confirmată în eMAG.

Dacă prețul publicat diferă, incidentul trebuie să arate unde s-a produs abaterea. Operatorul a schimbat canalul direct? Regula a fost aplicată de două ori? TVA-ul ori moneda au fost mapate greșit? Un feed vechi a suprascris corecția? Fără acest traseu, sincronizarea poate reintroduce aceeași eroare la următorul ciclu.

Rutina de control: alerte azi, tendințe la final de săptămână

Controlul zilnic și analiza săptămânală au roluri diferite. Zilnic protejezi comenzile și promisiunile în curs. Săptămânal repari procesele care produc aceleași excepții.

La începutul zilei

Verifică ofertele cu stoc zero sau suspect, comenzile care se apropie de data maximă de finalizare, actualizările respinse, prețurile în afara regulii și coletele fără dovadă de predare. Fiecare excepție primește proprietar și termen. „E la IT” nu este stare; „conectorul a respins SKU-123, Ana verifică maparea până la 11:00” este.

În timpul zilei

Urmărește coada de comenzi și confirmările canalului, nu doar faptul că jobul de sincronizare a pornit. Un proces poate rula și poate trimite date greșite. Pentru SKU-urile rapide, alertele trebuie să țină cont de fereastra de risc calculată. Pentru cele lente, o verificare mai rară poate fi suficientă.

La finalul săptămânii

Grupează incidentele după cauză, nu după operatorul care le-a descoperit. Măsoară:

• câte discrepanțe de stoc au apărut și pe ce SKU-uri;
• cât a durat până la detectare și până la corecție;
• câte actualizări au fost respinse sau reluate;
• câte comenzi au fost afectate înainte de remediere;
• ce regulă, mapare sau pas manual a fost schimbat;
• dacă problema a reapărut după închidere.

Pentru livrare, recomandările eMAG folosesc istoricul timpului pe rută și depozitul sellerului drept origine. Asta întărește ideea că execuția nu se termină la AWB. Urmărești pregătirea, predarea și scanarea, cu dovadă.

Rutina trebuie să fie suficient de scurtă ca să fie executată și suficient de precisă ca să prindă riscul. Un raport cu 40 de coloane pe care nimeni nu îl deschide este mai slab decât cinci excepții cu proprietar. Automatizezi colectarea; decizia rămâne explicită.

Separă și severitatea. O diferență de o unitate la un SKU fără comenzi deschise poate intra în investigația zilei. O diferență pe ultima unitate a unui produs rapid, cu o comandă nouă, cere oprirea imediată a ofertei și verificare fizică. O eroare de autentificare care afectează tot catalogul este incident de sistem, chiar dacă încă nu a produs anulări.

Poți folosi o regulă simplă de triere:

Severitatea nu trebuie calculată din valoarea produsului singur. O piesă ieftină poate genera zeci de comenzi și mult suport; un produs scump poate avea o singură rezervare bine controlată. Contează expunerea: câte promisiuni pot deveni imposibile înainte de următoarea intervenție.

Întrebări frecvente

La cât timp trebuie sincronizat stocul cu eMAG?

Nu există o frecvență universală publicată pentru orice seller. Pleci de la viteza maximă de vânzare a SKU-ului, numărul canalelor și întârzierea completă până la confirmare. Dacă în fereastra dintre două actualizări se pot vinde mai multe unități decât bufferul, actualizezi mai des, mărești bufferul sau oprești expunerea simultană.

Este suficient să pun stoc zero când apare o problemă?

Stocul zero poate opri noi promisiuni după ce actualizarea este acceptată, dar nu rezolvă comenzile deja primite și nu repară sursa. Verifică rezervările, comenzile deschise, cauza diferenței și confirmarea că oferta a fost actualizată. Apoi corectează sistemul care ar putea suprascrie intervenția.

Anularea unei comenzi din lipsă de stoc afectează indicatorii?

eMAG include rata de finalizare și indicatori legați de comenzi în zona Sănătatea Contului, iar lipsa stocului apare în tutorialul de anulare. Pragul aplicabil contului tău trebuie verificat în platformă sau cu suportul eMAG. Articolul nu publică valori din clipuri vechi ori din ecrane inaccesibile.

Pot avea preț diferit în magazinul propriu și pe eMAG?

Operațional, tratează fiecare canal prin costul și regulile sale. Nu forța aceeași sumă dacă structura economică diferă, dar păstrează o podea aprobată, o regulă de transformare și un jurnal al valorii publicate. Pentru obligații contractuale sau juridice specifice, verifică termenii curenți și cere consultanță adecvată.

Când merită integrarea API?

Când volumul, viteza și numărul canalelor depășesc controlul manual sau XLS fără a crea latență periculoasă. API-ul merită numai dacă are monitorizare, retry controlat, loguri, alertare și reconciliere. Automatizarea fără aceste componente poate propaga greșeala mai repede.

Fișa de incident: din simptom în cauză, proprietar și termen

Un incident nu este închis când ai schimbat cifra în eMAG. Este închis când ai protejat comenzile curente, ai reparat sursa și ai dovada că următorul ciclu nu reintroduce eroarea.

Fișa minimă conține:

Fluxul este semnal → protecție → diagnostic → corecție → confirmare → prevenție. Nu sări direct de la semnal la o explicație probabilă. Verifică ora ultimei valori corecte, evenimentele dintre sisteme, răspunsul eMAG și inventarul fizic.

La sfârșitul lunii, nu premia absența alertelor. Poate însemna că sistemul nu vede nimic. Urmărește diferențele găsite, viteza de remediere și recurența după corecție. Un seller matur nu este cel care nu are incidente, ci cel care limitează expunerea, păstrează urmele și nu lasă aceeași cauză să producă a treia anulare.

Revizuirea săptămânală păstrează și numărul incidentelor redeschise. O cauză revine atunci când dovada corecției nu rezistă următorului ciclu complet.

Indicatorii eMAG rămân importanți: arată cum ajunge execuția la client și la platformă. Dar ordinea corectă este inversul reflexului obișnuit. Nu optimizezi un indicator abstract și speri că depozitul se aliniază. Controlezi stocul vandabil, prețul, rezervarea și predarea; apoi verifici dacă indicatorii confirmă că procesul funcționează.