WooCommerce · catalog · inventarATELIERUL DATELOR
Catalog Data & Inventory: automatizare catalog și stoc WooCommerce printr-un registru canonic.
Implementarea organizează produsele, variațiile, atributele, taxonomiile, media și inventarul înainte ca datele aprobate să alimenteze magazinul ori canalele externe. Autoritatea se stabilește separat pentru fiecare câmp și flux, iar diferențele rămân vizibile până la o decizie controlată.
- Autoritate explicită pentru fiecare câmp și flux
- Identități separate pentru produs, variație și canal
- Simulare și diferență înaintea scrierii
- Reconciliere periodică în direcția autorizată
Catalog Data & Inventory descrie o implementare personalizată, nu un PIM universal și nu un modul funcțional inclus automat în KEPA Plugins. Schema, sursele și operațiile reale se confirmă pentru fiecare proiect.
O înregistrare coerentă, ieșiri delimitateautoritate, identitate, validare și reconciliere
MODEL CONCEPTUAL01 / MODEL CANONIC ȘI AUTORITATE
Fiecare câmp are o singură sursă autoritară în fluxul său.
WooCommerce poate rămâne sursa comercială a catalogului, iar ERP-ul, PIM-ul, fișierele sau API-urile pot furniza numai câmpurile aprobate. Nu prezentăm două sisteme concurente drept surse autoritare simultan.02 / REGISTRUL IDENTITĂȚIIENTITATE · CANAL · CORESPONDENȚĂ
Identitatea locală și identitățile externe nu sunt comprimate într-o singură valoare.
Registrul păstrează separat corespondența pentru fiecare canal și tip de entitate: produs părinte, variație vandabilă, ofertă sau alt obiect aprobat. Un identificator extern nu înlocuiește ID-ul local, iar relația poate avea propria stare și dovadă.
Unicitate verificată
Rezolvarea caută duplicate, spații, diferențe de formatare și coliziuni înainte ca SKU-ul să fie folosit drept cheie.
Prezență și coliziuni
Codul este validat când există sau când destinația îl cere; absența și reutilizarea nepermisă rămân erori explicite.
Legătură separată
Fiecare integrare păstrează propriul identificator, fără a-l reutiliza implicit în alt marketplace sau sistem.
Intervenție necesară
Mai multe potriviri nu sunt rezolvate prin presupunere; elementul este blocat până la o decizie documentată.
03 / TAXONOMIE ȘI DICȚIONAREDESTINAȚIE FINALĂ · PRIORITATE · VALOARE
Categoria și atributele urmează reguli explicite, nu potriviri ghicite.
Rutarea urmărește categoria finală acceptată de canal. Excepția aprobată pe produs are prioritate, urmată de regula categoriei; o variantă de rezervă este folosită numai dacă rezultatul rămâne neambiguu.
- 01Excepție pe produsPRIORITATE MAXIMĂ
O decizie locală documentată poate indica direct destinația finală.
- 02Regulă de categorieORDINE CONTROLATĂ
Categoria WooCommerce relevantă conduce către maparea aprobată pentru acel canal.
- 03Variantă de rezervăFĂRĂ AMBIGUITATE
Se aplică numai când o singură destinație validă poate fi determinată.
Atribut WooCommerce
Maparea indică atributul, metadatele ori regula aprobată din care provine valoarea.
Valoare permisă
Valoarea normalizată este verificată față de nomenclatorul curent al categoriei și canalului.
04 / FAMILII, VARIAȚII ȘI MEDIA
Familia păstrează relația dintre părinte, dimensiuni și fiecare unitate vandabilă.
Schema verifică dimensiunile de variație, identitatea fiecărei unități și regulile media înainte ca familia să devină eligibilă pentru o ieșire externă.
Context comun
Familia păstrează legătura cu produsul părinte și câmpurile aprobate pentru moștenire.
Roluri distincte
Culoarea, mărimea sau alte dimensiuni au ordine, sursă și valori permise definite.
SKU și EAN proprii
Fiecare variație vandabilă își păstrează identificatorii și verificările de unicitate.
Galerie pe culoare
Regulile pot grupa imaginile după culoare fără a presupune că numele fișierului dovedește asocierea.
05 / INVENTAR ȘI RECONCILIERESURSĂ · ALOCARE · DIFERENȚĂ
Stocul vandabil rezultă dintr-o formulă aprobată, nu dintr-o copiere oarbă.
Formula proiectului poate porni de la sursă înmulțită cu un factor, apoi scade rezervările, alocările și marja de siguranță. Rezultatul este limitat la zero și la limitele canalului; termenii, rotunjirea și autoritatea se confirmă înainte de activarea fluxului LIVE.
Cheie idempotentă
O mișcare externă poate primi o cheie stabilă și o intrare în registru pentru a limita repetarea aceluiași efect.
Politică și inspecție
Returul nu repune automat cantitatea în stoc fără politica aprobată și confirmarea inspecției.
Așteptat și observat
Reconcilierea compară valoarea calculată cu valoarea locală ori externă și clasifică diferența.
Direcție autorizată
O diferență poate fi corectată numai către sistemul pentru care acea scriere a fost aprobată.
06 / PREFLIGHT, DIFERENȚE ȘI COADĂSIMULARE · STARE · INTERVENȚIE
Simularea construiește schimbarea propusă și arată diferența fără scriere externă.
Modul DRY RUN validează schema, identitatea, mapările și efectul estimat fără scriere comercială ori la distanță. Poate citi nomenclatoare și poate genera copii media locale numai dacă fluxul respectiv a fost configurat explicit.
- 01Primește intrarea
Verifică schema, tipurile, cheile și autoritatea declarată pentru fiecare câmp.
- 02Rezolvă regulile
Aplică identitatea, taxonomia, dicționarele, familia și formula de inventar.
- 03Construiește diferența
Separă elementele pregătite, avertismentele, blocajele și rezultatele ambigue.
- 04Cere decizia
Scrierea rămâne o operație ulterioară, limitată la direcția și lotul aprobate.
07 / SURSE ȘI IEȘIRI CONTROLATE
Fiecare intrare primește o schemă; fiecare ieșire păstrează propria responsabilitate.
Importul nu este presupus ca funcție implicită. Formatul, cheile, autoritatea, transformările, erorile și metoda de revenire sunt documentate înainte de dezvoltare.Fișiere contractate
Coloanele, codarea, tipurile, valorile lipsă, delimitarea lotului și reluarea sunt definite pentru sursa reală.
Citire și scriere separate
Drepturile, limitele, paginarea, erorile și direcția autorizată sunt tratate independent.
Câmpuri aprobate
Sistemul furnizează doar domeniul stabilit; integrarea nu îl declară automat autoritar pentru întregul catalog.
Sursă comercială posibilă
Produsele și variațiile pot rămâne referința comercială, cu mapări externe păstrate separat.
Orchestrare multicanal
Oferă index, mapare generică, cozi și registru operațional; nu este un motor universal pentru taxonomiile fiecărui canal.
Vezi implementarea ↗Reguli eMAG
Adaugă separat nomenclatoarele, categoriile finale, familiile, media, simularea și reconcilierea cerute de eMAG.
Vezi implementarea ↗Reguli Trendyol
Adaugă separat taxonomia, valorile permise, familia, media, simularea și reconcilierea proprii Trendyol.
Vezi implementarea ↗Circuit ERP
Definește separat rutele dintre ERP și WooCommerce; nu este inclus și nu transformă această soluție într-un conector ERP universal.
Vezi implementarea ↗08 / CE LIVRĂM
Un sistem adaptat la catalogul, sursele și canalele proiectului.
Livrabilele se aleg după audit și descriu atât calea normală, cât și blocajele, intervențiile și limitele operaționale.Înregistrare canonică
Câmpuri, tipuri, relații părinte–variație, reguli de completare și moment de indexare.
PRODUS · VARIAȚIE · MEDIAMatrice pe câmp și flux
Sursă aprobată, direcție de citire ori scriere, responsabil și dovada deciziei.
SURSĂ · DIRECȚIE · CONTROLRegistru pe canal
ID-uri locale și externe, tipuri de entitate, unicitate SKU/EAN și tratarea coliziunilor.
CORESPONDENȚĂ · STARE · DOVADĂTaxonomie și atribute
Categorii finale, excepții, priorități, dicționare și blocaje pentru câmpuri obligatorii.
CATEGORIE · VALOARE · AVERTISMENTIntrări controlate
Schema fișierului sau API-ului, chei, transformări, loturi, erori și metodă de revenire.
VALIDARE · SIMULARE · DECIZIEFormulă și registru
Factor, rezervări, alocări, marjă de siguranță, limite, chei idempotente și politica returului.
CALCUL · MIȘCARE · INSPECȚIECoadă și reconciliere
Stări, reluări limitate, diferențe clasificate, corecție autorizată și intervenție.
LUCRARE · DIFERENȚĂ · RESPONSABILProceduri verificabile
Teste, monitorizare, drepturi, retenție, lansare graduală și pași pentru incidente.
MEDIU DE TESTARE · LANSARE · SUPORT09 / COMPATIBILITATE ȘI LIMITE
Compatibilitatea este demonstrată pe fluxurile reale, nu presupusă din lista de sisteme.
WooCommerce, tema, extensiile, sursele, infrastructura și canalele externe sunt verificate împreună în mediul proiectului.| Componentă | Ce inventariem | Ce validăm |
|---|---|---|
| WooCommerce | produse, variații, atribute și stoc | identitate, autoritate și efectul extensiilor |
| WordPress și PHP | versiuni, drepturi și programare | compatibilitate, memorie și execuție de fundal |
| Bază de date | tabele, indexuri și retenție | integritate, concurență și plan de revenire |
| Fișiere și API-uri | scheme, chei și limite | formate, paginare, erori și reluări |
| ERP sau PIM | câmpuri și responsabilități | autoritate, conectivitate și direcții permise |
| Canale externe | taxonomii, nomenclatoare și cote | drepturi, răspunsuri și procesare asincronă |
| Media | surse, formate și asocieri | copii locale, limite și reguli pe variații |
10 / IMPLEMENTARE ȘI LANSARE
Pornim cu autoritatea datelor și extindem numai după o reconciliere verificată.
Fiecare etapă produce o decizie observabilă înainte ca următorul tip de date, următoarea direcție sau următorul canal să fie activat.- 01AUDIT
Catalog și surse
Inventariem produsele, variațiile, taxonomiile, media, inventarul, extensiile și sistemele conectate.
- 02CONTRACT
Autoritate și identitate
Definim sursa fiecărui câmp, direcțiile, cheile, coliziunile, blocajele și responsabilitățile.
- 03MODELARE
Scheme și mapări
Construim înregistrarea canonică, taxonomiile, dicționarele, familiile și formula de inventar.
- 04SIMULARE
Set reprezentativ
Rulăm preflightul în mediul de testare și verificăm diferențele fără scriere comercială ori externă.
- 05PILOT
Direcție limitată
Activăm un lot și o singură direcție aprobată, apoi urmărim stările și reconcilierea.
- 06OPERARE
Extindere graduală
Adăugăm surse și ieșiri numai după criterii acceptate, cu monitorizare și proceduri de intervenție.
12 / ÎNTREBĂRI FRECVENTE
Ce clarificăm înainte de prima schimbare controlată în catalog.
Întrebările și răspunsurile provin din registrul unic al portofoliului, astfel încât pagina vizibilă și datele structurate să rămână aliniate.01Catalog Data & Inventory este un PIM universal sau un plugin gata de instalat?
Nu. Pagina descrie o implementare personalizată, proiectată după catalogul, tema, extensiile, sursele de date și regulile operaționale ale magazinului. KEPA Plugins livrează prezentarea editorială, nu motorul funcțional al proiectului.
02Ce sistem este sursa principală pentru datele de catalog și inventar?
Autoritatea se stabilește separat pentru fiecare câmp și flux. WooCommerce poate rămâne sursa comercială, iar ERP-ul, un PIM, fișierele sau API-urile pot furniza numai câmpurile aprobate. Două sisteme nu sunt prezentate simultan drept sursă autoritară pentru aceeași valoare.
03Ce păstrează înregistrarea canonică a unui produs?
Modelul poate păstra ID-ul local, părintele, tipul, SKU-ul, EAN/GTIN când există, starea, prețurile, moneda, stocul, greutatea și dimensiunile, atributele, taxonomiile, media și momentul indexării. Produsul și fiecare variație rămân entități distincte.
04Cum sunt tratate identitățile, categoriile și nomenclatoarele externe?
Identitatea externă se păstrează separat pe canal și tip de entitate, iar unicitatea SKU/EAN și coliziunile sunt verificate explicit. Rutarea folosește categoria finală, cu excepția pe produs înaintea regulii de categorie și o variantă de rezervă numai când rezultatul este neambiguu. Valorile WooCommerce nu sunt rescrise automat după taxonomia unui marketplace.
05Cum sunt validate atributele, variațiile și imaginile?
Atributele sunt mapate la surse WooCommerce și comparate cu valorile permise de canal. Câmpurile obligatorii nemapate pot bloca fluxul, iar avertismentele rămân vizibile. O familie păstrează părintele, dimensiunile de variație, SKU/EAN pe unitatea vandabilă și regulile media pe culoare; publicarea unei familii incomplete poate fi oprită.
06Sunt incluse implicit importuri CSV, XML, JSON, API sau ERP?
Nu. Aceste intrări pot fi proiectate numai după definirea schemei, autorității câmpurilor, cheilor, formatelor, validărilor și căii de revenire. Preflightul construiește schimbarea propusă și diferența fără scriere comercială ori la distanță, dar poate face citiri și poate genera copii media locale dacă fluxul aprobat o cere.
07Cum poate fi calculat și protejat stocul disponibil?
Formula se confirmă pentru proiect și poate porni de la sursă înmulțită cu un factor, din care se scad rezervările, alocările și marja de siguranță, apoi rezultatul este limitat la zero și la limitele canalului. Mișcările externe pot folosi chei idempotente și un registru, iar retururile nu repun automat marfa în stoc fără politica și inspecția aprobate.
08Reconcilierea elimină diferențele în timp real și supravânzarea?
Nu. Reconcilierea periodică compară valoarea așteptată cu valoarea locală sau externă, clasifică diferențele și poate corecta numai direcția autorizată. Nu sunt garantate procesarea în timp real, consistența instantanee, ordinea totală, execuția distribuită exact o singură dată sau eliminarea supravânzării.
09Marketplace Hub și conectorii eMAG, Trendyol sau ERP sunt incluși în această implementare?
Nu. Sunt integrări separate, iar legăturile lor sunt afișate numai dacă paginile de prezentare sunt publicate valid. Marketplace Hub 0.2.1 oferă infrastructură generică de index, mapări, coadă, registru și SDK, nu un motor universal care validează ori publică singur întregul catalog. Regulile eMAG 1.4.5, Trendyol 0.6.5 și fluxul ERP de stoc 1.3.6 rămân în modulele lor dedicate.
10Ce protecții sunt necesare înainte de operațiile LIVE?
Definim un mediu de testare, o copie de siguranță verificată, jurnalul schimbărilor, drepturile minime, retenția și curățarea pentru PII, structurile transmise și jurnalele, apoi testăm un lot pilot. Nu promitem revenire globală: operațiile distructive și corecțiile în masă pornesc numai după aprobarea direcției, criteriilor de acceptare și căii de revenire.
URMĂTORUL PAS