Gambio combina un catalogo e-commerce ampio con prezzi per gruppi Customer, gestione dei contenuti, campi multilingua, moduli e due ambienti operativi: Gambio Cloud e Gambio self-hosted. I record visibili possono sembrare familiari, ma le loro relazioni sono specifiche della piattaforma. Un articolo può essere collegato a più Categories, utilizzare diversi tipi Product, contenere campi e tab aggiuntivi, limitare la visibilità in base al gruppo Customer e ricevere prezzi specifici per gruppo o quantità. Anche le scelte dell’acquirente possono provenire da generazioni diverse della logica di catalogo Gambio, tra cui attributi degli articoli, proprietà degli articoli, opzioni correnti, Product Options e Product Variants.
Queste differenze rendono inaffidabile un trasferimento puramente campo per campo. Un valore colore nell’origine può rappresentare un’informazione descrittiva, un attributo legacy, un valore di opzione oppure una parte di una variante con identità propria. Un livello Customer nell’origine può controllare visibilità, prezzo, trattamento fiscale, quantità minima o più relazioni contemporaneamente. Un record di contenuto può appartenere al Content Manager, a un tab Product, a una Category, a un blocco del tema o a un modulo. Il modello di migrazione deve quindi identificare quale struttura Gambio possiede ciascun valore e mantenere i record correlati che gli conferiscono significato commerciale.
Il significato dei record Gambio dipende dalla generazione del catalogo e dall’ambiente
Gambio dispone di una linea di piattaforma attuale e attiva, ma gli store utilizzati da molti anni possono contenere dati creati con strutture di catalogo precedenti, moduli di terze parti o modifiche personalizzate al database. La versione dell’origine e i componenti installati incidono sul fatto che una scelta sia memorizzata come vecchio attributo o proprietà di un articolo, opzione corrente, Product Option, Product Variant oppure record di un modulo personalizzato.
Gli ambienti Cloud e self-hosted utilizzano entrambi Gambio, ma creano confini diversi nella responsabilità dei record tecnici. Gli store Cloud dipendono normalmente in misura maggiore da hosting e aggiornamenti gestiti dalla piattaforma. Gli store self-hosted possono contenere file locali, GXModules, temi, aggiunte al database o modifiche dirette che non hanno un equivalente in un’installazione di destinazione pulita. Questa distinzione non dovrebbe cambiare il significato di Products, Customers o Orders nativi, ma influenza quanto sia possibile considerare con sicurezza i campi gestiti da estensioni come dati Gambio trasferibili.
| Evidenza nell’origine | Interpretazione in Gambio | Conseguenza per la relazione |
|---|---|---|
| Record Product Option e Product Variant correnti | Modello attuale delle scelte dell’acquirente e delle combinazioni vendibili | Conservare insieme definizioni delle opzioni, valori selezionati, identità della variante e valori commerciali. |
| Attributi o proprietà legacy degli articoli | Struttura appartenente a una generazione precedente del catalogo | Interpretare in base alla versione di origine invece di forzarla nella terminologia corrente. |
| GXModule o tabella di terze parti | Entità gestita da un modulo o estensione di un record principale | Identificare il modulo e il record Product, Customer, Order o di contenuto che estende. |
| Record di uno store Cloud | Dato Gambio nativo con contesto tecnico gestito dalla piattaforma | Mantenere separati i dati commerciali dalla configurazione tecnica gestita dalla piattaforma. |
| Campo o tabella personalizzata in uno store self-hosted | Estensione locale, schema modificato o record di integrazione | Assegnare una destinazione soltanto dopo aver identificato il responsabile del dato e il processo che lo utilizza. |
| Identificativo esterno | Chiave ERP, PIM, WMS, marketplace, contabile o di evasione | Conservare la chiave stabile necessaria per ricollegare lo store di destinazione. |
Versione e ambiente sono quindi informazioni sulla provenienza dei dati. Spiegano perché due store Gambio possano mostrare la stessa etichetta pur memorizzando o utilizzando il valore in modo diverso.
Products, tipi di articolo, Categories e campi di catalogo sono strutture distinte
Gambio usa comunemente il termine articolo per indicare un Product vendibile. Un Product può contenere numero articolo, quantità disponibile, peso, Manufacturer, classe fiscale, stato di consegna, barcode o EAN, unità di confezionamento, unità di quantità, quantità minima ordinabile, incrementi di quantità, immagini, descrizioni multilingua, metadati e collegamenti alle Categories. Il tipo Product può inoltre distinguere un articolo standard, un articolo scaricabile o un servizio.
Le Categories sono record separati e un Product può essere collegato a più di una Category. Questa relazione è importante quando uno store di origine duplica i record Product per ottenere più posizionamenti oppure quando le Categories svolgono anche funzioni di merchandising, SEO o navigazione. La rappresentazione corretta sulla destinazione può essere un solo Product con più assegnazioni Category, anziché diversi Products che condividono lo stesso contenuto.
Gambio supporta inoltre campi Product aggiuntivi, tab Product, filtri, assegnazioni alla tassonomia Google, Manufacturers, contenuti correlati e indicatori di merchandising. Questi valori non devono essere compressi nella descrizione solo perché risultano visibili nella pagina Product.
| Modello nell’origine | Struttura Gambio da considerare | Significato da conservare |
|---|---|---|
| Articolo fisico vendibile | Record Product standard | Identità, prezzo, imposta, stock, peso, immagini e assegnazioni Category. |
| File digitale | Product scaricabile e relazione di accesso con l’Order | Identità del file, condizioni di accesso e contesto storico dell’acquisto. |
| Servizio o articolo senza spedizione | Tipo Product servizio | Identità vendibile senza inventare dati di evasione fisica. |
| Product presente in più rami di navigazione | Un Product collegato a più Categories | Identità condivisa con più percorsi di scoperta. |
| Specifica tecnica | Campo aggiuntivo, valore di filtro o contenuto strutturato | Il significato descrittivo resta separato da una scelta dell’acquirente. |
| Spiegazione Product estesa | Tab Product o relazione di contenuto | Il contenuto resta collegato al Product corretto e alla lingua corretta. |
| Identità di fornitore o brand | Manufacturer o relazione con dati master esterni | Significato del brand e chiave esterna restano coerenti. |
La regola principale è conservare una volta l’identità Product e poi ricostruirne le relazioni. Duplicare un Product per riprodurre ogni percorso di navigazione dell’origine crea incoerenze di stock, SEO e storico Orders.
Opzioni, Product Options, varianti, attributi e proprietà non devono essere confusi
Il modello Gambio per le scelte dell’acquirente si è evoluto nel tempo. Le risorse di sviluppo correnti distinguono opzioni, Product Options e Product Variants, mentre gli store più vecchi possono ancora utilizzare attributi o proprietà degli articoli. Queste strutture possono apparire simili al cliente, ma non sono intercambiabili a livello dati.
Un’opzione definisce un insieme di scelte, ad esempio taglia o colore. Una Product Option collega un’opzione a un Product. Una Product Variant rappresenta una combinazione concreta derivata dalle Product Options e può contenere dati commerciali specifici della combinazione. Attributi o proprietà più vecchi possono memorizzare valori simili attraverso tabelle e regole differenti. I dati di origine devono quindi essere classificati in base al funzionamento e alla provenienza, non soltanto all’etichetta.
| Funzionamento nell’origine | Domanda di interpretazione per Gambio | Relazione che deve sopravvivere |
|---|---|---|
| La scelta cambia soltanto la selezione mostrata | Opzione o Product Option senza identità commerciale indipendente | Collegamento Product-opzione e valore selezionato. |
| La combinazione ha SKU, stock, prezzo, peso, immagine o disponibilità propri | Product Variant | Product padre, valori delle opzioni selezionate, identità della variante e valori commerciali. |
| L’acquirente inserisce testo o personalizzazione | GX-Customizer o input gestito da un modulo | Il valore inserito resta collegato alla riga Order. |
| Il valore descrive il Product | Campo aggiuntivo, filtro, proprietà o contenuto | Il valore descrittivo resta distinto dalla combinazione acquistata. |
| Lo store legacy utilizza attributi degli articoli | Struttura di attributi legacy | Nome attributo, valore, effetto sul prezzo, comportamento dello stock e provenienza. |
| Lo store legacy utilizza proprietà degli articoli | Struttura legacy di proprietà o combinazioni | Gruppi di proprietà, valori, combinazioni e relazioni Product. |
Un semplice selettore di taglia può essere rappresentato in modo lineare. Una matrice di combinazioni con stock e immagini distinti richiede invece identità a livello variante. Un campo di personalizzazione appartiene alla riga Order acquistata, non a una variante riutilizzabile. Trattare tutti e tre i casi come normali opzioni può far apparire corretto il catalogo pur facendo perdere significato storico e per l’evasione degli ordini.
Stock, prezzi, gruppi Customer e regole di quantità formano un livello commerciale
I dati Product di Gambio possono essere collegati a controllo dello stock, quantità minime ordinabili, incrementi di quantità, visibilità per gruppo Customer, prezzi specifici per gruppo, prezzi graduati, sconti, classi fiscali, offerte speciali e altre regole commerciali. Queste relazioni determinano chi può vedere un articolo, quale prezzo riceve e quale quantità può acquistare.
Un gruppo Customer non è soltanto un’etichetta di segmentazione. Gambio può utilizzarlo per controllare la visibilità dei Products e i prezzi Product. Un livello wholesale nell’origine può quindi richiedere una relazione con un gruppo Customer, mentre un segmento di marketing può appartenere a un’altra struttura. Gli Orders storici devono mantenere le evidenze effettive di prezzo, sconto, imposta e quantità registrate al momento dell’acquisto, anziché essere reinterpretati in base al gruppo attuale del Customer.
| Significato nell’origine | Relazione Gambio | Confine di rappresentazione |
|---|---|---|
| Product disponibile solo ad acquirenti approvati | Visibilità Product-gruppo Customer | Conservare la relazione di accesso, non soltanto il nome del gruppo. |
| Prezzo wholesale o dealer | Prezzo Product per gruppo Customer | Mantenere collegati Product, gruppo, valuta e prezzo. |
| Soglia di quantità | Prezzo graduato o regola dipendente dalla quantità | Conservare le soglie e l’ambito Customer che ne beneficia. |
| Quantità minima di acquisto | Valore minimo ordinabile del Product | Mantenere la regola commerciale separata dalla quantità di inventario. |
| Stock per combinazione vendibile | Stock a livello variante quando previsto | Non assegnare tutta la quantità al Product padre. |
| Prezzo promozionale corrente | Relazione di prezzo attiva | Mantenere separato dal prezzo storico memorizzato nei vecchi Orders. |
È in questo livello che campi apparentemente piccoli diventano rilevanti sul piano operativo. Un prezzo copiato senza la relazione con il gruppo non è lo stesso prezzo. Un valore di stock copiato senza l’identità della variante non rappresenta lo stesso record di inventario.
Customers, indirizzi, gruppi e Orders contengono tipi diversi di evidenza
I dati Customer di Gambio possono includere identità dell’account, indirizzi, appartenenza a gruppi Customer, contesto commerciale o dealer, note, preferenze di comunicazione, Reviews e relazioni amministrative. Questi record devono essere separati in base allo scopo. Una voce della rubrica indirizzi non equivale allo snapshot di un indirizzo registrato al momento dell’Order. L’appartenenza a un gruppo non equivale a uno sconto storico. Un account amministratore non è un account Customer.
Gli Orders contengono evidenza commerciale storica: identità di un Customer o cliente non registrato, indirizzi di fatturazione e spedizione, riferimenti a Products e varianti, scelte selezionate, quantità, prezzi, sconti, imposte, spedizione, etichette dei metodi di pagamento, stati Order, commenti, fatture, documenti di consegna, recessi e altri record correlati. Un Order migrato deve restare comprensibile anche se lo store di destinazione utilizza configurazioni attive differenti per pagamenti, spedizioni, imposte o stati.
| Elemento storico | Struttura Gambio responsabile | Significato da mantenere |
|---|---|---|
| Acquirente registrato | Account Customer | Identità e relazione con Orders e indirizzi. |
| Acquirente senza registrazione | Snapshot dell’identità a livello Order | Contesto storico dell’acquirente senza creare un account inesistente. |
| Indirizzo salvato | Rubrica indirizzi Customer | Relazione riutilizzabile dell’indirizzo Customer. |
| Indirizzo di fatturazione o spedizione in un Order | Snapshot al momento dell’Order | Evidenza della transazione così come effettuata. |
| Scelta Product su una riga Order | Etichetta Product/variante e valori selezionati | Articolo acquistato esatto, anche se il catalogo cambia in seguito. |
| Etichette di pagamento e spedizione | Storico Order | Evidenza storica del metodo, non configurazione del metodo corrente. |
| Storico di rimborsi, recessi o stati | Record Order correlati | Il contesto successivo alla vendita resta tracciabile. |
Il modello più solido mantiene distinti i dati master Customer dagli snapshot Order. L’aggiornamento di un indirizzo Customer dopo la migrazione non deve riscrivere l’indirizzo registrato in un Order precedente.
Content Manager, contenuti Product, URL e temi hanno proprietari distinti
I contenuti Gambio possono risiedere nel Content Manager, nelle descrizioni Product, nei tab Product, nelle descrizioni Category, in banner, teaser slider, menu, pagine legali, pagine di errore, blocchi del tema, file di lingua o moduli. Ogni struttura ha un proprietario e una relazione con i percorsi differenti.
Le CMS Pages devono conservare identità, lingua, contenuto, visibilità, posizionamento nei menu e relazione con gli URL. I tab Product restano collegati ai Products. Le descrizioni Category restano collegate alle Categories. Un blocco del tema o una configurazione StyleEdit controlla la presentazione e non deve essere scambiato per una CMS Page trasferibile. Contenuti legali e policy possono richiedere una revisione aziendale aggiornata, ma identità e posizionamento del record possono comunque essere mantenuti come dati di contenuto.
I record Product e Category di Gambio possono inoltre contenere parole chiave URL, URL rewrite, metadati, termini di ricerca e valori multilingua. Queste relazioni influiscono sulla reperibilità, ma non rendono navigazione, contenuti e SEO un unico oggetto.
| Elemento visibile nella vetrina | Probabile struttura Gambio responsabile | Implicazione per il modello dati |
|---|---|---|
| Pagina informativa o policy | Voce Content Manager | Conservare contenuto, lingua, percorso e posizionamento. |
| Spiegazione Product aggiuntiva | Tab Product o contenuto Product | Mantenere collegata al Product anziché creare una Page generica. |
| Testo di landing di una Category | Record Category | Mantenere insieme all’identità Category e al relativo percorso. |
| Banner o teaser della homepage | Configurazione banner/teaser | Risorsa di contenuto e posizionamento sono elementi separati. |
| Voce di menu | Configurazione di navigazione | Una Page o Category migrata non ricrea automaticamente il proprio posizionamento nel menu. |
| Blocco del tema o override di template | Presentazione tramite tema o modulo | Ricostruire la presentazione senza classificare il codice come contenuto. |
| Vecchio URL Product o Category | URL dell’entità e relazione di redirect | Conservare la relazione tra percorso di origine e destinazione. |
Una migrazione pulita può conservare i contenuti anche quando cambia la presentazione. Il requisito essenziale è che ogni record raggiunga la struttura Gambio corretta e resti collegato al proprio percorso e alla propria lingua.
Moduli, GXModules, API e sistemi esterni estendono il modello nativo
Gambio supporta moduli, GXModules, temi, REST API, importazioni ed esportazioni e integrazioni con marketplace, contabilità, evasione degli ordini, ricerca o altri sistemi. Questi componenti possono creare campi, tabelle, stati, identificativi e record di processo che non appartengono al modello Product, Customer o Order nativo.
La presenza di un valore nel database non lo rende un campo Gambio core. Un modulo può memorizzare un ID di listing marketplace, un codice fornitore, un riferimento di transazione di pagamento, lo stato di un flusso Product, una proprietà Customer personalizzata o un indicatore per l’elaborazione degli Orders. Il significato dipende dal modulo o dal sistema esterno che utilizza quel valore.
| Responsabile del dato | Esempi di record | Decisione di rappresentazione |
|---|---|---|
| Core Gambio | Products, Categories, Customers, Orders, contenuti, opzioni, varianti | Rappresentare attraverso le relazioni dati native. |
| Modulo Gambio o GXModule | Campi del modulo, tabelle, stati, record collegati alla configurazione | Conservare soltanto con un responsabile di destinazione identificato e la relativa chiave del record core. |
| Tema o StyleEdit | Layout, blocchi, template, impostazioni visive | Trattare come presentazione lato destinazione, non come dati master commerciali. |
| ERP/PIM/WMS esterno | Identificativi master, stock, fornitore, prezzi o record di evasione | Mantenere chiavi cross-system stabili e relativa autorità. |
| Marketplace o canale | ID listing, stati delle offerte, Categories del canale, metadati di sincronizzazione | Mantenere separati dal Product canonico salvo che il flusso di destinazione continui a utilizzarli. |
| Codice personalizzato | Tabelle su misura o campi core modificati | Definire esplicitamente a quale entità appartengono invece di presumere il supporto nativo. |
Gli store Cloud e self-hosted possono rendere disponibili evidenze tecniche differenti, ma vale la stessa regola: i dati attivi gestiti da estensioni devono avere un responsabile che continui a utilizzarli. Gli artefatti tecnici obsoleti non diventano utili soltanto perché esistono nel database di origine.
Decisioni di rappresentazione in Gambio in base al significato commerciale
| Modello nell’origine | Domanda corretta per Gambio | Conseguenza di un presupposto errato |
|---|---|---|
| Product padre con combinazioni figlie | Il valore di origine è un’opzione, una Product Option, una variante corrente oppure una combinazione legacy di attributi/proprietà? | SKU figlio, stock, prezzo, immagine o valori selezionati vengono persi o duplicati. |
| Product visibile soltanto ai grossisti | La limitazione appartiene alla visibilità per gruppo Customer? | Il Product diventa pubblico oppure non accessibile agli acquirenti previsti. |
| Prezzo per livello o quantità | Quali Product, gruppo, soglia e valuta definiscono il prezzo? | Gli acquirenti ricevono un prezzo errato anche se il valore numerico esiste. |
| Contenuto mostrato in una pagina Product | È un tab Product, un campo aggiuntivo, un blocco di modulo o una CMS Page? | Il contenuto arriva senza la relazione che ne determina la visualizzazione. |
| Stato Order storico | Quale storico Order, pagamento, evasione o recesso spiega lo stato? | Il personale non riesce a interpretare con affidabilità la transazione passata. |
| Campo creato da un modulo | Quale modulo o sistema esterno possiede e aggiorna il valore? | Un dato orfano viene copiato in un campo che nessun processo mantiene. |
| URL legacy | Quale record Product, Category o di contenuto deve ricevere il redirect? | La continuità della ricerca e dei link interni si interrompe nonostante il trasferimento dei record sia riuscito. |
Una migrazione verso Gambio mantiene il significato quando provenienza Product, scelte degli acquirenti, regole commerciali per gruppi Customer, evidenze storiche degli Orders, proprietà dei contenuti e record delle estensioni vengono trattati come domini collegati ma distinti.
Conclusione
La rappresentazione del modello dati Gambio è influenzata dalla generazione del catalogo, dai tipi Product, dai collegamenti Category, dalle strutture di opzioni correnti e legacy, dai prezzi e dalla visibilità per gruppi Customer, dagli Orders storici, dai record Content Manager, dai moduli, dalle API e dall’ambiente Cloud o self-hosted. Un campo di origine è utile soltanto quando lo store di destinazione conserva l’entità che lo possiede e i record correlati che gli attribuiscono significato.
Il modello di destinazione più solido distingue Products e varianti, campi descrittivi e scelte dell’acquirente, dati master Customer e snapshot Order, contenuti e presentazione, record Gambio core e dati di moduli o sistemi esterni. Questa disciplina sulla proprietà produce un catalogo e uno storico commerciale comprensibili, non semplicemente popolati.
Domande frequenti
Qual è la differenza tra le opzioni Gambio e le Product Variants?
Le opzioni definiscono insiemi di scelta e le Product Options collegano tali scelte a un Product. Le Product Variants rappresentano combinazioni concrete e possono contenere valori commerciali specifici della combinazione. Gli store più vecchi possono invece utilizzare attributi o proprietà degli articoli, quindi versione di origine e relazioni tra tabelle sono rilevanti.
Ogni combinazione Product dell’origine deve diventare una Product Variant Gambio?
No. Una combinazione è adatta a essere rappresentata come variante quando possiede identità o valori commerciali separati, ad esempio SKU, stock, prezzo, peso, immagine o disponibilità. Personalizzazioni e specifiche descrittive appartengono in genere a strutture differenti.
In che modo i gruppi Customer di Gambio incidono sulla migrazione dei dati?
I gruppi Customer possono controllare visibilità dei Products, prezzi specifici per gruppo, prezzi graduati, trattamento fiscale o altre regole commerciali. Conservare soltanto l’etichetta del gruppo non mantiene le relazioni Product e di prezzo associate.
Un Product Gambio può appartenere a più Categories?
Sì. Gambio può collegare un Product a più Categories. Uno store di origine che duplica Products per motivi di navigazione può essere rappresentato meglio da un’unica identità Product con più assegnazioni Category.
Le voci del Content Manager Gambio sono equivalenti ai tab Product o ai blocchi del tema?
No. Le voci del Content Manager sono record di contenuto indipendenti. I tab Product appartengono ai Products, mentre blocchi del tema e impostazioni StyleEdit appartengono alla presentazione. Ognuno richiede una struttura di destinazione distinta.
Come devono essere gestiti i dati creati da moduli Gambio o integrazioni esterne?
Identificare il modulo o sistema esterno, il record core che estende e l’identificativo stabile che li collega. Le relazioni ancora attive richiedono una destinazione esplicita nello store di destinazione; i record tecnici obsoleti possono essere esclusi o archiviati senza essere trattati come dati Gambio nativi.