Catalogo prodotti con varianti e bundle: schema e pattern UI

Perché varianti e bundle diventano complicati in fretta

Un catalogo sembra semplice quando ogni prodotto è un singolo articolo con un unico prezzo e una sola quantità a magazzino. Aggiungi colore, taglia, durata dell'abbonamento o confezioni specifiche per regione e quella semplicità si rompe. Una singola tabella “Prodotti” non può più rispondere a domande di base: quale cosa esatta stiamo vendendo e come la tracciamo?

Anche i clienti si aspettano che i dettagli siano corretti. Vogliono scegliere opzioni, vedere immediatamente il prezzo corretto e sapere se la loro scelta può essere spedita oggi. Se la pagina dice “Disponibile” ma la taglia selezionata non c’è, la fiducia cala rapidamente. Se il prezzo cambia solo al checkout, arrivano ticket al supporto e resi.

I bundle aggiungono un secondo livello di complessità perché sembrano prodotti ma si comportano come regole. Un “Starter Kit” potrebbe includere una bottiglia, una pompa e un set di filtri. La sua disponibilità dipende dalle parti, e i costi e i report devono comunque avere senso.

Segnali che il catalogo sta iniziando a cedere:

• Crei SKU duplicati solo per rappresentare un’opzione.
• I conteggi di stock sembrano sbagliati, soprattutto dopo la vendita di bundle.
• Le schermate admin diventano lunghe liste di elementi quasi identici.
• Sconti e tasse funzionano per articoli singoli ma si rompono per i kit.
• I report non riescono a rispondere a “cosa è stato venduto realmente?”

La soluzione è soprattutto disciplina: un modello dati coerente e pattern UI che rendano ovvie le scelte e la disponibilità per i clienti e il team.

Termini in linguaggio semplice: opzioni, varianti, SKU, bundle

Quando si parla di “varianti” spesso si mescolano concetti differenti. Chiarire i termini all’inizio rende decisioni successive (schema, UI, inventario) molto più facili.

La maggior parte dei team usa queste definizioni:

• Opzione: una scelta che il cliente può fare, come Taglia o Colore.
• Valore dell’opzione: un valore dentro un’opzione, ad esempio Taglia = M o Colore = Nero.
• Variante: una combinazione esatta di valori di opzione, come Taglia M + Colore Nero.
• SKU: un’unità vendibile che tracci nelle operazioni e nell’inventario. Una variante spesso mappa a uno SKU, ma non sempre.
• Bundle / kit / multipack: un prodotto composto da altri prodotti. Un bundle è un raggruppamento per marketing (le parti si possono vendere separatamente). Un kit è un set che “deve essere spedito insieme”. Un multipack è lo stesso articolo ripetuto (es. 3-pack di calzini).

Gli ID si confondono spesso nella pratica. Un ID interno è quello che usa il database. Uno SKU è il codice operativo (usato nel picking, riassortimento e report). Un barcode (UPC/EAN) è ciò che leggono gli scanner. Uno SKU può avere più barcode (per regioni diverse) e alcuni articoli non hanno barcode.

Una buona regola per decidere se qualcosa debba essere una variante vendibile: se può avere prezzo diverso, inventario diverso, peso o regole di spedizione diverse, trattalo come vendibile. La stessa T-shirt in Taglia M e Taglia XL di solito richiede conteggi di magazzino separati, quindi dovrebbero essere SKU distinti.

Decidi cosa deve supportare il tuo catalogo

Prima di scegliere uno schema, parti dalle domande che il business deve poter rispondere ogni giorno. Quando qualcuno guarda un articolo, puoi dire con sicurezza: è disponibile ora, quanto costa, come verrà spedito e quali regole fiscali si applicano?

Un modo utile per pensarci è decidere dove risiede ogni “fatto”. Metti i fatti condivisi sul prodotto e i fatti che cambiano sulla variante (SKU). Se li mischi, finirai per correggere lo stesso bug in due posti.

