Se CS-Cart viene scelto come piattaforma di destinazione, la preparazione deve iniziare identificando se il modello operativo previsto sarà un ambiente Store Builder gestito dall’azienda oppure un marketplace Multi-Vendor. Entrambi utilizzano strutture di catalogo correlate, ma la preparazione per un marketplace aggiunge proprietà vendor, amministratori vendor, Products e Orders specifici dei venditori, commissioni, record contabili, prelievi, autorizzazioni delle vetrine e flussi finanziari dipendenti dalle estensioni.
L’obiettivo è preparare le evidenze della fonte prima di finalizzare la configurazione della migrazione. Ogni area principale deve indicare azione, responsabile, evidenza e condizione di prontezza. Product options, features e variations devono restare distinte; l’ambito delle vetrine deve essere esplicito; i record vendor non devono essere ridotti ad account Customer; e gli Orders storici devono preservare contesto del venditore e contesto finanziario.
Confermare edizione, versione, vetrine e accesso di CS-Cart
Registrare l’esatta edizione CS-Cart o Multi-Vendor, la versione, il percorso di installazione, il database, le vetrine attive, le aziende o i vendor, le lingue, le valute, i temi, le estensioni della piattaforma e le sincronizzazioni esterne. Installazioni di lunga durata possono includere strutture Product variation aggiornate, estensioni ritirate, template personalizzati o modifiche al database che cambiano i record disponibili nella fonte.
Preparare l’accesso alla fonte richiesto dal percorso di migrazione selezionato. Il responsabile tecnico deve confermare database corretto, struttura dei file, ambiente amministrativo ed eventuali restrizioni di accesso. Per Multi-Vendor, identificare anche l’amministratore del marketplace e le persone che comprendono relazioni vendor e record contabili.
| Azione | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Confermare edizione e versione | Responsabile tecnico | Evidenza di versione e licenza/edizione | Le ipotesi Store Builder e Multi-Vendor non sono mescolate. |
| Registrare l’ambito delle vetrine | Responsabile commerciale | Elenco vetrine, domini, lingue, valute, assegnazioni azienda | Ogni vetrina attiva ha uno scopo aziendale documentato. |
| Confermare accesso alla fonte | Responsabile hosting o database | Stato connessione, prefisso database, nota sul file root | I record e i file della fonte necessari sono raggiungibili. |
| Inventariare temi ed estensioni | Sviluppatore o agenzia | Tema attivo, elenco estensioni, registro tabelle personalizzate e file modificati | Record core e funzionamento gestito dalle estensioni possono essere separati. |
| Identificare sistemi esterni | Responsabile integrazioni | Elenco ERP/PIM/WMS/marketplace/contabilità e chiavi stabili | I valori mantenuti fuori da CS-Cart hanno un sistema autorevole nominato. |
Creare un registro modifiche dopo il cut-off delle evidenze. Nuove estensioni, modifiche alle Product variations, fusioni di vendor, modifiche alle vetrine o ristrutturazioni delle Categories devono essere registrate durante la preparazione.
Preparare Products, options, features, variations e Categories
CS-Cart separa proprietà Product, options selezionabili, Product features, variations, Categories, sconti quantità, file scaricabili, immagini, valori SEO e assegnazioni alle vetrine. Le options possono raccogliere scelte o input dell’acquirente. Le features descrivono caratteristiche strutturate e possono supportare filtraggio o confronto. Le variations raggruppano Products simili in base a valori feature e possono mantenere identità Product indipendente.
Preparare un inventario Product che identifichi quale struttura possiede ogni valore commerciale o descrittivo.
| Pattern della fonte | Azione di preparazione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Option selezionabile | Registrare tipo di option, variants, obbligatorietà, regole di combinazione ed effetti su prezzo/peso | Export di Product e assegnazione option | Il comportamento delle scelte dell’acquirente è esplicito. |
| Product variation | Registrare variation group, valori feature, Product ID, SKU, prezzo, stock, immagini e stato | Manifest dei variation group | Ogni Product gestito indipendentemente resta identificabile. |
| Product feature | Registrare feature group, tipo, valori, ambito Category/vetrina e utilizzo nei filters | Inventario feature | Valori descrittivi e di scoperta sono separati dalle options. |
| Product in più Categories | Registrare tutte le assegnazioni, contesto principale di merchandising e ambito vetrina | Export Product-to-Category | La presenza condivisa è visibile senza ipotizzare Products duplicati. |
| Product scaricabile | Registrare file, condizioni di attivazione, relazione Product e percorso originale | Manifest Product/file | File e relazioni Product sono disponibili. |
| Prezzo quantità o wholesale | Registrare Product, soglia, gruppo utenti o contesto Customer, valuta e importo | Inventario prezzi | I valori commerciali condizionati non sono ridotti al prezzo base. |
Registrare combinazioni di options vietate o consentite, allegati, Products obbligatori, bundle, relazioni reward e campi Product gestiti dalle estensioni quando attivi. Non unire etichette di option e feature simili senza confermare se una rappresenta una scelta dell’acquirente e l’altra una specifica.
Documentare ambito di vetrina, azienda e catalogo
CS-Cart può usare più vetrine e Multi-Vendor può introdurre vendor i cui Products, amministratori, Pages, metodi di spedizione e Orders appartengono a partecipanti distinti del marketplace. Preparare una matrice di ambito che mostri quali record appartengono al catalogo comune, a una vetrina specifica, a un vendor o a un canale esterno.
| Area di ambito | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Domini e lingue delle vetrine | Amministratore piattaforma | Impostazioni delle vetrine ed elenco domini | Ogni contesto Store pubblico è identificato. |
| Disponibilità di Products e Categories | Responsabile catalogo | Export delle assegnazioni vetrina/azienda | Record di catalogo condivisi e limitati sono distinguibili. |
| Features e filters | Responsabile merchandising | Mappa feature-to-Category e vetrina | I vocabolari di scoperta hanno un ambito esplicito. |
| CMS Pages e layout | Responsabile contenuti | Inventario Page, blocchi, layout, menu e vetrine | Contenuti e presentazione sono collegati alla vetrina corretta. |
| Proprietà azienda o vendor | Responsabile marketplace | Associazioni Product, Order, amministratore e Page | I record di proprietà del venditore non sono trattati per impostazione predefinita come proprietà del marketplace. |
Preparare vendor, amministratori, piani e relazioni finanziarie
Questa sezione si applica quando il modello operativo della fonte o della destinazione include Multi-Vendor. Un vendor è un’azienda venditrice indipendente con amministratori, Products, Orders, contesto di spedizione, stato e relazioni contabili associati. Vendor plans, commissioni di transazione, commissioni, pagamenti, prelievi ed estensioni di pagamento del marketplace possono aggiungere ulteriori record.
Preparare un registro vendor che distingua vendor attivi, in attesa, disabilitati, uniti, storici e duplicati. Registrare amministratori assegnati a ogni vendor, proprietà Product, proprietà Order, contesto di piano o commissione, evidenze del saldo account, record di pagamento e prelievo e identificatori esterni del venditore.
| Record marketplace | Azione di preparazione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Identità vendor | Registrare company ID, stato, dati legali/contatto, pagina vetrina e chiave esterna | Inventario vendor | Ogni venditore mantenuto ha una sola identità prevista. |
| Amministratori vendor | Registrare account utente, relazione vendor, stato e contesto autorizzazioni | Mappa amministratore-to-vendor | Le relazioni di accesso del venditore sono documentate. |
| Products di proprietà vendor | Registrare proprietà Product e Category, stato di approvazione e ambito vetrina | Export Product-to-vendor | La proprietà del catalogo è esplicita. |
| Vendor plans o commissioni | Registrare piano, tariffa, commissione, date di efficacia ed estensione responsabile | Inventario piano/commissione | Le regole finanziarie sono separate dai normali campi del profilo vendor. |
| Contabilità, pagamenti e prelievi | Registrare tipo di transazione, vendor, importo, stato, data e Order collegato | Campioni di cronologia finanziaria | Il contesto finanziario del marketplace è tracciabile. |
| Orders suddivisi o vendor Orders | Registrare relazioni parent/suborder e vendor responsabile | Gruppi Order rappresentativi | La responsabilità storica del venditore può essere interpretata. |
Non presumere che ogni Customer con un nome azienda sia un vendor o che un account amministratore vendor contenga l’intero record del venditore.
Preparare Customers, User Groups, indirizzi e campi account
I record Customer di CS-Cart possono includere indirizzi, user groups, stato di approvazione, campi profilo, newsletter, rewards, Reviews e identificatori esterni. Multi-Vendor include anche amministratori vendor, che richiedono una proprietà distinta dai Customers ordinari.
| Area record | Azione di preparazione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Identità Customer | Identificare duplicati, email condivise, clienti non registrati, approvazioni e chiavi esterne | Elenco eccezioni Customer | Le eccezioni di identità hanno responsabile e decisione. |
| User Groups | Registrare appartenenza e ogni effetto su prezzi, imposte, accesso o contenuti | Matrice group-to-rule | Il significato del gruppo è documentato oltre l’etichetta. |
| Campi profilo | Registrare responsabile del campo, tipo, obbligatorietà e uso | Inventario campi profilo | I valori personalizzati attivi hanno una decisione di destinazione. |
| Indirizzi | Separare profili riutilizzabili da snapshot al momento dell’Order | Esempi Customer e Order | Record account e transazione sono distinti. |
| Amministratori vendor | Mantenere l’identità dell’amministratore del venditore collegata al record vendor | Mappa amministratori | L’accesso marketplace non viene appiattito nella segmentazione Customer. |
| ID account esterni | Registrare chiavi CRM, ERP, loyalty o B2B | Mappa identificatori | I sistemi che continuano a operare possono trovare lo stesso account. |
Preparare Orders, proprietà venditore, totali e stato storico
La preparazione degli Orders deve preservare che cosa è stato acquistato, da chi, da quale venditore, a quale prezzo e con quale contesto storico di pagamento, spedizione, imposte, sconti e stato. Gli Orders Multi-Vendor possono essere suddivisi in modo che ogni vendor gestisca una parte correlata dell’acquisto originale.
| Evidenza Order | Azione di preparazione | Condizione di prontezza |
|---|---|---|
| Righe Product e variation | Registrare Product ID, variation/features/options, venditore, quantità, prezzo e testo snapshot | Articoli acquistati e proprietà venditore restano interpretabili. |
| Parent e vendor Orders | Registrare Order originale e Orders specifici del venditore correlati | La cronologia Multi-Vendor non viene appiattita in transazioni scollegate. |
| Indirizzi di fatturazione e spedizione | Preservare snapshot Order separatamente dai profili Customer | Le evidenze storiche degli indirizzi sono complete. |
| Imposte, spedizione, sconti, commissioni e rewards | Inventariare ogni totale materiale e relativa estensione responsabile | I totali finali possono essere spiegati. |
| Riferimenti pagamento ed evasione | Registrare etichette, transaction ID, metodi di spedizione, tracking e vendor responsabile | Il contesto storico di elaborazione è tracciabile. |
| Stati, rimborsi e commenti | Registrare sequenza, visibilità, venditore interessato e record collegati | Lo staff può interpretare il ciclo di vita storico. |
| Riferimenti contabili | Collegare Orders a record di commissione, pagamento, prelievo o saldo dove applicabile | La cronologia finanziaria marketplace resta collegata. |
Gli Orders storici non devono essere ricalcolati utilizzando impostazioni correnti di Product, vendor plan, commissione, spedizione o pagamento.
Inventariare estensioni della piattaforma, temi, campi personalizzati e integrazioni
Le estensioni CS-Cart possono possedere Product variations, SEO names, vendor plans, pagamenti marketplace, rewards, Reviews, layout, campi personalizzati, totali Order, report o connessioni esterne. Usare “estensione della piattaforma” o il nome esatto del componente, così le funzioni della piattaforma non vengono confuse con gli enhancement del servizio di migrazione.
| Effetto della dipendenza | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Estensione Product o catalogo | Campi/tabelle, Product ID, impostazioni e record rappresentativi | I valori attivi del catalogo hanno un responsabile definito. |
| Estensione vendor o contabile | Record vendor, piano, commissione, pagamento o prelievo | I dati finanziari marketplace sono classificati separatamente. |
| Estensione pagamento o spedizione | Riferimenti storici e riepilogo configurazione | Le evidenze di transazione sono separate dalla configurazione corrente dello Store. |
| Estensione SEO o percorsi | SEO names, impostazioni rewrite e tabelle redirect | I percorsi importanti della fonte possono essere ricostruiti. |
| Personalizzazione tema o layout | File tema, assegnazioni layout/blocchi, screenshot | I contenuti aziendali sono separati dalla presentazione. |
| Integrazione ERP/PIM/WMS/marketplace | Sistema autorevole, direzione della sincronizzazione e ID stabili | I sistemi che continuano a operare possono riconnettersi alle entità della destinazione. |
| Tabella o campo personalizzato | Schema, chiavi parent, utilizzatore e finalità aziendale | Ogni valore personalizzato attivo ha una decisione. |
Preparare CMS Pages, SEO names, media ed evidenze dei percorsi
Preparare CMS Pages, Blog Posts dove presenti, descrizioni Product e Category, pagine vendor, menu, layout, blocchi, banner, allegati e media per responsabile e vetrina. Registrare lingua, stato, percorso, vetrina, relazione vendor, link incorporati e destinazione prevista.
Per percorsi prioritari Product, Category, feature, CMS, vendor e Blog, registrare oggetto della fonte, vetrina, lingua, SEO name, percorso attuale, importanza aziendale e decisione di redirect o esclusione. Blog Posts, pagine vetrina vendor e blocchi CMS possono condividere etichette pur appartenendo a responsabili diversi, quindi registrare separatamente ID, ambito vetrina, relazione autore o vendor, media e posizionamento nei menu. Preservare immagini originali, file scaricabili, allegati e risorse del tema al di fuori del backup del database.
Costruire il pacchetto di backup e prontezza degli input
| Componente del pacchetto | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Backup database | Amministratore database | Dump con timestamp e nota sul prefisso database | Tutte le tabelle core, delle estensioni e vendor dello Store previsto sono incluse. |
| File e media | Responsabile hosting o tecnico | Archivio file o struttura sorgente accessibile | Immagini, download, allegati, temi ed estensioni sono disponibili. |
| Registro edizione e ambito | Responsabile piattaforma | Versione, edizione, vetrine, aziende/vendor, lingue, valute | Le relazioni Store Builder e Multi-Vendor sono esplicite. |
| Registro accessi | Responsabile progetto | Responsabile accesso e stato connessione | L’accesso richiesto è disponibile senza esporre credenziali. |
| Registro modifiche | Amministratore Store | Modifiche strutturali dopo il cut-off delle evidenze | Le modifiche tardive possono essere incorporate deliberatamente. |
Selezionare campioni rappresentativi per il test di migrazione
Preparare un manifest dei campioni con ID della fonte, ragione aziendale, vetrina o vendor responsabile, file correlati e relazioni della fonte attese. Il manifest dei campioni CS-Cart è pronto quando ogni aspettativa della fonte, proprietario vetrina o vendor, file collegato e identificatore è completo e assegnato a un revisore.
Includere almeno:
- Products semplici e Products con options, features, variations, più Categories, file o prezzi speciali;
- record circoscritti a vetrine differenti;
- Customers ordinari, Customers appartenenti a user group, amministratori vendor e campi profilo personalizzati;
- Orders standard e Orders con variations, totali insoliti, rimborsi, tracking e ID esterni;
- per Multi-Vendor, Products di proprietà vendor, parent/suborders, piani, commissioni, pagamenti o prelievi;
- percorsi prioritari CMS, Blog, Product, Category, vendor e SEO;
- un record attivo di un’estensione della piattaforma e una relazione con un sistema esterno.
Applicare il gate finale di prontezza CS-Cart
| Domanda di prontezza | Risultato richiesto |
|---|---|
| Edizione e ambito delle vetrine sono noti? | Versione, modello Store Builder o Multi-Vendor, vetrine, lingue e aziende/vendor sono registrati. |
| Le evidenze del catalogo sono complete? | Products, options, features, variations, Categories, prezzi, media e ambito sono rappresentati. |
| Le relazioni marketplace sono preparate? | Vendor, amministratori, Products di proprietà venditore, Orders, piani e record contabili hanno responsabili. |
| Customers e Orders sono interpretabili? | Gruppi, profili, indirizzi, stati, totali, contesto venditore e ID esterni sono documentati. |
| Estensioni e dati personalizzati sono classificati? | Ogni dipendenza attiva ha finalità aziendale e decisione di destinazione. |
| Contenuti e percorsi sono inventariati? | Relazioni di vetrina, vendor, CMS, Blog, media e SEO sono documentate. |
| Backup, accessi e campioni sono pronti? | Il pacchetto della fonte è ripristinabile e gli ID rappresentativi sono elencati. |
La preparazione resta aperta quando edizione, proprietà vendor, Product variation, suddivisione degli Orders, cronologia contabile, ambito delle vetrine o un record attivo di un’estensione non sono ancora documentati.
Conclusione
La preparazione a CS-Cart deve riflettere il modello operativo reale. Products, options, features, variations, vetrine, Customers, Orders, contenuti ed estensioni formano un livello di preparazione; Multi-Vendor aggiunge venditori, amministratori, record di catalogo di proprietà dei venditori, Orders suddivisi, piani, commissioni, pagamenti e prelievi.
Un pacchetto della fonte controllato rende esplicite queste relazioni e fornisce record rappresentativi per la configurazione della migrazione.
Domande frequenti
Perché CS-Cart Store Builder e Multi-Vendor devono essere distinti prima della migrazione?
Multi-Vendor introduce vendor, amministratori vendor, Products di proprietà dei venditori, Orders suddivisi, piani, commissioni, contabilità, pagamenti e prelievi. Queste relazioni non appartengono a un normale modello dati Store Builder.
Qual è la differenza tra options, features e variations di CS-Cart?
Le options raccolgono scelte o input dell’acquirente, le features descrivono e classificano Products e le variations raggruppano Products gestiti indipendentemente in base a valori feature. Prepararle come set di evidenze separati.
Come devono essere documentate più vetrine CS-Cart?
Registrare dominio, lingua, valuta, tema, Products, Categories, contenuti, percorsi, features e ambito aziendale di ogni vetrina. I record condivisi e limitati devono essere visibili in un’unica matrice.
Quali record vendor appartengono a un pacchetto di preparazione Multi-Vendor?
Includere profili vendor, stati, amministratori, proprietà Product, proprietà Order, piani, commissioni, transazioni contabili, pagamenti, prelievi e identificatori esterni del venditore dove utilizzati.
I dati delle estensioni CS-Cart devono essere trattati come normali campi Product o Order?
Non automaticamente. Registrare estensione, entità interessate, tabelle o campi, ID rappresentativi e utilizzatore aziendale. I record attivi richiedono un responsabile esplicito; i dati obsoleti possono essere archiviati o esclusi.
Quali Orders devono essere selezionati per la preparazione a CS-Cart?
Usare Orders ordinari e complessi, righe variation e option, diversi totali e stati, rimborsi, tracking, ID esterni e, quando è coinvolto Multi-Vendor, parent/suborders, responsabilità vendor e record contabili collegati.