Sincronizare ERP-TecDoc: stoc si preturi actualizate fara downtime

Stocul si preturile dintr-un magazin de piese auto se schimba de zeci de ori pe zi, iar catalogul TecDoc trebuie sa reflecte exact aceleasi cifre, altfel clientul vede "in stoc" pentru o piesa care de fapt lipseste. Solutia standard este un job de sincronizare care preia datele din ERP, le transforma in formatul asteptat de catalogul local si le scrie fara sa opreasca magazinul in timpul actualizarii. Cheia pentru zero downtime este sa nu scrii niciodata direct peste tabelele pe care le citeste magazinul in productie, ci sa construiesti o versiune noua a datelor si sa o comuti atomic dupa ce validarea trece.

Articolul explica arhitectura tehnica a acestei sincronizari: de la structura ERP-TecDoc-magazin, prin modelul de job in coada cu tabele shadow, pana la erorile frecvente care duc la stoc gresit afisat clientului. Este util pentru echipe de dezvoltare Laravel/PHP care intretin un magazin cu integrare TecDoc si un ERP extern (fie el pe Windows, cloud sau on-premise), precum si pentru manageri IT care vor sa inteleaga unde apar riscurile in acest flux.

Ce inseamna sincronizare stoc si preturi intre ERP si TecDoc

TecDoc furnizeaza structura catalogului auto: identificarea pieselor, compatibilitatea cu vehiculele, atributele tehnice si codurile OEM. TecDoc nu tine evidenta stocului sau a preturilor tale de vanzare - acestea vin din sistemul ERP al magazinului (Saga, WinMentor, SAP, un ERP custom sau altul). Sincronizarea inseamna procesul prin care aceste doua surse de date sunt unite intr-un singur catalog afisat clientului: identitatea piesei vine din TecDoc, disponibilitatea si pretul vin din ERP.

In practica, magazinul pastreaza local o legatura intre codul intern TecDoc al piesei (articleId sau referinta similara) si codul de produs din ERP (de obicei codul de gestiune sau SKU-ul intern). Aceasta legatura, numita adesea "mapping ERP-TecDoc", este piesa care face posibila sincronizarea automata a stocului si a preturilor.

De ce sincronizarea manuala sau prin export/import CSV nu tine pasul

Multe magazine incep cu un export CSV din ERP, incarcat manual sau printr-un cron simplu o data pe zi. Functioneaza la inceput, dar are limite clare:

Stocul afisat ramane invechit intre doua exporturi - un client poate comanda o piesa vanduta cu cateva ore in urma.
Un export CSV complet, la cataloage cu zeci de mii de referinte, poate dura suficient cat sa suprapuna doua rulari sau sa blocheze resurse pe server in orele de trafic.
Nu exista validare automata inainte de aplicare - un fisier corupt sau incomplet poate sterge stocul pentru mii de produse fara alerta.
Nu exista rollback rapid daca o rulare introduce date gresite.

Pentru un catalog cu trafic constant, sincronizarea trebuie sa fie incrementala (doar ce s-a schimbat, nu tot catalogul de fiecare data) si sa ruleze pe un flux care nu afecteaza citirea datelor de catre magazinul live.

Arhitectura recomandata: coada de joburi + tabele shadow

Modelul care evita downtime-ul se bazeaza pe trei componente care lucreaza separat de tabelele citite in productie:

Sursa de schimbari din ERP - fie un webhook/export declansat de ERP la fiecare modificare de stoc sau pret, fie un job programat care interogheaza ERP-ul la interval scurt (5-15 minute) si extrage doar randurile modificate dupa un timestamp.
Coada de procesare - fiecare lot de modificari intra intr-un job asincron (ex: Laravel Queue) care face mapping ERP-TecDoc, valideaza datele si scrie rezultatul intr-un tabel shadow (o copie a tabelului de stoc/pret, separata de cea servita live).
Comutare atomica - dupa ce toate randurile dintr-un lot au fost validate, aplicatia comuta printr-o singura tranzactie sau printr-un update in masa referinta catre tabelul shadow, care devine sursa curenta. Magazinul citeste mereu dintr-un singur tabel "activ", niciodata direct din tabelul in curs de scriere.