Domande che di solito decidono campi a livello prodotto vs variante:

• Se cambia per taglia/colore/materiale, appartiene alla variante.
• Se è vero per ogni combinazione, appartiene al prodotto.
• Se lo riporti per SKU (vendite, margine, resi), conservalo per variante.
• Se le operazioni lo usano per pick/pack/ship, conservalo dove lavora il magazzino: sullo SKU.
• Se può essere derivato in modo sicuro (es. nome di visualizzazione da valori di opzione), derivalo e conserva solo la sorgente.

Mantieni una sola fonte di verità. Per esempio, non conservare il “prezzo” sia sul prodotto che sulla variante a meno che i ruoli non siano chiari (es. prodotto ha MSRP, variante ha prezzo effettivo).

Pianifica i cambiamenti. Potresti aggiungere un’opzione dopo (es. “Lunghezza”), ritirare una variante o unire SKU dopo cambi fornitore. Questo procede più agevolmente quando le varianti sono record di prima classe, non solo etichette.

Se costruisci in AppMaster, una nomenclatura chiara delle entità nel Data Designer rende tutto più facile da mantenere quando i requisiti cambiano.

Uno schema pratico per prodotti e varianti

Uno schema pulito mantiene il catalogo comprensibile quando un prodotto semplice si trasforma in dozzine di combinazioni vendibili. L’obiettivo è modellare le scelte (quelle che i clienti fanno) separatamente dagli elementi vendibili (ciò che realmente stocchi e spedisci).

Un set affidabile di entità:

• Product: l’elemento “genitore” (nome, descrizione, brand, categoria, immagini di default)
• Option: un tipo di scelta (Taglia, Colore)
• OptionValue: i valori permessi (Small, Medium, Red, Blue)
• Variant: l’unità vendibile (una combinazione di valori)
• VariantOptionValue: tabella di join che collega una Variant ai suoi OptionValue

L’unicità della variante è dove molti cataloghi sbagliano. L’approccio più sicuro è normalizzato: fai rispettare un OptionValue per Option per ogni Variant e impedisci combinazioni duplicate. Se vuoi anche velocità, salva una “chiave variante” calcolata come color=red|size=m (o un suo hash) sulla Variant ed imponi l’unicità per Product.

Mantieni i campi che cambiano per combinazione su Variant, non su Product: SKU, barcode, prezzo, prezzo comparativo, costo, peso, dimensioni, stato (attivo/discontinuato) e immagini (o un’immagine principale o un piccolo set di immagini).

Per attributi custom (es. “materiale” o “istruzioni di cura”), evita di aggiungere colonne nuove all’infinito. Un campo JSONB su Product o Variant funziona bene in PostgreSQL, accompagnato da un piccolo livello di validazione nell’app.

Regole SKU che resistono nel tempo

Uno SKU è un identificatore per un’unità vendibile che ti impegni a mantenere stabile. Dovrebbe rispondere a una domanda: “Quale articolo esatto abbiamo venduto?” Non dovrebbe portare il nome marketing, il testo completo delle opzioni, la stagione o una storia intera. Se lo sovraccarichi, diventa difficile cambiare qualcosa senza rompere i report.

Decidi presto se gli SKU sono assegnati manualmente o generati. Gli SKU manuali sono più sicuri quando hai già un ERP, barcode o SKU fornitore che devono corrispondere. Gli SKU generati sono comodi quando hai molte varianti e cerchi coerenza, ma solo se le regole non cambieranno a metà anno. Un compromesso comune è un SKU base fisso che controlli, più un suffisso generato breve per attributi di variante.

Regole che restano leggibili e resistono alla crescita:

