osCommerce oggi comprende due generazioni di dati profondamente diverse. osCommerce v4 offre più front end o sales channel, Products configurabili, gruppi Customer, attributi Product, proprietà Product, brand, controllo CMS, temi, Apps e logiche di prezzo avanzate. Molti store di origine, tuttavia, utilizzano ancora database derivati dalla linea 2.x o installazioni fortemente modificate, con estensioni e strutture di tabelle che non corrispondono al modello v4.
Questa evoluzione è la prima decisione da affrontare nel modello dati. Un record products_attributesproveniente da un vecchio store non equivale automaticamente a un attributo, una proprietà o una relazione di Product configurabile dell’attuale v4. Una tabella di un’estensione legacy può contenere stock, fornitori, voucher, SEO o dati Order che v4 rappresenta altrove. Un Product v4 può inoltre essere assegnato a sales channel e gruppi Customer, relazioni che nelle installazioni precedenti non esistono nello stesso modo.
La pianificazione della migrazione deve quindi stabilire quale generazione di osCommerce possiede ciascun record, quale significato commerciale ha quel record e quali entità correlate devono rimanere collegate nello store di destinazione.
La generazione della piattaforma definisce un confine nel modello dati di osCommerce
osCommerce v4 e gli store osCommerce legacy non devono essere trattati come un unico schema uniforme. v4 è una piattaforma Open-Source attuale con più front end, controllo CMS, Products configurabili, temi, Apps e un modello amministrativo più recente. Gli store 2.x più vecchi utilizzano invece spesso estensioni dirette delle tabelle, moduli installati manualmente, file PHP modificati e contributi della community.
Lo store di origine può inoltre essere passato attraverso aggiornamenti o fork. I nomi delle tabelle possono sembrare familiari anche quando definizioni dei campi e relazioni sono cambiate. La linea evolutiva della piattaforma determina quindi se un’opzione Product, un gruppo Customer, un sales channel, una pagina di contenuto o il record di un’estensione dispone davvero di un equivalente nativo attuale.
| Evidenza nell’origine | Interpretazione in osCommerce | Conseguenza per la migrazione |
|---|---|---|
| Product v4 attuale e relativi record di assegnazione | Modello catalogo moderno di osCommerce | Mantenere Products, Categories, brand, attributi, proprietà, canali e collegamenti ai gruppi Customer. |
| Tabelle core legacy 2.x | Modello di record osCommerce precedente | Interpretare i dati attraverso le relazioni legacy invece di applicare le etichette attuali di v4. |
| Tabelle o colonne di estensioni della community | Dati di proprietà dell’estensione | Identificare l’estensione e il record core che modifica. |
| PHP e SQL modificati | Logica commerciale o schema personalizzati | Trasferire il significato commerciale anziché copiare il vecchio meccanismo. |
| Store derivato da un fork | Piattaforma con origine correlata ma non identica | Confermare definizioni delle entità e ID sull’installazione effettiva. |
| Chiave di un sistema esterno | Identificatore ERP, PIM, WMS, marketplace, contabilità o evasione degli ordini | Conservare l’identità stabile tra sistemi. |
Questa distinzione evita di progettare un modello di destinazione moderno sulla base di assunzioni valide soltanto per una vecchia installazione di origine.
Products, Categories, brand e sales channel sono collegati ma restano distinti
Nell’attuale osCommerce v4, un Product può includere identità core, descrizioni, identificatori, prezzo e costo, imposte, modalità di stock, immagini, video, packaging, impostazioni virtuali o scaricabili, dati SEO, fornitori, note e relazioni di marketing. Products possono essere assegnati o limitati per sales channel e gruppi Customer. Anche le Categories possono essere assegnate a front end e gruppi Customer specifici.
La struttura va quindi oltre una semplice gerarchia tra Product e Category. Lo stesso Product può essere condiviso tra più front end mantenendo visibilità, contenuto, prezzo o contesto commerciale differenti. Un’installazione multi-store di origine che duplica Products potrebbe essere rappresentata meglio da un’unica identità Product con assegnazioni ai canali; in un altro caso potrebbero invece servire Products distinti perché l’identità commerciale è realmente diversa.
| Struttura nell’origine | Proprietario in osCommerce v4 | Relazione da mantenere |
|---|---|---|
| Articolo vendibile canonico | Product | Identità, identificatori, prezzo, stock, media, imposte e descrizioni. |
| Gerarchia di navigazione | Category e assegnazione Product | Albero delle Categories e collocazione many-to-many dei Products. |
| Brand o produttore | Relazione con brand o fornitore | L’identità del brand resta distinta dalla classificazione in Category. |
| Vetrina regionale o di brand | Front end o sales channel | Disponibilità di Product e Category per canale. |
| Catalogo specifico per un gruppo di acquirenti | Assegnazione Product/Category al gruppo Customer | Visibilità e disponibilità restano collegate al gruppo previsto. |
| Merchandising correlato | XSell, UPSell, gruppi Product o altre relazioni di marketing | I collegamenti di merchandising restano separati dall’appartenenza alle Categories. |
Il numero di Products migrati dice poco sulla correttezza della relazione se il Product finisce nel front end, nella Category, nel gruppo Customer o nel brand sbagliati.
Attributi, proprietà, Products configurabili e gruppi Product hanno ruoli diversi
osCommerce v4 distingue gli attributi dalle proprietà. Gli attributi possono definire valori selezionabili, utilizzare template, incidere su prezzo o peso, supportare file virtuali o scaricabili e partecipare alla gestione dell’inventario Product. Le proprietà descrivono invece caratteristiche del Product e possono supportare visualizzazione, filtri, ricerca, confronto, gruppi Product, icone, swatch, intervalli e valori strutturati.
Un’opzione dell’origine deve quindi essere classificata in base alla sua funzione. Se l’acquirente seleziona un valore che cambia l’articolo acquistato, l’informazione appartiene al livello attributo o Product configurabile. Se il valore descrive l’articolo per ricerca o confronto, appartiene al livello delle proprietà. Se raggruppa Products per merchandising o caratteristiche condivise, può essere più adatta una relazione di gruppo Product.
| Significato nell’origine | Struttura osCommerce da considerare | Confine della relazione |
|---|---|---|
| Scelta di taglia o colore | Attributo e valore assegnato | Product, scelta, effetto su prezzo/peso e valore selezionato nella riga Order. |
| Combinazione con stock indipendente | Product configurabile o relazione attributo-inventario | Identità dell’elemento figlio o della combinazione, quantità, SKU e disponibilità. |
| Specifica tecnica | Categoria di proprietà, proprietà e valore | Il dato strutturato resta separato da una scelta d’acquisto. |
| Intervallo filtrabile | Proprietà con visualizzazione per filtro/ricerca | Tipo, unità, intervallo e valori Product restano normalizzati. |
| Set di opzioni riutilizzabile | Template di attributi | Le definizioni restano riutilizzabili per i Products previsti. |
| Famiglia Product o set di confronto | Gruppo Product o relazione con Products correlati | Il significato del gruppo resta separato dalla gerarchia delle Categories. |
| File digitale | Product virtuale/scaricabile e relazione attributo/file | File, scadenza, limite di download, Product e contesto Order. |
Gli attributi di un osCommerce legacy possono dover essere reinterpretati secondo questi ruoli moderni. Conservare il vecchio nome del campo senza classificarne il funzionamento può trasformare una combinazione vendibile in un valore di filtro oppure una specifica in un’opzione con inventario.
Stock, prezzi, fornitori, canali e gruppi Customer formano un grafo commerciale
I record Product dell’attuale v4 possono includere stock reale o modalità di stock alternative, costo del fornitore, sconti quantità, prezzo consigliato, classe fiscale, disponibilità per canale, assegnazioni ai gruppi Customer e restrizioni specifiche per gruppo. Altre Apps possono estendere funzioni per vendita all’ingrosso, marketplace, vendita al dettaglio o contesti enterprise.
Queste relazioni vanno modellate come un grafo, non appiattite in colonne Product. Un prezzo dell’origine può appartenere a un gruppo Customer, una soglia quantità, una regola di costo del fornitore, un canale, una valuta o una promozione. Una quantità di stock può appartenere a un singolo Product, a una combinazione di attributi, a una sede oppure a un magazzino esterno. Un codice fornitore può essere un campo Product interno o la chiave di un record di approvvigionamento esterno.
| Valore commerciale | Proprietario e relazione | Significato da conservare |
|---|---|---|
| Prezzo base al dettaglio | Product e valuta | Valore commerciale predefinito. |
| Visibilità per gruppo Customer | Assegnazione di Product/Category al gruppo Customer | Accesso dell’acquirente all’oggetto di catalogo. |
| Prezzo di gruppo o all’ingrosso | Product, gruppo Customer e regola di prezzo | Ambito acquirenti previsto e importo. |
| Sconto quantità | Product e relazione con soglia | Quantità di soglia ed effetto sul prezzo. |
| Costo fornitore | Relazione tra Product e fornitore | Responsabile dell’approvvigionamento, costo, valuta e chiave fornitore. |
| Disponibilità per canale | Relazione di Product/Category con il front end | Dove viene offerto l’articolo. |
| Quantità inventario | Product o combinazione configurabile e proprietario dello stock | Identità vendibile e quantità autorevole. |
I prezzi degli Orders storici devono restare snapshot storici. Non vanno ricalcolati dopo la migrazione utilizzando il gruppo Customer, il canale o il prezzo Product attuali.
Customers, gruppi Customer, indirizzi e permessi hanno significati differenti
In osCommerce v4, i gruppi Customer possono controllare visibilità di Product e Category, applicabilità delle imposte, sconti cumulativi e trattamento predefinito per acquirenti ospiti o nuovi acquirenti registrati. I record Customer si collegano inoltre a indirizzi, Orders, dati di comunicazione e potenzialmente ad Apps che forniscono strutture per vendita all’ingrosso, credito, fidelizzazione, marketplace o B2B.
Un segmento nell’origine deve essere interpretato per funzione. Un flag di esenzione fiscale, un segmento marketing, un account per vendita all’ingrosso, una relazione aziendale e un livello di fidelizzazione non corrispondono necessariamente allo stesso gruppo Customer. Alcuni appartengono alle impostazioni core del gruppo, altri a un’App, altri ancora a un CRM o ERP esterno.
| Concetto account nell’origine | Proprietario osCommerce da considerare | Relazione da mantenere |
|---|---|---|
| Acquirente individuale | Account Customer e rubrica indirizzi | Identità, login, indirizzi e Orders. |
| Acquirente ospite | Snapshot Customer a livello Order | Identità storica senza inventare un account persistente. |
| Livello all’ingrosso o al dettaglio | Gruppo Customer e relative regole di catalogo/prezzo | Appartenenza più effetti su visibilità, sconti e imposte. |
| Stato di esenzione fiscale | Impostazione del gruppo o campo Customer/App dedicato | Il significato legale/commerciale resta esplicito. |
| Account aziendale o commerciale | App per vendita all’ingrosso/B2B o entità account esterna | Più utenti e regole commerciali restano collegati. |
| Utente amministratore o staff | Utente amministrativo e permessi | L’accesso dello staff resta distinto dalla segmentazione Customer. |
| ID CRM/ERP | Identificatore esterno | Chiave stabile per la riconnessione. |
La sola etichetta del gruppo è insufficiente quando da essa dipendono prezzi, Products, Categories, imposte o condizioni di pagamento differenti.
Gli Orders conservano snapshot della transazione attraverso record correlati
Gli Orders in osCommerce possono includere identità Customer o di ospite, indirizzi di fatturazione e consegna, snapshot di Products e attributi, quantità, prezzi, sconti, imposte, spedizione, informazioni di pagamento, stati Order, commenti, transazioni, spedizioni, rimborsi, resi, fatture e record di proprietà delle estensioni. L’amministrazione v4 attuale può inoltre gestire Orders manuali e relativo storico Customer.
La migrazione degli Orders deve preservare la transazione storica, non tentare di ricostruirla dalla configurazione Product o Customer attuale. Un Product può aver cambiato nome o prezzo. Un Customer può essere passato a un altro gruppo. Un modulo di pagamento può essere stato sostituito. L’Order rimane interpretabile quando righe, totali, indirizzi, stati e riferimenti propri spiegano ciò che è avvenuto.
| Elemento Order | Proprietario storico | Significato da conservare |
|---|---|---|
| Riga Product | Snapshot Order Product | Nome/SKU Product, quantità, attributi selezionati e prezzo al momento dell’acquisto. |
| Indirizzo di fatturazione/consegna | Snapshot Order | Indirizzo storico indipendente dalla rubrica Customer attuale. |
| Importo di sconto/imposta/spedizione | Totale Order o record di rettifica | Etichetta, importo, sequenza e contributo al totale finale. |
| Riferimento di pagamento | Record transazione o modulo di pagamento | Evidenza storica per la riconciliazione. |
| Stato Order e commenti | Storico Order | Sequenza degli stati, data, visibilità e testo descrittivo. |
| Spedizione/tracking | Record spedizione o evasione degli ordini | Corriere, metodo, tracking e articoli spediti quando rappresentati. |
| Rimborso/reso | Record post-vendita correlato | Importo, righe interessate, motivo e stato. |
Lo store di destinazione può utilizzare nuove configurazioni live per pagamenti e spedizioni continuando a conservare etichette e riferimenti associati ai vecchi Orders.
CMS, front end, temi, URL e contenuti del catalogo hanno proprietari distinti
osCommerce v4 moderno include controllo CMS, più front end, temi, un editor visuale dei temi, contenuti Product e Category, impostazioni SEO, immagini, video e valori specifici per lingua. Le installazioni legacy possono invece utilizzare estensioni per pagine informative, pagine PHP statiche, box di template, file lingua o estensioni SEO della community.
Questi elementi visibili devono essere separati nei domini contenuto, route, canale e presentazione. Una descrizione Product appartiene al Product. Una CMS Page possiede identità e route indipendenti. Una descrizione Category appartiene alla Category. Una voce di menu o il posizionamento in un front end controllano la navigazione. Tema e template definiscono la presentazione. Un redirect collega un vecchio percorso a una nuova destinazione.
| Risorsa nell’origine | Proprietario nella destinazione | Implicazione nel modello dati |
|---|---|---|
| Descrizione Product/Category | Entità di catalogo | Conservare il contenuto con l’entità e la lingua corrette. |
| Pagina informativa o policy | CMS Page | Conservare identità della pagina, route, gerarchia e visibilità. |
| Contenuto specifico per front end | Record CMS/contenuto più assegnazione al canale | Mantenere collegati contenuto e ambito di canale. |
| Nodo menu o navigazione | Configurazione di navigazione | La sola presenza del contenuto non ricrea automaticamente il posizionamento. |
| Blocco tema o box template | Livello di presentazione | Ricostruire il layout separatamente dal contenuto sottostante. |
| Immagine/video Product | Relazione media del Product | Conservare identità media, ordine, lingua e collegamento al Product. |
| URL legacy | Route dell’entità e redirect | Mantenere le relazioni percorso origine-destinazione. |
Questa separazione è particolarmente importante quando si passa da un vecchio store 2.x, nel quale i contenuti sono incorporati nei template o nelle estensioni, alle strutture CMS e front end dell’attuale v4.
Apps, estensioni legacy, tabelle personalizzate e sistemi esterni ampliano osCommerce
osCommerce v4 attuale utilizza un App Shop e supporta Apps per pagamenti, spedizioni, marketing, vendita all’ingrosso, marketplace, contabilità e altre funzioni. Gli store legacy usano spesso estensioni installate manualmente che modificano file core e tabelle del database. Entrambi i modelli possono possedere record al di fuori dello schema nativo di catalogo e Orders.
| Proprietario dei dati | Esempi di record | Decisione di traduzione verso la destinazione |
|---|---|---|
| Core osCommerce | Products, Categories, brand, attributi, proprietà, Customers, Orders, CMS | Trasferire attraverso le relazioni dati native. |
| App v4 | Campi App, entità, transazioni, offerte marketplace, regole per la vendita all’ingrosso | Conservare con l’App o con un altro proprietario esplicito nella destinazione. |
| Estensione legacy | Colonne aggiunte, tabelle, stati, voucher, SEO, stock, report | Identificare l’estensione e i record core che modifica. |
| Codice personalizzato | Tabelle su misura, processi o calcoli modificati | Trasferire il significato commerciale invece della vecchia struttura del codice. |
| Servizio esterno | Imposte, pagamento, spedizione, ricerca, marketplace, analisi | Conservare riferimenti storici e chiavi di connessione attive. |
| ERP/PIM/WMS/CRM | ID master di Product, Customer, stock, fornitore e Order | Conservare identificatori stabili e sistema autorevole. |
Un campo di un’estensione legacy non diventa automaticamente un campo App v4. Allo stesso modo, il nome di un’App attuale non garantisce che i dati di una vecchia estensione abbiano lo stesso schema o significato commerciale. Il confine della migrazione deve essere definito record per record.
Le decisioni di migrazione verso osCommerce vanno prese in base al significato commerciale
| Schema nell’origine | Domanda corretta per la trasformazione | Conseguenza di un’assunzione errata |
|---|---|---|
| Matrice di opzioni legacy | Si tratta di un attributo core, di una relazione con Product configurabile o di una combinazione di stock appartenente a un’estensione? | Si perdono SKU degli elementi figli, stock, prezzo o valori selezionati. |
| Campo descrittivo Product | Appartiene a una proprietà v4, al contenuto, al brand, al fornitore o a un PIM esterno? | La struttura di ricerca e confronto diventa incoerente. |
| Product duplicato tra store | Esiste un solo Product con assegnazioni ai canali oppure più identità commerciali distinte? | Stock e SEO vengono separati inutilmente oppure le differenze regionali vengono sovrascritte. |
| Gruppo Customer | Quali relazioni di visibilità, sconto, imposta o prezzo dipendono dal gruppo? | L’etichetta del segmento sopravvive senza il suo effetto commerciale. |
| Totale Order proveniente da un vecchio modulo | Quale importo ed etichetta storici devono restare nell’Order? | I totali passati non possono più essere spiegati. |
| Pagina statica legacy | È contenuto CMS, codice del template, una route o un record di estensione? | Il contenuto arriva senza la corretta proprietà o navigazione. |
| ID esterno | Quale sistema e quale entità identifica la chiave? | Riconciliazione e sincronizzazione non funzionano. |
La migrazione verso osCommerce riesce quando il modello di destinazione riflette la corretta generazione della piattaforma e mantiene le relazioni tra catalogo, canali, Customers, Orders, contenuti, Apps e sistemi esterni.
Conclusione
La trasformazione del modello dati per osCommerce inizia distinguendo le strutture moderne di v4 dalle installazioni legacy. v4 supporta Products assegnati a sales channel e gruppi Customer, attributi, proprietà, relazioni di catalogo configurabili, controllo CMS, più front end, temi, Apps e logiche di prezzo avanzate. Gli store precedenti possono invece dipendere da tabelle, estensioni e file modificati molto differenti.
Lo store di destinazione deve mantenere identità di Product e Category, attributi selezionabili, proprietà descrittive, relazioni con canali e gruppi Customer, snapshot storici degli Orders, responsabilità di CMS e route e identificatori esterni stabili. Non deve presumere che il record di un’estensione legacy diventi nativo soltanto perché l’attuale v4 offre una funzione con un nome simile.
Domande frequenti
Perché la versione osCommerce dell’origine è così importante?
osCommerce v4 e gli store legacy 2.x utilizzano architetture e modelli di estensione profondamente differenti. La stessa etichetta può riferirsi a tabelle, relazioni o modalità operative diverse, quindi la linea evolutiva dell’origine determina come interpretare il record.
Qual è la differenza tra attributi e proprietà in osCommerce?
Gli attributi possono rappresentare valori Product selezionabili e incidere su prezzo, peso, inventario o file scaricabili. Le proprietà descrivono caratteristiche strutturate utilizzate per visualizzazione, filtri, ricerca, confronto o raggruppamento dei Products.
Un Product osCommerce può essere assegnato a più front end o gruppi Customer?
L’attuale v4 supporta assegnazione o restrizione di Product e Category per front end, sales channel e gruppo Customer. La migrazione deve conservare tali relazioni anziché duplicare Products senza necessità.
Ogni opzione Product legacy deve diventare una relazione Product configurabile moderna?
No. Alcune opzioni modificano soltanto il prezzo o acquisiscono un input dell’acquirente, mentre altre identificano combinazioni con stock indipendente. La destinazione corretta dipende da SKU, stock, prezzo, media e funzionamento della riga Order.
Come vanno gestiti gli Orders storici quando cambiano i moduli di pagamento o spedizione?
Bisogna conservare righe Product, indirizzi, totali, etichette dei metodi, riferimenti delle transazioni, stati, spedizioni e record post-vendita così come risultavano al momento dell’Order. La configurazione live della destinazione può cambiare senza riscrivere la transazione storica.
Che cosa dovrebbe accadere ai dati di vecchie estensioni osCommerce o Apps v4 attuali?
È necessario identificare l’estensione o l’App, l’entità core che estende e qualsiasi sistema esterno da cui dipende. I record ancora attivi richiedono un proprietario esplicito nella destinazione; i dati tecnici obsoleti possono essere archiviati o esclusi invece di essere forzati in campi nativi.