Acest tipar - scrie separat, valideaza, comuta atomic - este motivul pentru care sincronizarea nu produce downtime: clientii continua sa citeasca date consistente in tot acest timp, iar comutarea dureaza milisecunde, nu minute.

Sincronizare incrementala vs full sync

Pentru stoc si pret, sincronizarea incrementala (doar delta-ul fata de ultima rulare) este aproape mereu solutia potrivita, spre deosebire de catalogul de produse TecDoc in sine, unde o resincronizare completa periodica ramane utila pentru a prinde piese noi sau discontinuate. O rulare full sync pentru stoc, la fiecare cateva minute, pe un catalog mare, consuma resurse fara motiv - delta-ul tipic reprezinta un procent mic din catalogul total.

Cum eviti downtime-ul in timpul actualizarii

Downtime-ul apare de obicei din trei cauze evitabile: blocare la scriere pe tabelul citit live, procesare sincrona care tine conexiuni deschise prea mult timp si lipsa validarii inainte de aplicare. Practicile de mai jos elimina fiecare cauza:

Nu scrii niciodata direct in tabelul servit clientilor - foloseste tabelul shadow si comutare atomica, asa cum e descris mai sus.
Proceseaza in loturi mici (batch-uri de cateva sute-mii de randuri), nu un singur update masiv care blocheaza tabelul pentru zeci de secunde.
Ruleaza joburile asincron, in afara request-ului HTTP - clientul care navigheaza pe site nu asteapta niciodata dupa un job de sincronizare.
Foloseste idempotenta - daca un job esueaza si se reia, aplicarea repetata a acelorasi date nu trebuie sa produca stoc dublat sau pret gresit.
Programeaza rularile intensive (ex: recalcul de indici de cautare) in afara orelor de varf, chiar daca sincronizarea de stoc/pret in sine ruleaza continuu.

Cand alegi webhook din ERP vs polling programat

Alegerea intre cele doua metode de captare a schimbarilor depinde de ce permite ERP-ul si de cat de rapid trebuie sa fie stocul afisat:

Criteriu	Webhook din ERP	Polling programat
Latenta pana la actualizare	Aproape imediata (secunde)	Egala cu intervalul de polling (minute)
Suport necesar din partea ERP-ului	ERP-ul trebuie sa poata trimite evenimente HTTP	Orice ERP cu export de date sau acces la baza de date
Complexitate de implementare	Mai mare - endpoint dedicat, validare, retry	Mai mica - job programat clasic
Risc de evenimente pierdute	Prezent daca endpoint-ul e indisponibil temporar	Redus - urmatoarea rulare recupereaza automat delta-ul
Recomandat pentru	Stoc cu miscare rapida, ERP-uri moderne cu API	Majoritatea ERP-urilor clasice, preturi actualizate rar

In practica, multe integrari combina ambele: webhook pentru evenimente critice (stoc epuizat), plus un polling de siguranta la fiecare 10-15 minute care recupereaza orice eveniment ratat.

Riscuri frecvente si cum le previi

Mapping ERP-TecDoc incomplet - un cod de produs din ERP fara corespondent TecDoc ramane orfan si nu se actualizeaza niciodata. Previne prin raport periodic de coduri nemapate, verificat manual sau semi-automat.
Stoc negativ sau pret zero acceptat ca valid - fara validare, o eroare de export din ERP poate scrie stoc negativ sau pret 0 direct in catalog. Adauga reguli de validare inainte de comutarea in tabelul activ (ex: respinge randuri cu pret sub un prag minim configurabil).
Job blocat care tine coada intreaga in asteptare - un singur job care esueaza repetat poate opri procesarea restului cozii. Foloseste retry cu limita si un job separat pentru fiecare lot, nu un singur job monolitic pentru tot catalogul.
Discrepanta de fus orar sau format numeric intre ERP si aplicatie - preturi cu separator zecimal diferit sau timestamp-uri interpretate gresit produc valori incorecte tacut, fara eroare vizibila. Normalizeaza formatul la intrarea in pipeline, inainte de orice calcul.
Cache neinvalidat dupa sincronizare - daca magazinul cacheuieste pagini de produs, stocul poate ramane afisat gresit chiar daca baza de date e deja actualizata. Invalideaza explicit cache-ul pentru produsele modificate in lotul curent.