• Mantieni gli SKU stabili una volta che un ordine è stato piazzato. Non “correggere” SKU vecchi rinominandoli.
• Separa l’ID interno dallo SKU. Usa lo SKU per le persone, l’ID per i database.
• Usa prefissi brevi per famiglie di prodotto (es. TSH, MUG), non parole intere.
• Evita significati che possono cambiare (come “2026” o “SUMMER”) a meno che il tuo business non lavori davvero così.

Gli SKU dismessi non dovrebbero essere cancellati. Marchiali come inattivi, conserva la loro cronologia dei prezzi e mantienili selezionabili in ordini passati, rimborsi e report. Se sostituisci uno SKU, conserva un riferimento “sostituito da” così il supporto può tracciare cosa è successo.

Le regole di validazione prevengono danni lenti nel tempo: impone l’unicità degli SKU su tutti gli elementi vendibili, permetti solo lettere, numeri e trattini, imposta una lunghezza massima chiara (spesso 20–32 caratteri) e riserva prefissi per casi speciali (es. “BND-” per i bundle). In AppMaster, questi controlli si inseriscono bene come vincoli di dati più un Business Process che blocca il salvataggio se una regola è violata.

Logica inventario oltre il semplice disponibile/non disponibile

L’inventario diventa confuso quando lo stesso “prodotto” può significare molte unità vendibili diverse. Prima di scrivere regole, scegli la tua unità di inventario: tracci lo stock a livello prodotto, variante o entrambi?

Se i clienti scelgono taglia o colore, il livello variante è in genere il più sicuro. Una maglietta può essere “disponibile” globalmente, ma la variante Small-Blue può essere esaurita. Lo stock a livello prodotto funziona per articoli dove le varianti non cambiano ciò che fisicamente conservi (per esempio, una licenza digitale con piani di fatturazione diversi). Alcuni team tengono entrambi: prodotto per report, variante per vendita.

La prevenzione dell’overselling è meno una singola flag e più una combinazione di stati chiari. La maggior parte dei cataloghi ha bisogno di: reservation (bloccare unità brevemente per carrelli o ordini non pagati), backorder (permettere vendite con date di spedizione chiare), buffer di stock (quantità nascosta per coprire ritardi di sync) e aggiornamenti atomici (ridurre stock nella stessa operazione che conferma l’ordine).

I casi limite sono dove nasce lo “stock misterioso”. I resi dovrebbero aggiungere stock solo dopo ispezione, non quando si crea l’etichetta di reso. Gli articoli danneggiati devono essere spostati in uno stato o ubicazione separata così non appaiono vendibili. Le rettifiche di stock devono avere una traccia di audit (chi ha cambiato cosa e perché), specialmente se più canali aggiornano l’inventario.

I bundle e i kit aggiungono una regola chiave: non decrementare un record “bundle” se il bundle è solo un raggruppamento. Decrementa gli elementi componenti invece. Un 3-pack dovrebbe ridurre tre unità dello stesso SKU; un kit dovrebbe ridurre una unità di ogni componente.

Esempio: un “Starter Kit” include 1 bottiglia e 2 filtri. Se hai 10 bottiglie e 15 filtri, la disponibilità del kit è 7 perché i filtri sono il limite. La matematica basata sui componenti mantiene coerenti report, rimborsi e ristorni.

In AppMaster, questo si mappa chiaramente a tabelle di variant nel Data Designer e alla logica di reservation/decrement nel Business Process Editor, così ogni checkout segue le stesse regole.

Modellare bundle e kit senza rompere i report

I bundle sono il punto in cui i cataloghi spesso scivolano nei casi speciali. L’approccio più semplice è modellare i bundle come normali elementi vendibili, poi allegare una lista chiara di componenti.

Una struttura pulita è: Product (elemento vendibile) più BundleLines. Ogni BundleLine punta a uno SKU componente (o a un prodotto componente più una variante richiesta) e memorizza una quantità. Gli ordini mostrano ancora “un articolo”, ma puoi espanderlo in parti quando ti servono costo, inventario e dettagli di fulfillment.

