Gli store X-Cart contengono spesso più generazioni di logica di catalogo e di estensione. Le versioni attuali della piattaforma distinguono le Product Variations dai Product Variants legacy, mentre classi Product e attributi forniscono informazioni strutturate sul catalogo. I record Customer possono essere collegati a tipi di utente, ruoli, indirizzi, campi del profilo e membership. Gli Orders hanno stati separati per pagamento ed evasione degli ordini. I moduli possono aggiungere prezzi all’ingrosso, dati di compatibilità automotive, informazioni sui dealer, recensioni, loyalty, abbonamenti o funzionalità marketplace.
Questi livelli fanno sì che una migrazione X-Cart non possa essere ridotta a Products, Categories, Customers e Orders. Una matrice colore-taglia nel sistema di origine può richiedere le attuali Product Variations, l’interpretazione dei Product Variants legacy oppure un’altra struttura di opzioni Product. Un gruppo Customer può rappresentare prezzi di membership, accesso, imposte o limitazioni nei metodi di pagamento. Un valore di compatibilità automotive può appartenere a un modulo e a una tassonomia veicolo esterna invece che a un attributo Product generico.
La migrazione dipende quindi dalla corretta rappresentazione di proprietà e relazioni: quale entità X-Cart possiede il valore, quali altri record gli danno significato e se il valore appartiene al core, a una struttura legacy, a un modulo, alla presentazione oppure a un sistema esterno.
Il significato del catalogo X-Cart dipende dalla versione e dai moduli installati
Le strutture dati attuali e legacy di X-Cart devono essere separate prima di definire la corrispondenza dei dati. Le versioni attuali di X-Cart utilizzano Product Variations, mentre gli store più vecchi possono conservare strutture legacy Product Variant. Installazioni X-Cart mantenute per molti anni possono inoltre contenere moduli storici, codice personalizzato o strutture importate che non corrispondono a un’installazione attuale pulita.
| Evidenza nel sistema di origine | Interpretazione in X-Cart | Conseguenza per la migrazione |
|---|---|---|
| Record di varianti attuali | Product Variations e relativi dati Product | Preservare identità della variante attuale, attributi selezionati e valori commerciali. |
| Tabelle o campi di varianti legacy | Struttura legacy Product Variants | Interpretare i dati in base alla versione di origine invece di presumere lo schema attuale. |
| Record di classi Product e attributi | Informazioni Product strutturate e definizioni di attributi riutilizzabili | Mantenere appartenenza alla classe e relazioni tra attributi e valori. |
| Campi Product specifici di un modulo | Dati di estensione appartenenti al modulo | Non considerare ogni campo come parte del core X-Cart. |
| Tabelle database personalizzate | Entità o relazione personalizzata | Definire una destinazione soltanto dopo aver identificato il flusso operativo che utilizza quei dati. |
| ID di integrazioni esterne | Identificatore ERP, PIM, WMS, CRM, marketplace o automotive | Conservare le chiavi stabili necessarie per ricollegare lo store di destinazione. |
Versione di origine e inventario dei moduli non sono semplici metadati tecnici. Determinano il significato effettivo di un Product, di un’opzione, di un Customer o di un campo Order. Due store X-Cart possono usare la stessa etichetta pur memorizzando e utilizzando il valore in modi diversi.
Products, varianti, classi e attributi svolgono ruoli diversi
Un Product X-Cart contiene l’identità principale, come nome, SKU, prezzo, inventario, descrizioni, immagini, assegnazioni Category, proprietà di spedizione e fiscali e visibilità. Le Product Variations rappresentano versioni selezionabili di un Product. Classi e attributi descrivono caratteristiche strutturate e possono supportare organizzazione del catalogo, filtri, confronto o informazioni nella pagina Product.
Un’opzione Product del sistema di origine deve essere classificata in base al suo funzionamento. Se il valore selezionato identifica una combinazione gestita separatamente, con prezzo, quantità, SKU, immagine o peso propri, è più vicino a una variante. Se il valore modifica un Product senza inventario indipendente, può essere più appropriata un’altra struttura di scelta. Se il valore descrive il Product senza modificare l’articolo acquistato, appartiene agli attributi o ai contenuti.
| Struttura nel sistema di origine | Domanda da risolvere nella destinazione X-Cart | Relazione da preservare |
|---|---|---|
| SKU figlio colore-taglia | Product Variation attuale o Product Variant legacy | Identità del figlio, disponibilità, prezzo, media e valori selezionati. |
| Campo di personalizzazione | Input dell’acquirente o scelta Product appartenente a un modulo | Il valore inserito rimane collegato alla riga Order. |
| Specifica tecnica | Attributo Product sotto la classe appropriata | L’informazione strutturata resta distinta da una scelta di acquisto. |
| Prezzo all’ingrosso per quantità | Relazione di prezzo all’ingrosso del core o appartenente a un modulo | Soglie di quantità e perimetro della membership restano collegati. |
| File digitale | Relazione e-goods o file allegato, dove utilizzata | L’accesso appartiene al corretto contesto Product e Order. |
| Compatibilità automotive | Record del modulo fitment e tassonomia veicolo | La relazione tra Product e veicolo resta distinta dagli attributi generici. |
Le Product Variations attuali di X-Cart e i Product Variants legacy non devono mai essere mescolati superficialmente. Una migrazione può dover interpretare record legacy e rappresentarli nel modello attuale dello store di destinazione, ma la provenienza deve rimanere chiara per evitare duplicazione o perdita delle identità figlie e delle combinazioni di opzioni.
Categories, classi, attributi e ricerca definiscono la reperibilità dei Products
Le Categories organizzano la navigazione per gli acquirenti e l’assegnazione dei Products. Le classi Product raggruppano attributi riutilizzabili. Gli attributi contengono informazioni Product. I moduli di ricerca e filtro possono indicizzare Categories, attributi, SKU, brand, tag, dati fitment o altri valori appartenenti a estensioni. Queste strutture sono correlate, ma non intercambiabili.
Un brand rappresentato come Category nel sistema di origine potrebbe essere più adatto a un attributo X-Cart o a un modulo brand. Un albero di specifiche di origine potrebbe diventare un insieme di classi Product e attributi. Una pagina di ingresso può richiedere contenuto e navigazione anziché una Category. Un selettore di compatibilità può dipendere da record veicolo e da una relazione Product-fitment anziché da filtri ordinari.
| Elemento di reperibilità | Responsabile in X-Cart | Confine di rappresentazione |
|---|---|---|
| Gerarchia rivolta all’acquirente | Category e assegnazioni Product | La presenza della Category non ricrea automaticamente la navigazione. |
| Specifica Product | Classe e valore dell’attributo | I valori restano strutturati e collegati al corretto tipo Product. |
| Brand | Attributo o record di un modulo brand | Il significato del brand non deve essere duplicato tra Categories e campi. |
| Valore utilizzabile come filtro | Attributo o campo di indice appartenente a un modulo | Il funzionamento della ricerca dipende da valori normalizzati e indicizzazione nella destinazione. |
| Compatibilità veicolo | Record automotive fitment | Il fitment richiede tassonomia veicolo e chiavi di relazione, non testo libero. |
| Product correlato | Relazione Product del core o appartenente a un modulo | I collegamenti di merchandising restano distinti dall’appartenenza a una Category. |
Questo modello impedisce di appiattire la logica di reperibilità nelle descrizioni Product. Una descrizione migrata può mostrare specifiche, ma non può sostituire attributi strutturati, fitment, confronti o relazioni di filtro.
Customers, tipi di utente, ruoli, campi del profilo e membership sono elementi separati
La gestione utenti di X-Cart può includere amministratori, Customers e venditori; ruoli e autorizzazioni; account Customer e indirizzi; campi del profilo personalizzati; e livelli di membership. Le membership possono influire sull’accesso a Products e Categories, sui prezzi Product, sulle quantità minime, sugli sconti, sui coupon, sulle offerte speciali, sulle imposte o sui metodi di pagamento.
Un segmento Customer nel sistema di origine deve quindi essere interpretato in base alla funzione. Stati come all’ingrosso, dealer, VIP, dipendente, esente da imposte, acquirente approvato, loyalty o abbonamento potrebbero non appartenere a un’unica membership generica. Alcuni valori sono informazioni di identità, alcuni sono regole di accesso commerciale, altri appartengono a moduli e altri ancora sono classificazioni di CRM o ERP esterni.
| Significato dell’account nel sistema di origine | Responsabile X-Cart da considerare | Relazione da mantenere |
|---|---|---|
| Acquirente individuale | Account Customer e rubrica indirizzi | Identità, accesso, indirizzi e Orders restano collegati. |
| Utente amministrativo | Tipo utente amministratore e ruolo | Le autorizzazioni restano separate dalla segmentazione Customer. |
| Utente venditore marketplace | Utente vendor e relazione organizzativa appartenente al modulo | L’utente appartiene al corretto venditore o alla corretta entità marketplace. |
| Livello di prezzo o accesso | Livello di membership e relative regole commerciali | La membership influisce sui Products, prezzi, imposte o metodi previsti. |
| Informazioni Customer aggiuntive | Campo del profilo o identificatore esterno | Finalità del campo e requisiti di privacy restano espliciti. |
| Account aziendale esterno | Struttura personalizzata/di modulo o chiave di sistema esterno | Quando necessario, più acquirenti restano associati all’azienda autorevole. |
Anche la cronologia delle membership è diversa dall’assegnazione corrente. Un Order storico deve mantenere prezzo, sconto, imposte ed evidenze di pagamento registrati al momento dell’acquisto; non deve essere ricalcolato in base alla membership attuale del Customer dopo la migrazione.
Gli Orders utilizzano relazioni commerciali e di evasione degli ordini separate
Gli Orders X-Cart possono includere identità Customer registrata o cliente non registrato, indirizzi, riferimenti Product e variante, attributi selezionati, quantità, prezzi, sconti, imposte, stato di pagamento, stato di evasione degli ordini, spedizioni, transazioni, resi, note, fatture e record appartenenti a moduli. X-Cart separa lo stato del pagamento da quello di evasione, quindi un unico stato Order generico nel sistema di origine può non contenere informazioni sufficienti.
| Elemento Order nel sistema di origine | Relazione X-Cart | Significato storico |
|---|---|---|
| Riga Order | Snapshot di Product o variante, SKU, quantità, prezzo e scelte selezionate | Spiega esattamente cosa è stato acquistato. |
| Stato di pagamento | Stato di pagamento e record delle transazioni | Separa l’avanzamento finanziario da quello dell’evasione degli ordini. |
| Stato di evasione | Stato di evasione, spedizione e tracking | Spiega cosa è stato spedito o cosa rimane aperto. |
| Reso o rimborso | Record del modulo resi, importo rimborsato e righe interessate quando disponibili | Conserva la cronologia post-vendita. |
| Indirizzo Customer | Snapshot di fatturazione e spedizione al momento dell’Order | L’indirizzo storico non deve essere sovrascritto dalla rubrica corrente. |
| Dati appartenenti a moduli | Contesto di abbonamento, marketplace, loyalty, fitment o integrazione esterna | L’Order può dipendere da record esterni alle tabelle Order del core. |
Uno stato di origine come complete, processing, shipped, partially refunded o canceled può combinare significato di pagamento e di evasione. La migrazione deve preservare le evidenze invece di forzare l’etichetta in un unico campo. Configurazione corrente di pagamenti, spedizioni, imposte e notifiche rimane separata dagli Orders storici.
Contenuti, pagine statiche, URL e presentazione della vetrina hanno responsabili diversi
I dati della vetrina X-Cart possono includere descrizioni Product e Category, Pages statiche, menu, immagini, video, tab Product personalizzate, banner, blocchi di layout, temi, metadati, clean URL, redirect e valori linguistici. Questi elementi devono essere separati in base alla proprietà di contenuto, routing e presentazione.
Le descrizioni Product appartengono ai Products. Le Pages statiche hanno identità e route proprie. Le tab Product personalizzate possono appartenere a un modulo. Menu e blocchi di layout controllano il posizionamento. Temi e template definiscono la presentazione. Metadati SEO e redirect proteggono le relazioni tra percorsi. Una vetrina headless o fortemente personalizzata può mantenere contenuti aggiuntivi fuori dal core X-Cart.
| Risorsa nel sistema di origine | Livello di destinazione X-Cart | Significato da preservare |
|---|---|---|
| Descrizione Product o Category | Contenuto del catalogo | Il testo resta collegato all’entità e alla lingua corrette. |
| Pagina informativa statica | Record Page | Contenuto, route, gerarchia e visibilità restano distinti. |
| Tab Product personalizzata | Relazione di contenuto Product appartenente a un modulo | Posizionamento della tab e assegnazione Product restano collegati. |
| Banner o blocco della homepage | Configurazione di presentazione o record di modulo | Il posizionamento visivo non è implicito nella migrazione del contenuto. |
| URL legacy | Struttura clean URL e redirect | Vecchio percorso e destinazione nello store di destinazione restano espliciti. |
| Personalizzazione del tema | Implementazione della presentazione di destinazione | Il codice del template non è normale dato CMS. |
Questo modello di proprietà evita un errore di classificazione comune: trattare ogni elemento visibile nella vetrina come contenuto trasferibile. Alcuni elementi visibili sono generati da Products e Categories, altri sono Pages separate e altri ancora esistono soltanto perché un modulo o un tema li renderizza.
I moduli X-Cart possono possedere dati di catalogo, Customer e Order
I moduli X-Cart possono introdurre campi ed entità per prezzi all’ingrosso, loyalty, abbonamenti, recensioni, allegati Product, tab personalizzate, fitment automotive, dealer, venditori marketplace, resi, social login, servizi fiscali, servizi di pagamento, integrazioni di spedizione e flussi dati esterni. I record dei moduli possono dipendere da impostazioni, processi pianificati, credenziali API o tassonomie esterne.
La domanda centrale per la migrazione non è se il nome di un modulo esista nello store di destinazione. È se i record e le relazioni siano ancora necessari e se la piattaforma di destinazione disponga di una struttura in grado di interpretarli.
| Proprietario dei dati | Record di esempio | Implicazione per il perimetro |
|---|---|---|
| Core X-Cart | Products, Categories, classi, attributi, utenti, Orders, Pages | Rappresentare attraverso le relazioni dati native. |
| Modulo X-Cart | Prezzi di membership, fitment, sedi dealer, recensioni, loyalty, abbonamenti | Esaminare lo schema del modulo e i collegamenti con i record core. |
| Codice personalizzato | Campi, tabelle, stati o flussi operativi su misura | Definire deliberatamente una destinazione o una decisione di archiviazione. |
| Servizio esterno | Pagamenti, imposte, spedizioni, ricerca, marketplace, strumenti di analisi | Conservare i riferimenti necessari a riconciliare sistemi storici e attivi. |
| ERP/PIM/WMS/CRM | Identificatori principali di Product, Customer, stock e Order | Mantenere chiavi stabili per ricollegamento e proprietà. |
I dati automotive mostrano bene questa distinzione. Anno, marca, modello, motore, allestimento, tipo di compatibilità e sede dealer possono sembrare attributi Product, ma la compatibilità operativa dipende da tassonomie veicolo condivise e da relazioni Product-veicolo. Appiattirli in testo può conservare le parole distruggendo però ricerca e manutenzione del fitment.
I formati Data Transfer non definiscono l’intero modello X-Cart
Le funzioni di importazione ed esportazione di X-Cart possono gestire Products, Categories, attributi, utenti, Orders, inventario, recensioni e alcuni record di moduli. Un campo CSV conferma che un dato può essere rappresentato in un formato di trasferimento; non dimostra che tutte le relazioni circostanti, le impostazioni del modulo o le dipendenze esterne siano incluse.
Per esempio, importare il valore di un attributo non ricrea automaticamente la sua classe Product e il funzionamento di visualizzazione. Importare un Customer non configura prezzi specifici per membership se membership e regole correlate non esistono. Importare un Order non ricrea i metodi di pagamento o spedizione correnti. Importare un ID fitment non ha significato se manca la tassonomia veicolo a cui fa riferimento.
| Evidenza di trasferimento | Relazione aggiuntiva da identificare |
|---|---|
| Riga Product | Category, classe, attributi, variante, media, stock e collegamenti ai moduli. |
| Valore attributo | Definizione attributo, assegnazione alla classe, tipo di input e relazione Product. |
| Riga Customer | Tipo di utente, indirizzi, campi del profilo, membership e identità esterna. |
| Riga Order | Righe, stati, transazioni, spedizioni, resi e snapshot storici. |
| CSV del modulo | Modulo installato, tabelle di riferimento, configurazione e tassonomia esterna. |
| Campo ID esterno | Sistema autorevole, regola di unicità e processo di ricollegamento. |
Il piano di migrazione deve seguire le relazioni tra dati, non la forma di un singolo file di esportazione. Questo è particolarmente importante negli store X-Cart più vecchi, i cui dati possono essere passati attraverso aggiornamenti, importazioni personalizzate o sostituzioni di moduli.
Decisioni di rappresentazione in X-Cart in base al significato aziendale
| Struttura nel sistema di origine | Domanda corretta da risolvere | Conseguenza di un’ipotesi errata |
|---|---|---|
| Combinazioni figlie attuali o legacy | Il sistema di origine usa Product Variations attuali, Product Variants legacy o logica di opzioni personalizzata? | SKU figlio, stock, prezzo o valori selezionati vengono duplicati o persi. |
| Specifiche tecniche | Appartengono a classi Product e attributi? | Filtri, confronto e governance del catalogo diventano inaffidabili. |
| Segmento all’ingrosso o dealer | Il significato è una membership, dati aziendali appartenenti a un modulo o una classificazione CRM esterna? | Prezzi e accesso vengono associati al livello di identità sbagliato. |
| Stato Order combinato | Come devono essere separate le evidenze di pagamento ed evasione degli ordini? | Lo stato finanziario o di spedizione storico diventa fuorviante. |
| Compatibilità automotive | Quale modulo e quale tassonomia veicolo possiedono la relazione? | Ricerca e manutenzione fitment scompaiono anche se i valori testuali vengono migrati. |
| Tab o campo personalizzato | È contenuto core, dato di modulo o presentazione del tema? | Il dato arriva senza la struttura di vetrina che lo utilizza. |
| Chiave ERP o marketplace | Quale sistema è autorevole e quale record identifica la chiave? | Il record migrato non può essere riconciliato o sincronizzato. |
La migrazione X-Cart preserva il significato quando la generazione della versione, le strutture e categorie dati del core, i moduli e i sistemi esterni vengono trattati come domini di proprietà distinti. Questo approccio consente di ottenere uno store di destinazione in cui scelte Product, trattamento dei Customers, Orders storici, contenuti e integrazioni restano comprensibili invece di essere semplicemente presenti.
Conclusione
La rappresentazione del modello dati X-Cart dipende da versione di origine, struttura del catalogo, relazioni degli utenti, semantica degli Orders, moduli e sistemi esterni. Le Product Variations attuali devono essere distinte dai Product Variants legacy. Classi Product e attributi devono rimanere separati dalle scelte di acquisto. Le membership possono governare prezzi, accesso, imposte e relazioni con i pagamenti. Gli Orders richiedono contesti distinti per pagamento, evasione, transazioni, spedizioni e resi. I moduli possono possedere record quali prezzi all’ingrosso, fitment, dealer, loyalty, abbonamenti e dati marketplace.
Un perimetro di migrazione solido assegna ogni valore di origine all’entità o al modulo X-Cart che possiede lo stesso significato aziendale e mantiene identificatori stabili tra sistemi collegati. In questo modo si evita la falsa sicurezza di un trasferimento campo per campo e si ottiene uno store di destinazione il cui catalogo e la cui cronologia commerciale restano utilizzabili.
Domande frequenti
Qual è la differenza tra le attuali X-Cart Product Variations e i Product Variants legacy?
Appartengono a generazioni diverse della struttura catalogo X-Cart. Le versioni attuali usano Product Variations, mentre gli store più vecchi possono contenere ancora record Product Variant legacy. Prima di rappresentare le combinazioni nello store di destinazione è necessario identificare versione di origine e relazioni tra tabelle.
Ogni opzione Product di origine dovrebbe diventare una X-Cart Product Variation?
No. Un valore è adatto a una variante quando identifica una combinazione gestita separatamente con valori commerciali propri. Personalizzazione, servizi regalo o specifiche descrittive possono appartenere a un’altra struttura di scelta Product, a un attributo o a un campo gestito da un modulo.
In che modo classi Product e attributi X-Cart influenzano la migrazione?
Le classi raggruppano definizioni di attributi riutilizzabili, mentre i valori degli attributi descrivono singoli Products. Preservare soltanto i valori senza le relazioni con classe e definizione indebolisce governance del catalogo, filtri, confronto e struttura delle pagine Product.
Un gruppo Customer di origine può sempre diventare una membership X-Cart?
No. Una membership è appropriata quando governa un funzionamento commerciale o di accesso in X-Cart. Segmenti marketing, relazioni aziendali, stato loyalty, indicatori fiscali e classificazioni CRM esterne possono richiedere destinazioni diverse.
Perché i dati di compatibilità automotive devono essere gestiti separatamente dagli attributi Product ordinari?
Il fitment dipende normalmente da record veicolo condivisi e da relazioni Product-veicolo. Valori liberi per anno, marca e modello non preservano tassonomia e chiavi di relazione necessarie per una ricerca di compatibilità accurata e per la relativa manutenzione.
Cosa dovrebbe accadere ai record appartenenti a un modulo X-Cart o a una tabella personalizzata?
È necessario identificare modulo o flusso personalizzato, record core estesi e qualsiasi tassonomia o identificatore esterno utilizzato. Le relazioni ancora attive richiedono una destinazione esplicita nello store di destinazione; i dati obsoleti possono essere archiviati o esclusi senza classificarli erroneamente come dati nativi Product, Customer o Order.