Plan practic: pasii de implementare a sincronizarii

Construieste si documenteaza tabelul de mapping ERP-TecDoc (cod ERP -> identificator TecDoc), cu un raport de coduri nemapate rulat saptamanal.
Creeaza tabelele shadow pentru stoc si pret, separate de tabelele citite in productie.
Implementeaza captarea schimbarilor din ERP (webhook, polling sau ambele), cu extragere incrementala bazata pe timestamp sau flag de modificare.
Configureaza joburi in coada care proceseaza loturi mici, cu retry limitat si logare a erorilor per rand, nu doar per job.
Adauga validari inainte de comutare: stoc negativ, pret sub prag, format numeric invalid.
Implementeaza comutarea atomica intre tabelul shadow si tabelul activ, plus invalidarea cache-ului pentru produsele modificate.
Monitorizeaza timpul de la modificare in ERP pana la reflectare in magazin si seteaza o alerta daca depaseste un prag acceptabil.

Ce monitorizezi dupa punerea in productie

Sincronizarea automata nu se termina la implementare - are nevoie de monitorizare continua pentru a ramane de incredere. Urmareste minim: numarul de randuri procesate cu succes vs esuate per rulare, timpul mediu de la modificare in ERP pana la aparitia in catalog, numarul de coduri ERP nemapate si eventualele blocaje de coada (joburi care raman mult timp in asteptare). O crestere brusca a randurilor esuate este de obicei semnul unei schimbari neanuntate in formatul de export al ERP-ului.

FAQ: intrebari frecvente despre sincronizarea ERP-TecDoc

Cat de des trebuie sincronizat stocul intre ERP si TecDoc?

Pentru piese cu miscare rapida, intervalul recomandat este de cateva minute (5-15 minute) pentru stoc, prin polling, sau aproape in timp real prin webhook. Preturile se pot sincroniza la interval mai relaxat (ex: orar), decat daca magazinul face modificari de pret dese, in campanii sau pe baza cursului valutar.

Se poate face sincronizarea fara sa opresti magazinul deloc?

Da, cu conditia sa nu scrii direct in tabelele citite de magazinul live. Modelul cu tabel shadow si comutare atomica, descris mai sus, este exact metoda prin care sincronizarea ruleaza continuu fara nicio fereastra de mentenanta vizibila clientilor.

Ce se intampla daca sincronizarea esueaza la jumatate?

Daca fiecare lot se scrie intai in tabelul shadow si comutarea se face doar dupa validarea completa a lotului, o esuare la jumatate inseamna ca tabelul activ ramane neschimbat - clientii continua sa vada ultimele date valide, nu date partial actualizate. Jobul esuat se reia automat prin retry, fara interventie manuala in majoritatea cazurilor.

Trebuie sa sincronizezi tot catalogul TecDoc sau doar produsele din stoc?

Structura de catalog (identificarea pieselor, compatibilitatea) se ia din TecDoc pentru intreg catalogul relevant magazinului. Stocul si pretul, pe de alta parte, se sincronizeaza doar pentru produsele efectiv gestionate in ERP - nu are sens sa actualizezi stoc pentru piese pe care magazinul nu le comercializeaza.

Ce facem cu produsele TecDoc care nu exista in ERP?

Raman afisate ca indisponibile sau sunt excluse din catalogul public, in functie de politica magazinului. Cel mai sigur este sa nu afisezi pret sau optiune de comanda pentru un produs fara corespondent confirmat in ERP, pentru a evita comenzi pe piese pe care magazinul nu le poate onora.

Concluzie

O sincronizare ERP-TecDoc fara downtime nu tine de un singur trick tehnic, ci de o arhitectura care separa scrierea de citire: joburi in coada, tabele shadow, validare inainte de comutare si monitorizare continua a erorilor. Aplicat corect, clientul vede mereu stoc si pret corecte, fara ferestre de mentenanta si fara riscul de a vinde o piesa care nu mai exista in gestiune.

Vrei sa integrezi TecDoc in magazinul tau de piese auto? Contacteaza-ne pentru o consultatie despre arhitectura de sincronizare potrivita pentru ERP-ul tau.

Imagine generata cu AI, folosita in scop ilustrativ.