La maggior parte delle configurazioni di bundle rientra in una di queste categorie:

• Fixed bundle (kit): sempre gli stessi componenti e quantità.
• Configurable bundle: il cliente sceglie tra componenti consentiti (anch’essi salvati come righe nell’ordine).
• Virtual bundle: un raggruppamento per merchandising (spesso senza effetto inventario), utile per promozioni senza complicare la logistica.

Il pricing è dove i team accidentalmente rompono i report. Decidi in anticipo cosa appare sulla riga d’ordine e cosa alimenta i report di margine e inventario. Approcci comuni sono prezzo fisso del bundle, somma delle parti, o somma scontata con regole per componente (es. “scegli 3 articoli, il più economico è scontato del 50%”).

L’inventario deve essere altrettanto rigoroso: un kit è disponibile solo se ogni componente richiesto è disponibile nelle quantità necessarie. Per i report, conserva due viste della vendita:

• Articolo venduto: lo SKU del bundle (per ricavi, conversione e merchandising).
• Componenti consumati: righe espanse del BundleLines (per movimenti di stock, COGS e packing list).

In AppMaster, questo si adatta naturalmente: una tabella Bundle più righe BundleLine, con Business Processes che espandono i componenti al checkout e scrivono sia la vendita del bundle sia il consumo dei componenti in un’unica transazione.

Pattern UI per la scelta di opzioni e varianti

Una buona UI per le opzioni mantiene le persone in movimento. Una cattiva UI le fa indovinare, incappare in errori e abbandonare. La chiave è guidare gli utenti verso una variante reale acquistabile presto, mostrando chiaramente cosa cambiano le loro scelte.

Lato cliente: opzioni prima, varianti dopo

Un pattern affidabile è presentare le opzioni (Taglia, Colore, Materiale), poi calcolare e mostrare solo le scelte che hanno ancora senso.

Invece di lasciare che i clienti scelgano qualsiasi combinazione e fallire solo quando cliccano Aggiungi al carrello, disabilita le combinazioni impossibili non appena l’utente fa una scelta. Per esempio, una volta che qualcuno seleziona Colore = Nero, le taglie che non esistono in Nero dovrebbero diventare disabilitate (non rimosse), così il cliente capisce cosa non è disponibile.

Man mano che la selezione cambia, aggiorna le parti che contano di più: prezzo (incluso il prezzo promozionale e eventuali sconti bundle), immagini principali (in base al colore o allo stile selezionato), stato di stock (stock della variante esatta, non stock generico del prodotto), stima di consegna (se varia per variante) e opzionalmente lo SKU o “Codice articolo” per il supporto.

Mantieni l’interfaccia calma. Mostra pochi gruppi di opzioni alla volta, evita dropdown enormi quando swatch o pulsanti funzionano meglio e rendi la selezione corrente evidente.

Lato admin: modifica varianti come un foglio di calcolo

In admin le persone hanno bisogno di velocità, non di belle card. Una griglia di varianti funziona bene: ogni riga è uno SKU, ogni colonna è un’opzione o una regola (prezzo, barcode, peso, stock, attivo/inattivo). Aggiungi azioni di massa per operazioni comuni come aggiornamenti di prezzo, toggle disponibilità o assegnazione immagini.

Se costruisci questo in AppMaster, una configurazione pratica è una griglia legata alla tabella Variant con filtri (valore opzione, stato attivo, stock basso), più un’azione di aggiornamento in blocco che valida le regole prima del salvataggio.

Passo passo: selezione variante e controlli di disponibilità del bundle

Un flusso di selezione dovrebbe sembrare semplice, ma sotto deve avere regole rigorose. L’obiettivo è sapere sempre quale SKU esatto il cliente sta configurando e se può essere acquistato ora.

Selezione variante (prodotto singolo)

Carica più del nome e delle immagini del prodotto. Ti serve l’insieme completo di valori di opzione (Taglia, Colore) e la lista delle combinazioni di varianti valide che esistono come SKU.

