WooCommerce · pachete · stocPLANȘA DE ASAMBLARE
Bundles & Multipacks: bundle multipack WooCommerce cu stoc derivat și defalcare controlată.
Modelăm pachetul ca produs vandabil și lista lui de componente ca un contract versionat. Magazinul poate afișa o singură ofertă, în timp ce stocul, comanda, pickingul și ERP-ul primesc reprezentarea aprobată pentru fiecare destinație.
- Rețetă versionată pentru fiecare pachet
- Disponibilitate derivată din componente
- Snapshot stabil la nivel de comandă
- Proiecție separată pentru ERP și canale
Bundles & Multipacks descrie o implementare funcțională personalizată. KEPA Plugins livrează această pagină editorială, nu motorul de pachete. Tipurile de produs, formulele și integrările reale se dezvoltă și se validează separat pentru magazin.
O ofertă, două reprezentăripachet în magazin · componente în operațiuni
MODEL CONCEPTUAL01 / CONTRACTUL DE COMPOZIȚIE
Pachetul începe cu o rețetă explicită, nu cu o etichetă comercială.
Definim ce se vinde, ce se consumă și ce rămâne doar prezentare. Domeniul de bază pornește prudent cu multipack și bundle fix; alegerile configurabile, pachetele imbricate și extensiile terțe intră numai după audit.Aceeași unitate × N
Un singur SKU vandabil este repetat într-o cantitate stabilită. Unitatea, cantitatea și regula de stoc rămân verificabile.
EXEMPLU: UNITATE × 6Mai multe SKU-uri
Lista de componente și necesarul fiecăreia sunt prestabilite. Rețeta poate avea propria versiune și perioadă de utilizare.
EXEMPLU: A × 2 + B × 1Alegeri și compatibilități
Sloturile, opțiunile, excluderile și dependențele cer un contract suplimentar. Nu sunt presupuse în implementarea de bază.
NUMAI DUPĂ AUDIT02 / IDENTITATE ȘI CANTITĂȚIOFERTĂ · REȚETĂ · COMPONENTĂ
Identitatea pachetului rămâne separată de identitatea componentelor.
Un bundle vândut ca ofertă distinctă poate avea propriul SKU și, când destinația îl cere, propriul EAN sau GTIN. Componentele păstrează ID-urile și corespondentele lor, iar o variație vandabilă nu este înlocuită de produsul părinte.
SKU comercial propriu
Identifică linia pe care o vede clientul și nu devine implicit identificatorul unei componente.
Entitate vandabilă
Referința indică produsul simplu ori variația exactă din care se consumă cantitatea.
Număr întreg pozitiv
Necesarul este validat, iar pozițiile duplicate pot fi agregate numai determinist.
Corespondență separată
ERP-ul și fiecare marketplace primesc identificatorii acceptați de propriul contract.
03 / DISPONIBILITATE DERIVATĂNECESAR · REZERVĂRI · LIMITĂ
Componenta limitativă stabilește câte pachete pot fi promise.
Pentru o rețetă fixă, motorul poate calcula pentru fiecare componentă cantitatea utilizabilă după rezervări, alocări și marja de siguranță, apoi împarte la necesarul din rețetă. Cea mai mică valoare întreagă devine disponibilitatea derivată, înaintea plafonului comercial aprobat.
Index invers
O schimbare de componentă identifică pachetele afectate fără scanarea întregului catalog la fiecare eveniment.
Coadă delimitată
Rezultatul nou intră în fluxurile autorizate, cu versiune, stare, reluări limitate și reconciliere.
O singură strategie
Stocul fizic propriu al unui kit și stocul derivat din componente nu sunt combinate implicit.
04 / PREȚ ȘI ALOCARE
Prețul comercial și distribuirea lui operațională sunt două decizii distincte.
Pachetul poate avea un preț fix ori unul derivat printr-o regulă aprobată. Când ERP-ul cere liniile componentelor, totalul real al comenzii este repartizat determinist și apoi reconciliat după rotunjire.
Fix sau derivat
Regula comercială are versiune, prioritate și interacțiuni documentate cu promoțiile și cupoanele.
Referință verificată
Alocarea poate folosi prețurile de referință ale componentelor, dacă sunt valide și provin din sursa aprobată.
Pondere pe unități
Dacă reperele lipsesc, o regulă explicită poate împărți valoarea după numărul de unități, fără a inventa prețuri.
Total păstrat
Ultima diferență de rotunjire este distribuită determinist, astfel încât suma liniilor să egaleze totalul real.
05 / SNAPSHOTUL COMENZIIISTORIC · CANTITATE · VERSIUNE
Comanda păstrează rețeta acceptată în momentul cumpărării.
Pe linia comenzii salvăm versiunea rețetei, componentele, cantitățile și reperele necesare proiecțiilor ulterioare. Cantitatea fiecărei componente rezultă din cantitatea pachetului înmulțită cu necesarul ei din snapshot.
- 01Validare în coș
Rețeta și disponibilitatea sunt reverificate înaintea acceptării.
- 02Snapshot pe linie
Se fixează versiunea și lista normalizată de componente.
- 03Proiecții ulterioare
Pickingul și ERP-ul citesc istoricul, nu rețeta curentă.
06 / PROIECȚII PE DESTINAȚIE
Aceeași comandă poate avea o reprezentare comercială și una operațională.
Destinația decide dacă primește pachetul, componentele sau ambele forme legate printr-un identificator stabil. Nicio proiecție nu este activată implicit pentru toate sistemele.O singură ofertă
Clientul vede numele, configurația, prețul și cantitatea pachetului, conform designului temei.
LINIE COMERCIALĂComponente executabile
Lista internă poate arăta fiecare SKU și cantitatea totală necesară pentru pregătire.
MANIFEST OPERAȚIONALDefalcare contractată
Implementarea auditată de referință defalcă un snapshot pe identificatori Supplier numerici și repartizează valoarea netă; regula nu este universală.
ADAPTOR SPECIFICOfertă acceptată de canal
Pachetul este transmis numai dacă destinația acceptă tipul de ofertă, identificatorii, conținutul și regula de inventar.
VALIDARE PE CANALIdentitate și autoritate
Poate furniza registrul canonic și regulile de inventar; schema BOM se adaugă explicit.
Vezi implementarea ↗Rută pentru componente
Poate proiecta snapshotul către ERP dacă payloadul, prețurile, identificatorii și confirmările au fost contractate.
Vezi implementarea ↗Infrastructură, nu BOM
Hub-ul auditat indexează tipul produsului, prețul, stocul și atributele, dar nu definește o schemă generică pentru componente.
Vezi implementarea ↗Reguli separate
Conectorii auditați tratează produse simple și familii de variații; nu oferă automat o semantică universală de bundle.
07 / PREFLIGHT ȘI OPERAREVALIDARE · DIFERENȚĂ · INTERVENȚIE
Înainte de LIVE, planșa trebuie să treacă toate porțile relevante.
Simularea verifică rețeta, identitatea, stocul, prețul, snapshotul și proiecțiile fără scriere comercială sau externă. Rezultatul separă elementele pregătite, avertismentele, blocajele și cazurile care cer decizie.
- 01StructurăREȚETĂ
Componente existente, cantități valide, fără cicluri și fără referințe ambigue.
- 02ComercialVALOARE
Preț, taxe, reduceri, SGR, shipping și total alocat reconciliate.
- 03OperaționalEXECUȚIE
Stoc, rezervare, snapshot, coadă, drepturi și adaptor de destinație verificate.
08 / CE LIVRĂM
Un circuit complet pentru definire, vânzare și execuție.
Componentele finale se aleg după audit. Fiecare livrabil are criterii de acceptare, limite și o procedură pentru cazurile care nu pot fi rezolvate automat.Rețetă versionată
Tip, componente, cantități, identități, perioadă de utilizare și reguli pentru modificări.
PACHET · BOM · VERSIUNEEditor sau import
Interfață adaptată temei administrative ori contract CSV/JSON, cu validări și previzualizare.
CREARE · VALIDARE · DIFERENȚĂMotor de disponibilitate
Formulă, dependențe, rezervări, invalidare cache, coadă și reconciliere controlată.
COMPONENTĂ · LIMITĂ · PACHETSnapshot imuabil
Versiune, componente, cantități și repere păstrate pe linia comercială acceptată.
ISTORIC · DOVADĂ · RELUARERegulă și alocare
Preț fix ori derivat, ponderi, rotunjire, taxe și reconcilierea totalului de comandă.
POLITICĂ · PONDERE · TOTALERP, picking și canale
Transformări distincte pe destinație, identificatori, răspunsuri și confirmări documentate.
ADAPTOR · PAYLOAD · ACKJurnal și intervenție
Stări, chei de deduplicare, reluări limitate, alerte, retenție și responsabil pentru excepții.
COADĂ · AUDIT · INCIDENTTeste și proceduri
Scenarii de acceptare, lansare graduală, monitorizare și cale de revenire pe operație.
STAGING · PILOT · SUPORT09 / COMPATIBILITATE ȘI LIMITE
Compatibilitatea se verifică pe întregul traseu al pachetului.
Tipurile de produs, tema, coșul, checkoutul, stocul, promoțiile, taxele, comenzile și sistemele externe trebuie testate împreună pe versiunile reale.| Suprafață | Ce inventariem | Ce validăm |
|---|---|---|
| WooCommerce | produse, variații, HPOS și stări | stoc, comandă și compatibilitate cu extensiile |
| Temă și Blocks | pagină produs, coș și checkout | interacțiune, accesibilitate și fallback |
| Preț și promoții | taxe, cupoane și reguli active | prioritate, total și rotunjire |
| Stoc și cache | autoritate, rezervări și dependențe | concurență, invalidare și reconciliere |
| ERP și picking | SKU-uri, payloaduri și confirmări | defalcare, deduplicare și intervenție |
| Marketplace | tip ofertă, EAN și cerințe | acceptare, stoc și conținut pe canal |
| Programare | Action Scheduler, WP-Cron și volume | loturi, reluări, monitorizare și retenție |
10 / IMPLEMENTARE ȘI LANSARE
Începem cu un pachet fix și extindem după reconcilierea traseului complet.
Fiecare etapă produce un artefact verificabil înainte ca o regulă nouă, un volum mai mare sau o destinație suplimentară să fie activată.- 01AUDIT
Produse și sisteme
Inventariem tipurile de produs, stocul, prețurile, comenzile, extensiile și destinațiile.
- 02CONTRACT
Rețetă și autoritate
Definim identitățile, cantitățile, formula de stoc, politica de preț și responsabilitățile.
- 03MODELARE
Snapshot și proiecții
Stabilim istoricul comenzii, defalcarea, payloadurile, stările și confirmările.
- 04STAGING
Preflight complet
Testăm rețeta, coșul, checkoutul, stocul, taxele, comanda și proiecțiile fără LIVE.
- 05PILOT
Pachet reprezentativ
Activăm un model fix și un volum limitat, apoi verificăm stocul și rezultatul în destinație.
- 06OPERARE
Extindere graduală
Adăugăm pachete, reguli și canale numai după criterii acceptate, monitorizare și runbook.
12 / ÎNTREBĂRI FRECVENTE
Ce clarificăm înainte de primul pachet activ.
Întrebările și răspunsurile provin din registrul unic al portofoliului, astfel încât pagina vizibilă și datele structurate să rămână aliniate.01Bundles & Multipacks este un plugin universal, gata de instalat?
Nu. Pagina descrie o implementare personalizată, construită după tipurile de produs, extensiile, stocul, prețurile și sistemele proiectului. KEPA Plugins livrează pagina editorială; motorul funcțional se dezvoltă și se testează separat.
02Care este diferența dintre multipack, bundle fix și pachet configurabil?
Un multipack repetă aceeași unitate vandabilă de un număr stabilit de ori. Un bundle fix combină SKU-uri și cantități prestabilite. Un pachet configurabil permite alegeri și are nevoie de reguli suplimentare pentru opțiuni, preț, stoc și snapshot; nu este presupus automat în domeniul de bază.
03Cum se calculează stocul unui pachet?
Pentru o rețetă fixă, disponibilitatea poate fi minimul dintre cantitățile componentelor împărțite la necesarul lor, după rezervări, alocări și marja aprobată. Formula, rotunjirea, backorder-ul și sursa autoritară se stabilesc în proiect; stocul propriu al pachetului și stocul derivat nu sunt combinate implicit.
04Ce se întâmplă când se modifică stocul unei componente?
Pachetele dependente pot fi recalculate și trimise în coada fluxurilor autorizate. Indexul de dependențe, cache-ul și reconcilierea limitează diferențele, dar nu garantează actualizare în timp real, ordine totală sau eliminarea supravânzării.
05Cum este stabilit și repartizat prețul bundle-ului?
Pachetul poate avea un preț fix ori unul derivat printr-o regulă aprobată. Dacă o destinație cere componentele, totalul net real poate fi repartizat proporțional după repere complete sau, printr-o regulă de rezervă explicită, după unități. Evaluările parțiale sunt blocate, iar diferența de rotunjire este reconciliată determinist.
06De ce este necesar un snapshot al rețetei în comandă?
Snapshotul păstrează versiunea rețetei, componentele, cantitățile și reperele acceptate la cumpărare. Astfel, modificarea ulterioară a catalogului nu rescrie istoria comenzii, iar pickingul și ERP-ul folosesc structura confirmată, nu rețeta curentă.
07Pachetul este defalcat automat în ERP?
Numai printr-un adaptor proiectat și testat pentru contractul ERP. Modulul Supplier auditat poate citi un snapshot existent, multiplica necesarul componentelor și repartiza valoarea netă, dar nu creează rețeta, snapshotul sau stocul derivat. Identificatorii, taxele, rotunjirea și confirmările se validează separat.
08Bundle-ul poate fi publicat automat în eMAG sau Trendyol?
Nu presupunem acest lucru. Marketplace Hub și conectorii eMAG ori Trendyol auditați operează în principal per SKU și nu cunosc automat compoziția unui bundle. Fiecare canal necesită o politică pentru oferta de pachet, identificatori, conținut, stoc și comenzi, iar publicarea depinde de cerințele și aprobarea canalului.
09Ce verifică preflightul înainte de activarea LIVE?
Verifică existența și identitatea componentelor, cantitățile, duplicatele, ciclurile, variațiile, stocul, prețurile, taxele, snapshotul, suma alocată și mapările de destinație. DRY RUN arată diferențele fără scriere comercială sau externă; blocajele și cazurile ambigue cer corectare ori decizie.
10Cum sunt tratate anulările și retururile?
Anularea poate elibera componentele conform snapshotului și unei chei stabile, numai o dată în fluxul local aprobat. Returul nu repune automat marfa în stoc fără politica și, când este necesar, inspecția fizică. Jurnalul și deduplicarea reduc repetările, dar nu garantează procesare distribuită exact o singură dată sau recuperare automată din orice incident.
URMĂTORUL PAS