CS-Cart rappresenta l’e-commerce attraverso relazioni che possono essere facilmente appiattite in modo errato. I Products possono includere features, filters, options, eccezioni delle options e variations Product. Categories e Products possono appartenere ad ambiti di vetrina differenti. Le edizioni Multi-Vendor aggiungono vendor, amministratori vendor, Products di proprietà dei venditori, Orders del marketplace, commissioni e contesto dei pagamenti. I gruppi Customer possono influenzare prezzi, accesso e promozioni. Le estensioni della piattaforma possono introdurre record che non appartengono affatto al catalogo principale.
Queste differenze contano perché etichette simili nella fonte non garantiscono lo stesso funzionamento. Un campo “colore” può essere una feature descrittiva, un valore usato per il filtraggio, una option che modifica il prezzo oppure una feature usata per generare variations Product separate. Uno store di origine può tradursi in una vetrina CS-Cart indipendente, in una filiale regionale del marketplace oppure semplicemente in una presentazione localizzata. Un supplier può essere un riferimento interno in un sistema e un vendor marketplace con proprietà di Products e Orders in un altro.
La migrazione verso CS-Cart richiede quindi di tradurre correttamente proprietà delle entità e relazioni. L’obiettivo è preservare che cosa ogni record significa per catalogo, vetrina, venditore, Customer, Order e sistemi collegati, non soltanto riprodurre nomi di campi.
CS-Cart separa fatti di catalogo, scelte di acquisto e variations vendibili
CS-Cart usa strutture diverse per i fatti relativi ai Products e per le scelte effettuate sul Product. Le features sono proprietà inseparabili del Product, come brand, materiale, ISBN o specifiche tecniche. Possono essere raggruppate e utilizzate per confronto, filtraggio o organizzazione del catalogo. Le options sono scelte separabili effettuate dall’acquirente, come incisione, confezione regalo o garanzia; non possiedono stock indipendente ma possono influenzare prezzo o peso. Le variations Product sono Products raggruppati in base a valori feature selezionati e ogni variation resta un Product con una propria identità commerciale.
| Valore della fonte | Responsabile in CS-Cart | Significato che deve restare distinto |
|---|---|---|
| Specifica tecnica | Product feature o feature group | Descrive il Product e può supportare filtraggio o confronto. |
| Configurazione Product scelta dall’acquirente | Product option e option variant | Modifica la configurazione acquistata senza diventare stock indipendente. |
| SKU figlio colore/taglia | Product variation all’interno di un variation group | Resta un Product e può avere SKU, prezzo, stock, immagine e visibilità di catalogo propri. |
| Combinazione di scelta non consentita | Option exception o regola di disponibilità della variation | Impedisce configurazioni non valide anziché creare un nuovo valore attributo. |
| Scelta di merchandising riutilizzabile | Global option o struttura simile a un template | Una definizione può essere assegnata a più Products. |
| Facet di ricerca | Filter basato su features o altri valori supportati | Richiede valori normalizzati e relazioni Category corrette. |
La distinzione tra variations e articoli di catalogo è particolarmente importante. Ogni variation è un Product, ma può o meno occupare una propria posizione visibile negli elenchi Product. Un catalogo di origine che espone ogni SKU figlio come Product separato può richiedere più articoli di catalogo visibili; un altro catalogo può mostrare un unico parent mantenendo la maggior parte delle scelte di variation all’interno della pagina Product.
Una migrazione che mappa tutte le options della fonte in features CS-Cart perde il funzionamento di acquisto. Mappare tutte le specifiche in options crea scelte di acquisto non necessarie. Comprimere tutti gli SKU figli in un singolo Product può eliminare identità e inventario indipendenti. La struttura corretta dipende da ciò che il valore della fonte controlla realmente.
Products, Categories, features e filters formano il modello di scoperta
Un Product CS-Cart include campi commerciali principali, immagini, prezzo, quantità, stato, informazioni di spedizione e fiscali, descrizioni, Categories, features, options, file e valori gestiti da estensioni. Le Categories forniscono gerarchia e ambito della vetrina; le features forniscono fatti strutturati; i filters espongono valori selezionati per la scoperta dei Products.
Una Category nella fonte può rappresentare navigazione, una landing page SEO, un brand, una classificazione tecnica o un raggruppamento interno. Questi significati non devono restare automaticamente Categories. Un brand memorizzato come Category nella fonte può essere più adatto a una brand feature CS-Cart. Un albero di specifiche usato per la navigazione a faccette può richiedere feature groups e filters. Una landing page di merchandising può richiedere contenuti e blocchi oltre alle assegnazioni Product.
| Struttura di scoperta nella fonte | Domanda di traduzione verso CS-Cart | Conseguenza sulla relazione |
|---|---|---|
| Gerarchia Category | Quali Categories restano visibili agli acquirenti e quali sono interne? | Assegnazione Product e proprietà della vetrina dipendono dalla risposta. |
| Categories di brand | Il brand dovrebbe diventare una Product feature? | Il brand può supportare filtraggio e confronto senza duplicare la navigazione. |
| Valori facet | Sono features normalizzate, options o campi personalizzati di un’estensione? | Solo il responsabile corretto può supportare filters coerenti. |
| Products in più Categories | Quali Categories e vetrine devono esporre ogni Product? | Un Product può essere presente ma assente da un percorso di acquisto importante. |
| File Product | Sono download, allegati, manuali o record di un’estensione? | La proprietà del file determina accesso e significato a livello di riga Order. |
I codici Product di CS-Cart sono identificatori ma non sono intrinsecamente garantiti come univoci. Quando lo store di origine dipende dall’unicità dello SKU per corrispondenze con ERP, magazzino o marketplace, la relazione con l’identificatore esterno deve essere esplicita anziché dedotta dalla sola etichetta della piattaforma.
Le vetrine cambiano l’ambito di Products, Categories, Customers e configurazione
Il funzionamento delle vetrine CS-Cart varia in base all’edizione. In Store Builder Ultimate, le vetrine possono operare come store indipendenti con Products, Categories, impostazioni, base utenti e meccanismi del processo di acquisto propri. In Multi-Vendor Ultimate, le vetrine possono rappresentare filiali regionali del marketplace con vendor selezionati, valute, lingue, metodi di pagamento, metodi di spedizione, temi, layout e blocchi propri.
Questa differenza significa che “store” non è un’unità universale da trasferire uno-a-uno dalla fonte alla destinazione. Lo stesso Product può appartenere a una vetrina, apparire in più vetrine tramite assegnazioni Category oppure seguire la visibilità del vendor tra filiali del marketplace. Le Categories possono appartenere a una vetrina oppure avere un ambito più ampio nei contesti marketplace. Anche account Customer e amministratori possono essere globali o specifici della vetrina, a seconda della configurazione.
| Contesto della fonte | Interpretazione Store Builder | Interpretazione Multi-Vendor |
|---|---|---|
| Store di brand o regionale | Vetrina indipendente con catalogo e impostazioni propri | Filiale marketplace con vendor selezionati e configurazione regionale. |
| Proprietà Product | Product della vetrina che può apparire tramite Categories assegnate | Product di proprietà del vendor visibile dove il vendor partecipa. |
| Prezzo Product | Può differire per vetrina | Normalmente segue il Product del vendor tra filiali, salvo l’applicazione di un’altra struttura di prezzo. |
| Category | Appartiene a una vetrina specifica | Può essere globale o associata a una vetrina specifica. |
| Base Customer | Può essere separata per vetrina | Può essere condivisa o circoscritta in base al design del marketplace. |
| Amministratore | Relazione amministrativa specifica della vetrina | Amministratori marketplace e amministratori vendor hanno proprietà differenti. |
L’ambito della migrazione deve quindi identificare se le differenze tra vetrine della fonte appartengono ai dati, alla configurazione o a operazioni indipendenti. Impostazioni di localizzazione, valuta, pagamento, spedizione, tema e processo di acquisto non sostituiscono la proprietà di Products e Categories. Un record può essere migrato correttamente e comparire comunque nella vetrina sbagliata se manca la relazione di ambito.
Vendor e Common Products aggiungono proprietà marketplace
CS-Cart Multi-Vendor introduce il vendor come responsabile commerciale, non come semplice etichetta manufacturer. I vendor possono avere amministratori, Products, partecipazione alle vetrine, righe Order, metodi di spedizione, piani, commissioni, saldi, pagamenti e dati del profilo. Un campo supplier della fonte dovrebbe diventare vendor soltanto quando quell’organizzazione possiede realmente attività marketplace.
Alcune implementazioni marketplace usano anche Common Products o concetti di catalogo condiviso. Un Common Product può fornire un’identità di catalogo condivisa mentre le offerte vendor contengono informazioni commerciali specifiche del venditore. Questo è diverso sia dal copiare lo stesso Product in più cataloghi vendor sia da avere un unico Product di proprietà dello store con metadati supplier.
| Relazione della fonte | Destinazione marketplace CS-Cart | Significato da preservare |
|---|---|---|
| Manufacturer o brand | Product feature, valore simile a manufacturer o dati brand | Origine descrittiva senza proprietà venditore. |
| Riferimento supplier | Campo interno o identificatore esterno | Approvvigionamento operativo senza comportamento da account marketplace. |
| Venditore marketplace | Record vendor | Proprietà di Products, righe Order, commissioni e pagamenti. |
| Amministratore venditore | Utente vendor o relazione amministrativa | L’accesso appartiene al vendor corretto. |
| Articolo di catalogo condiviso con offerte venditore | Common Product più dati offerta specifici del vendor dove utilizzati | L’identità condivisa resta separata da prezzo e stock del venditore. |
| Order marketplace | Parent Order e contesto Order o riga collegato al vendor | Responsabilità venditore e regolamento restano interpretabili. |
La migrazione dei vendor è incompleta se i Products dei venditori arrivano senza proprietà vendor oppure se gli account vendor arrivano senza Products, amministratori, contesto Order e identificatori esterni. Al contrario, trasformare ogni supplier della fonte in un vendor crea relazioni marketplace che non esistevano.
Customers, gruppi utenti e segmentazione commerciale
Gli utenti CS-Cart possono includere Customers, amministratori e utenti vendor. I gruppi Customer possono influenzare prezzi Product, sconti, trattamento fiscale, metodi di pagamento, metodi di spedizione e accesso a Products o Categories. Campi profilo e indirizzi contengono ulteriori informazioni Customer, mentre sistemi esterni possono possedere numeri account, stato del credito o relazioni aziendali.
Un’etichetta Customer della fonte deve essere interpretata per funzione. Stati wholesale, VIP, dealer, staff, tax-exempt, distributor o subscription possono mappare a un gruppo utenti CS-Cart solo quando il gruppo è il responsabile corretto di quel funzionamento. Un account aziendale con più acquirenti può richiedere una struttura diversa o un’estensione della piattaforma. Un segmento CRM usato soltanto per marketing non dovrebbe diventare automaticamente un gruppo prezzi.
| Significato Customer nella fonte | Responsabile CS-Cart da valutare | Relazione chiave |
|---|---|---|
| Acquirente individuale | Utente Customer e indirizzi | Identità, login, indirizzi e Orders restano collegati. |
| Fascia di prezzo | Gruppo utenti e relazione con i prezzi Product | L’appartenenza Customer influenza i valori commerciali previsti. |
| Segmento di accesso | Gruppo utenti e restrizione Product/Category | La visibilità resta distinta dall’etichettatura descrittiva. |
| Dipendente vendor | Relazione utente vendor | L’utente appartiene al venditore corretto, non alla popolazione Customer. |
| Account aziendale esterno | Dati profilo personalizzati, estensione della piattaforma o identificatore esterno | Gli acquirenti restano collegati all’organizzazione autorevole dove necessario. |
Cronologia Orders e segmentazione Customer devono restare separate. Un Order storico può registrare prezzo e imposta applicati al momento dell’acquisto; non deve essere ricalcolato in base al gruppo Customer attuale dopo la migrazione.
Gli Orders preservano snapshot marketplace e commerciali
Un Order CS-Cart può includere identità Customer o cliente non registrato, indirizzi, riferimenti Product e variation, selezioni di options, quantità, prezzi, sconti, imposte, spedizione, etichette di pagamento, stati, note, file, promozioni e proprietà marketplace. Nei contesti Multi-Vendor, strutture Order legate ai venditori e commissioni aggiungono un ulteriore livello.
Le righe Order sono snapshot storici. Il nome Product, prezzo, stock, valori feature o vendor attuali di una variation possono cambiare successivamente. L’Order deve comunque spiegare che cosa il Customer ha acquistato. Allo stesso modo, etichette storiche di pagamento e spedizione devono restare leggibili anche quando i metodi correnti del processo di acquisto sono configurazione dello store di destinazione.
| Elemento Order | Relazione storica da mantenere |
|---|---|
| Riga Product | Identità Product o variation, codice, quantità, prezzo e options scelte. |
| Promozione | Importo sconto e regola di origine o contesto Coupon, quando disponibile. |
| Imposta | Importo fiscale applicato ed etichetta al momento dell’acquisto. |
| Spedizione | Corriere, metodo, tracking, quantità evasa e contesto venditore, quando disponibile. |
| Pagamento | Etichetta del metodo storico e riferimento della transazione, quando disponibile. |
| Contesto vendor | Proprietà venditore, commissione, pagamento o relazione Order vendor. |
| Stato | Significato del ciclo di vita della fonte usato dai team di assistenza, evasione degli ordini e reportistica. |
Lo store di destinazione non deve riprodurre ogni flusso obsoleto per preservare la cronologia, ma l’Order importato deve restare comprensibile. Un record che mostra un totale senza configurazione Product, venditore, sconto, imposta e contesto dello stato non equivale alla cronologia commerciale della fonte.
Contenuti, lingue, URL e presentazione della vetrina
I contenuti della vetrina CS-Cart possono includere Pages, record Blog dove installati, descrizioni Product e Category, banner, menu, blocchi, layout, temi, metadati, SEO names e valori specifici per lingua. Queste risorse hanno responsabili differenti e non devono essere compresse in un’unica entità generica di contenuto.
Le descrizioni Product e Category appartengono al catalogo. Pages e navigazione hanno una propria gerarchia e un proprio ambito di vetrina. Blocchi e layout descrivono la presentazione. SEO names e redirect governano i percorsi. I valori linguistici possono essere memorizzati come traduzioni associate a un’entità condivisa anziché come Products o Categories indipendenti.
| Risorsa della fonte | Livello di destinazione CS-Cart | Confine da preservare |
|---|---|---|
| Traduzione Product o Category | Valore di catalogo specifico per lingua | Un’entità resta collegata a più valori localizzati. |
| Pagina informativa | Gerarchia Page e assegnazione alla vetrina | Contenuto, relazione parent, accesso e percorso restano distinti. |
| Voce menu o navigazione | Struttura menu o blocco della vetrina | La navigazione non viene dedotta dalla sola esistenza della Category. |
| Banner o blocco promozionale | Record di presentazione o marketing | Il posizionamento visivo resta separato dai dati Product sottostanti. |
| URL legacy | SEO name e relazione di redirect | Percorso della fonte e destinazione restano espliciti. |
| Layout del tema | Configurazione di presentazione della destinazione | La struttura del tema non deve essere confusa con dati di contenuto portabili. |
Questa separazione è importante negli ambienti multi-store e marketplace, dove lo stesso contenuto può essere globale, specifico della vetrina, specifico del vendor o specifico della lingua.
Estensioni CS-Cart, tabelle personalizzate e integrazioni possiedono dati aggiuntivi
Le estensioni della piattaforma CS-Cart possono aggiungere campi Product, funzionamento marketplace, record fedeltà, abbonamenti, prenotazioni, Reviews, reward points, dati di pagamento o spedizione, flussi dati esterni e flussi personalizzati. I loro record possono risiedere in tabelle specifiche dell’estensione e dipendere da hook, impostazioni, attività pianificate o servizi esterni.
In CS-Cart, un’extension è un’estensione della piattaforma e non un’etichetta generica per normali campi Product. L’ambito della migrazione deve identificare l’estensione, le sue entità e i record principali che estende.
| Responsabile dei dati | Record tipici | Requisito di traduzione |
|---|---|---|
| Core CS-Cart | Products, Categories, features, options, variations, utenti, Orders, vetrine | Preservare semantica delle entità native e delle relazioni. |
| Livello Multi-Vendor | Vendor, utenti vendor, Products dei venditori, commissioni, pagamenti | Mantenere collegata la proprietà venditore tra catalogo e Orders. |
| Estensione della piattaforma CS-Cart | Reviews, rewards, abbonamenti, dati di prenotazione, campi Product speciali | Esaminare separatamente schema dell’estensione e capacità della destinazione. |
| Sviluppo personalizzato | Tabelle, campi, stati o record di flussi di lavoro su misura | Definire una destinazione esplicita per ogni relazione aziendale attiva. |
| Sistema esterno | Articolo ERP, account CRM, magazzino, listing marketplace, riferimento contabile | Preservare gli identificatori necessari per riconciliazione e riconnessione. |
I formati di import/export non definiscono l’intero modello dati. Un campo può essere esportabile senza portare con sé la configurazione o il flusso di lavoro correlato dell’estensione. Al contrario, un identificatore esterno può essere piccolo in termini di volume ma essenziale per collegare il record migrato a dati ERP, PIM, WMS, CRM o marketplace.
Decisioni di traduzione CS-Cart basate sulle relazioni
Una mappatura CS-Cart affidabile risolve il responsabile di ogni valore della fonte prima di decidere il campo di destinazione.
| Pattern della fonte | Domanda di traduzione | Conseguenza di un responsabile errato |
|---|---|---|
| Colore e taglia con SKU figli | Si tratta di un variation group basato su features? | Si perdono identità Product indipendente, stock o visibilità di catalogo. |
| Incisione o confezione regalo | Si tratta di una option senza stock indipendente? | Una scelta di servizio viene rappresentata erroneamente come variation vendibile. |
| Specifica tecnica | Si tratta di una feature e forse di un filter? | Scoperta e confronto diventano incoerenti. |
| Più store regionali | Sono vetrine indipendenti o filiali marketplace? | Ambito di Products, Categories, Customers e configurazione viene mescolato. |
| Fornitore o venditore | È approvvigionamento descrittivo o proprietà vendor? | Products, utenti, Orders, commissioni e pagamenti vendor vengono persi o inventati. |
| Fascia Customer | È un gruppo utenti, un segmento CRM esterno o una relazione aziendale? | Prezzi e comportamento di accesso vengono collegati alla struttura Customer sbagliata. |
| Campo di estensione | Quale modulo CS-Cart lo possiede e quale record estende? | I dati vengono copiati senza la capacità che li interpreta. |
La migrazione verso CS-Cart preserva il significato quando fatti di catalogo, scelte di acquisto, variations, ambito delle vetrine, proprietà vendor, segmentazione Customer, cronologia Orders, contenuti e record delle estensioni restano distinti ma collegati.
Conclusione
CS-Cart non è uno schema piatto di Products e Orders. Le features descrivono Products; le options rappresentano scelte separabili; le variations restano Products raggruppati in base a features selezionate. Le vetrine possono possedere catalogo e ambito Customer in modo diverso tra le edizioni Store Builder e Multi-Vendor. I vendor introducono proprietà marketplace, mentre i gruppi utenti influenzano il trattamento commerciale. Gli Orders dipendono dal contesto storico di righe, promozioni, imposte, pagamento, spedizione, stato e venditore. Estensioni della piattaforma e sistemi esterni possono possedere record al di fuori dei Data Types principali.
L’ambito di migrazione più solido assegna ogni valore della fonte alla struttura CS-Cart che controlla lo stesso significato aziendale. In questo modo vengono protetti scoperta dei Products, scelte di acquisto, responsabilità dei venditori, trattamento dei Customers, Orders storici, vetrine localizzate e continuità delle integrazioni senza forzare record diversi in campi solo superficialmente simili.
Domande frequenti
Qual è la differenza tra una feature e una option CS-Cart?
Una feature è una proprietà inseparabile del Product, come brand, materiale o ISBN, e può supportare filtraggio o confronto. Una option è una scelta separabile dell’acquirente, come incisione, confezione regalo o garanzia; può influenzare prezzo o peso ma non possiede stock indipendente.
Quando gli SKU figli della fonte dovrebbero diventare Product variations CS-Cart?
Sono adatti alle Product variations quando ogni figlio resta un Product e il gruppo differisce attraverso valori feature selezionati. La mappatura deve preservare SKU figlio, stock, prezzo, immagine e relazioni di visibilità nel catalogo anziché combinare i figli in un unico elenco piatto di options.
Uno store di origine può sempre diventare una sola vetrina CS-Cart?
No. In Store Builder, una vetrina può essere uno store indipendente con catalogo e Customers propri. In Multi-Vendor, una vetrina può essere una filiale regionale del marketplace con vendor selezionati e configurazione regionale. Il confine operativo della fonte determina il modello corretto.
Ogni supplier della fonte dovrebbe diventare un vendor CS-Cart?
No. Un vendor possiede Products marketplace e record commerciali collegati al venditore. Un manufacturer, brand, codice supplier o fonte di approvvigionamento può restare un dato descrittivo o di sistema esterno quando non rappresenta un account venditore.
Perché i dati delle estensioni CS-Cart devono essere separati dai dati core?
Un’estensione della piattaforma può possedere tabelle, stati, configurazione e relazioni propri. Copiare i suoi campi in un record Product o Customer core non preserva il flusso di lavoro che interpreta quei campi.
Come devono essere tradotti i record di catalogo condiviso in un marketplace?
Separare l’identità Product condivisa da offerte, prezzo, stock, proprietà e responsabilità Order specifici del vendor. Che lo store di destinazione utilizzi Common Products o un’altra struttura marketplace, questi livelli non devono essere compressi in Products duplicati e scollegati.