Un flusso affidabile:

1. Recupera il prodotto, le sue opzioni e tutte le varianti esistenti (o una mappa compatta delle combinazioni valide).
2. Memorizza le selezioni attuali del cliente (es.: Taglia=M, Colore=Nero) e aggiornale a ogni clic.
3. Dopo ogni cambiamento, trova la variante corrispondente confrontando i valori selezionati con la lista di varianti.
4. Se c’è una corrispondenza ed è acquistabile (attiva, prezzo impostato, non bloccata), abilita Aggiungi al carrello.
5. Se non c’è corrispondenza, tieni Aggiungi al carrello disabilitato e guida il cliente verso una scelta valida.

Un piccolo dettaglio UI che previene frustrazione: disabilita i valori di opzione impossibili non appena vengono fatte scelte precedenti. Se Taglia=M esiste solo in Nero, mostra gli altri colori come non disponibili una volta selezionata M.

Disponibilità bundle (kit composto da componenti)

Per i bundle, “in stock” non è un singolo numero. Dipende dai componenti. La regola usuale è:

bundle_available = minimo sui componenti di floor(component_stock / component_qty_per_bundle)

Esempio: un “Starter Kit” richiede 1 bottiglia e 2 filtri. Se hai 10 bottiglie e 9 filtri, la disponibilità è min(floor(10/1)=10, floor(9/2)=4) = 4 kit.

I messaggi d’errore dovrebbero essere concreti. Preferisci “Solo 4 kit disponibili (i filtri limitano questo bundle)” rispetto a “Esaurito.” In AppMaster, questo tipo di controllo è semplice da esprimere in un Business Process: calcola prima la variante corrispondente, poi i limiti del bundle, e restituisci uno stato chiaro per l’UI da mostrare.

Errori comuni e trappole da evitare

I cataloghi si rompono quando modelli per “tutto ciò che potrebbe esistere” invece di “ciò che venderai davvero”. Il modo più veloce per metterti in un angolo è generare tutte le possibili combinazioni di opzioni a priori e poi cercare di tenerle pulite man mano che il catalogo cresce.

Creare varianti che non saranno mai stoccate è la trappola classica. Se hai 4 colori x 6 taglie x 3 materiali fai 72 varianti. Se ne venderai realmente solo 10, le altre 62 creano rumore, invitano errori e rallentano i report.

Anche il pricing è una fonte silenziosa di bug. I problemi nascono quando lo stesso prezzo esiste in più posti (prodotto, variante, tabella prezzi, tabella promo) senza una singola fonte di verità. Una regola semplice aiuta: conserva il prezzo base una volta sola, poi memorizza override solo dove sono davvero necessari (per esempio, una variante ha prezzo diverso).

Bundle e kit falliscono nell’inventario quando decrementi sia il bundle sia i suoi componenti. Se vendi un “Starter Kit” che include 1 bottiglia e 2 filtri, sottrarre 1 kit e contemporaneamente 1 bottiglia e 2 filtri fa scendere lo stock a zero troppo presto. Mantieni il bundle come elemento vendibile, ma calcola disponibilità e decrementi dai componenti.

Gli strumenti admin possono causare danni se permettono dati non validi. Aggiungi protezioni presto:

• Blocca SKU duplicati, anche tra elementi archiviati.
• Richiedi che ogni variante abbia tutti i valori di opzione (niente “taglia mancante”).
• Impedisci a due varianti di condividere la stessa combinazione di opzioni.
• Valida i componenti del bundle (nessuna quantità zero, nessuno SKU mancante).

Infine, pianifica i cambiamenti. Aggiungere una nuova opzione dopo (es. “Larghezza” per le scarpe) è una migrazione, non una casella da spuntare. Decidi cosa succede alle varianti esistenti, come vengono impostati i valori di default e come gli ordini vecchi mantengono il loro SKU e lo snapshot delle opzioni.

