Articolul este disponibil doar în limba română.
Problema reală nu e volumul
Peste 27.000 de produse într-un catalog nu înseamnă mult pentru un calculator. Greu este că fiecare furnizor trimite datele altfel: un Excel cu coloane care își schimbă ordinea, un CSV cu alt separator, un XML, uneori un API. Iar codurile nu se potrivesc: furnizorul are codul lui, magazinul pe al lui, iar codul de bare lipsește exact la produsele care contează.
O sincronizare care merge în prima săptămână și strică prețurile în a doua e mai rea decât una făcută de mână. De aceea o construim în trepte, fiecare cu propria verificare.
Treapta 1: citirea, normalizată
- Fiecare furnizor are un adaptor care citește formatul lui și produce același rând standard: cod furnizor, cod de bare, denumire, stoc, preț de achiziție, monedă.
- Numerele se citesc explicit, cu separatorul zecimal și cel de mii ale fiecărui furnizor, nu cum ghicește programul.
- Un fișier care arată altfel decât ieri, cu coloane lipsă sau mult mai puține rânduri, oprește sincronizarea pentru acel furnizor și trimite o alertă.
Mai bine un stoc vechi de o zi decât un catalog golit din greșeală.
Treapta 2: potrivirea codurilor
Încercăm, în ordine: asocierea deja confirmată pentru codul furnizorului, apoi codul de bare, apoi codul normalizat, fără spații, cratime sau zerouri în față. Abia la sfârșit vine potrivirea aproximativă, pe denumire și atribute, care nu se aplică niciodată singură: intră într-o listă de confirmat, iar o asociere confirmată o dată se păstrează.
Aici își are locul un model de limbaj: poate ordona candidații și explica de ce seamănă două produse. Decizia rămâne la om, iar după confirmare regula devine deterministă.
Treapta 3: diferența, nu totul
Comparăm cu rularea anterioară și trimitem în magazin doar ce s-a schimbat. Mai puține apeluri înseamnă mai puține erori și un raport care se poate citi. API-ul WooCommerce acceptă actualizări în loturi; le folosim cu loturi mici și fiecare lot poate fi retrimis fără efecte secundare, pentru că trimitem valori absolute, „stoc 5”, nu operații, „scade 2”.
Rândul standard, după normalizare:
| Câmp | De unde vine | Observație |
|---|---|---|
| cod furnizor | fișierul furnizorului | cheia principală pentru furnizorul respectiv |
| cod de bare | fișierul furnizorului, dacă există | ajută la prima potrivire |
| denumire | fișierul furnizorului | folosită doar pentru potrivirea asistată |
| stoc | fișierul furnizorului | număr întreg, niciodată negativ |
| preț de achiziție și monedă | fișierul furnizorului | convertit la curs înainte de reguli |
Diferența, în schiță:
azi = rânduri_normalizate(furnizor)
ieri = ultima_rulare_reușită(furnizor)
pentru fiecare produs asociat:
dacă stocul s-a schimbat: actualizează(stoc = azi.stoc)
dacă prețul calculat s-a schimbat:
dacă diferența e peste pragul firmei: pune_la_aprobare(produs)
altfel: actualizează(preț = nou)
produse din ieri care lipsesc azi -> raport „dispărute”
produse noi, neasociate -> raport „de asociat”Treapta 4: regulile de preț
Prețul de vânzare vine din prețul de achiziție, cursul valutar și adaosul pe categorie, cu regula de rotunjire a magazinului. Regulile stau într-un singur loc, nu împrăștiate prin cod. Cursul se preia automat de la BNR, ca în ERP-ul de transport pe care îl dezvoltăm și îl întreținem.
O schimbare de preț peste pragul stabilit de firmă nu se aplică singură: intră în raport, la aprobare. Un furnizor care greșește o virgulă nu-ți vinde produsul la o zecime din preț.
Treapta 5: raportul
La final, un raport: produse actualizate, produse noi la furnizor, produse care au dispărut, coduri nepotrivite, prețuri oprite pentru aprobare. Raportul este produsul, nu un efect secundar: pe el se uită omul care răspunde de magazin.
Ce se strică de obicei
- Stocul apare disponibil, dar comenzile deja plasate l-au consumat: sincronizarea trebuie să țină cont de rezervări.
- Un produs retras de furnizor rămâne vizibil: stocul trece la zero, iar produsul se ascunde după regula stabilită de firmă.
- Două rulări se suprapun: o rulare nouă nu pornește până nu s-a terminat cea veche.
- Un furnizor schimbă formatul fără să anunțe: treapta 1 se oprește și cere atenție, în loc să strice datele.
Cum verificăm înainte de prima rulare reală
Rulăm întâi în modul de probă: sistemul produce raportul complet fără să modifice nimic în magazin. Comparăm raportul cu realitatea, corectăm asocierile și regulile, și abia apoi pornim rularea reală. Fiecare rulare lasă un jurnal, astfel încât orice modificare de stoc sau de preț să poată fi explicată ulterior.
Vrei asta în firma ta?
La auditul digital gratuit ne uităm cum lucrează firma ta acum și îți spunem ce se poate automatiza, cu sau fără AI, și cât costă.