Controlli rapidi prima del lancio

Prima del lancio, esegui un controllo su quelle cose che nella pratica si rompono: trovare SKU, aggiornare stock e bloccare acquisti impossibili.

Assicurati che ogni SKU vendibile sia facile da trovare. La ricerca dovrebbe trovarlo per nome, codice SKU, barcode/GTIN e attributi chiave (come taglia o colore). Se usi lo scanning in magazzino, testa alcune scansioni fisiche e conferma che puntino allo SKU esatto, non solo al prodotto genitore.

Sii rigoroso su dove avvengono le variazioni di stock. Scegli una sola fonte di verità (la logica di movimento inventario) e assicurati che ogni evento la usi: ordini, cancellazioni, rimborsi, aggiustamenti manuali e assemblaggio bundle. Se lo stock può essere modificato in due schermate o workflow, la deriva è garantita.

Controlli di lancio da eseguire:

• Seleziona opzioni nell’UI e conferma che le combinazioni invalide siano bloccate presto (prima di Aggiungi al carrello), non scoperte al checkout.
• Per i bundle, conferma che la disponibilità sia guidata dal componente più scarso e dalla giusta quantità (2 batterie per kit dovrebbero dimezzare la disponibilità).
• Ritira uno SKU e verifica che sparisca da browsing e ricerca, ma che appaia correttamente in ordini passati, fatture e report.
• Esegui un ordine di prova, cancellalo, poi rifallo; lo stock dovrebbe tornare e riservarsi pulitamente.

Se costruisci in AppMaster, tieni le regole di aggiornamento stock in un unico Business Process e chiamalo da ogni percorso. Quell’abitudine previene la maggior parte dei bug di inventario.

Scenario di esempio e passi pratici successivi

Immagina un negozio di abbigliamento che deve ancora sistemare seriamente il catalogo.

Vendi una T-shirt con due opzioni: Taglia (S, M, L) e Colore (Nero, Bianco). Ogni combinazione acquistabile è una sua variante con SKU, prezzo (se necessario) e inventario propri.

Nello schema, conserva un record Product per “Classic T-shirt”, due record Option (Taglia, Colore) e diversi record Variant. Ogni Variant memorizza i valori di opzione selezionati (es.: Taglia=M, Colore=Nero) e lo SKU (es.: TSH-CL-M-BLK). L’inventario è tracciato a livello Variant, non a livello Product.

Nell’UI, restringi le scelte e previeni vicoli ciechi. Un pattern pulito è: mostra prima tutti i Colori, poi solo le Taglie che esistono per il Colore scelto (o viceversa). Se “Bianco + L” non esiste, non permettere la selezione o mostralo disabilitato con una nota chiara.

Aggiungi ora un bundle: “Gift Set” che include:

• 1x Classic T-shirt (qualsiasi variante)
• 1x Sticker pack (SKU semplice)

La disponibilità del bundle è limitata dal componente più scarso. Se lo Sticker pack è a stock 5, non puoi vendere più di 5 bundle, anche se le T-shirt sono abbondanti. Se il bundle richiede una variante specifica di T-shirt (es. Nero M), allora lo stock bundle è min(StickerPackStock, NeroMStock).

Passi pratici in AppMaster:

• Costruisci le tabelle nel Data Designer (Products, Options, OptionValues, Variants, VariantOptionValues, Inventory, Bundles, BundleComponents).
• Implementa “trova varianti valide” e “calcola disponibilità bundle” nel Business Process Editor.
• Genera UI web e mobile native dallo stesso progetto, usando le stesse regole di filtraggio varianti e disponibilità ovunque.

Se vuoi prototipare rapidamente questo end-to-end, AppMaster è pensato per costruire app complete con logica di business reale, esattamente ciò di cui dipendono la selezione varianti e le regole di inventario dei bundle.