osCMax si comprende meglio come un’installazione e-commerce derivata da osCommerce il cui vero modello dati dipende dal pacchetto installato, dalle contribution, dai template, dai file modificati e dalle strutture personalizzate del database. Due negozi osCMax possono condividere tabelle familiari per Products, Categories, Customers e Orders ma comportarsi in modo diverso perché uno utilizza una contribution inclusa nel pacchetto, un altro ha accumulato anni di modifiche dirette al codice e un terzo dipende da esportazioni personalizzate o sistemi esterni.
Per questo la provenienza e la proprietà dei dati contano più del semplice nome del record. Un campo Product può appartenere al core derivato da osCommerce, essere stato aggiunto da una contribution, servire soltanto alla presentazione nel template oppure rappresentare una chiave di integrazione esterna. Un totale Order può essere un normale subtotale o valore fiscale, oppure essere prodotto da una contribution per sconti, supplementi, buoni regalo, spedizioni o pagamenti. Anche un box della vetrina può contenere informazioni utili al business pur essendo controllato dal codice del template o di un modulo, e non da un’entità CMS.
Il modello di migrazione deve quindi separare i fatti e-commerce di base dal comportamento posseduto dalle contribution e dagli elementi puramente di presentazione. L’obiettivo non è riprodurre ogni meccanismo legacy, ma conservare le relazioni tra Products, Customers, Orders, contenuti e identificatori che continuano ad avere valore per il business.
Il significato dei dati osCMax parte dalla provenienza e dalle contribution installate
osCMax nasce dalla famiglia osCommerce, ma è stato distribuito con funzionalità aggiuntive e viene spesso ampliato tramite contribution. I negozi con una lunga storia possono contenere diverse generazioni di file core, patch al database, template, file di lingua, moduli di pagamento, moduli di spedizione, moduli per i totali Order e modifiche specifiche dell’azienda.
La sola versione della sorgente non descrive completamente lo schema. Codice installato e database devono essere letti insieme. Una tabella apparentemente standard può contenere colonne aggiuntive. Un campo familiare può essere letto da codice personalizzato. Una contribution può creare tabelle proprie e collegarle a Products, Customers o Orders tramite ID interni. La provenienza dei dati è quindi una questione che riguarda le singole entità, non soltanto l’inventario tecnico.
| Livello della sorgente | Evidenza tipica | Conseguenza sul modello dati |
|---|---|---|
| Core derivato da osCommerce | Products, Categories, Customers, indirizzi, Orders, produttori, recensioni | In genere segue relazioni e-commerce familiari. |
| Livello del pacchetto osCMax | Miglioramenti inclusi, convenzioni dei template, campi amministrativi | Verificare se il valore rappresenta dati, configurazione o presentazione. |
| Contribution installata | Tabelle o campi aggiunti, stati, report, sconti, voucher, logica di spedizione o pagamento | Identificare la contribution e i suoi collegamenti ai record core. |
| Modifica dell’azienda | PHP modificato, cambiamenti SQL, file di lingua personalizzati, esportazioni su misura | Trattarla come confine di proprietà personalizzata, non come comportamento nativo della piattaforma. |
| Sistema esterno | ERP, contabilità, magazzino, marketplace, CRM, flusso dati del fornitore | Conservare identificatori esterni stabili e autorità del sistema. |
| Artefatto tecnico obsoleto | Tabelle di moduli abbandonati, campi inutilizzati, vecchi file di template | Non trasformare residui tecnici non più usati in dati permanenti della destinazione. |
Questa lettura a livelli evita un errore frequente: presumere che tutti i record presenti in una tabella riconoscibile in stile osCommerce abbiano lo stesso significato in ogni installazione osCMax.
Products, Categories, produttori e attributi formano il catalogo di base
Il catalogo osCMax di base ruota normalmente intorno a Products, Categories, produttori, descrizioni dei Products, immagini, stock, prezzi, offerte speciali, recensioni e attributi Product. I Products possono appartenere a più Categories e, nelle installazioni multilingua, nomi e descrizioni possono essere memorizzati separatamente per lingua. Gli attributi collegano nomi e valori delle opzioni ai Products e, in base alle contribution installate, possono influire su prezzo, peso, modello, stock o altri comportamenti.
La relazione tra Products, Categories e attributi conta più delle singole righe. Un negozio sorgente può usare un solo Product con vari attributi, record Product separati per ogni SKU oppure tabelle di stock per attributo gestite da una contribution. Il modello di destinazione non dovrebbe dedurre varianti indipendenti solo perché esistono valori di opzione, e non dovrebbe assegnare tutto lo stock al Product padre se la sorgente vende le combinazioni separatamente.
| Schema nella sorgente | Interpretazione osCMax | Relazione da preservare |
|---|---|---|
| Product standard | Record Product core | Identità, descrizione, prezzo, imposta, stock, immagini e collegamenti alle Categories. |
| Product assegnato a più Categories | Relazione Product-Categories | Un’unica identità commerciale con più percorsi di scoperta. |
| Produttore o brand | Record produttore e collegamento al Product | L’identità del brand resta distinta dal posizionamento in Category. |
| Attributo taglia o colore | Relazione attributo Product | Nome e valore dell’opzione, Product, effetto su prezzo/peso ed etichetta nella riga Order. |
| Stock specifico per combinazione | Record di stock per attributo gestito dai contribution | Product, combinazione di opzioni, quantità, SKU e chiave esterna. |
| Prezzo speciale | Relazione Product-offerta speciale | Prezzo attivo e contesto temporale restano distinti dal prezzo base. |
| Recensione | Recensione collegata al Product e, quando disponibile, al Customer | Valutazione, testo, data, stato e identità del Product. |
Una descrizione Product può mostrare quasi qualsiasi informazione, ma non può sostituire le relazioni strutturate di Category, produttore, attributi, stock o recensioni.
Combinazioni di attributi, stock, immagini e prezzi dipendono spesso dalle estensioni
I negozi osCMax legacy utilizzano spesso contribution per estendere il modello core di attributi Product. Queste estensioni possono introdurre stock per attributo, SKU separati per combinazione, immagini aggiuntive, campi extra Product, sconti quantità, prezzi per gruppi Customer, buoni regalo o configuratori Product personalizzati. La vetrina può far sembrare native queste funzioni anche quando i relativi record risiedono fuori dalle tabelle core.
Ogni scelta va classificata in base al suo comportamento commerciale. Un’opzione descrittiva non richiede inventario indipendente. Una combinazione vendibile con SKU e stock propri sì. Un input di testo appartiene alla riga Order. Un prezzo quantità appartiene alla relazione tra Product e soglia. Un’immagine aggiuntiva può appartenere al Product, a un valore di opzione oppure a una contribution che gestisce la galleria nel template.
| Comportamento | Proprietario probabile | Confine di rappresentazione |
|---|---|---|
| L’opzione modifica solo prezzo o peso | Relazione attributo Product core | Conservare nome opzione, valore, collegamento al Product e variazione. |
| La combinazione ha stock o SKU separato | Contribution per stock attributi o varianti | Conservare identità della combinazione e quantità separatamente dal padre. |
| Il compratore inserisce incisione o messaggio | Contribution per input di testo | Conservare il valore inserito sulla riga Order acquistata. |
| Il Product ha più immagini di galleria | Contribution immagini o convenzione del template | Conservare identità del media e relazione con Product/opzione. |
| Prezzo per quantità o Customer | Contribution di prezzi | Conservare Product, soglia o gruppo, valuta e importo come relazione. |
| Buono regalo o voucher | Contribution voucher e relativi record Order | Conservare codice, saldo, destinatario, utilizzi e storico Order quando ancora attivi. |
L’interpretazione deve seguire le relazioni reali tra tabelle e codice del negozio sorgente. Esportazioni generiche degli attributi non sono sufficienti quando un’estensione gestisce altrove la vera identità della combinazione vendibile.
Customers, rubriche indirizzi, gruppi ed estensioni account sono elementi distinti
Il modello Customer derivato da osCommerce comprende normalmente account Customer, rubrica indirizzi, riferimento all’indirizzo predefinito, dati di accesso e preferenze di comunicazione. Le contribution osCMax possono aggiungere gruppi Customer, stato wholesale, identificativi fiscali, campi profilo extra, dati di referral, punti fedeltà, credito account o flussi di approvazione.
Questi record devono essere separati in base alla funzione. Un indirizzo salvato è dato master riutilizzabile del Customer. Gli indirizzi di fatturazione e spedizione salvati sull’Order sono snapshot della transazione. Un gruppo wholesale può controllare prezzo o accesso. Una fonte marketing o un codice referral può essere metadato di reportistica. Un identificatore CRM esterno può essere la chiave necessaria a ricollegare il Customer dopo la migrazione.
| Elemento account sorgente | Proprietario | Significato da conservare |
|---|---|---|
| Account Customer | Record Customer core | Identità e collegamento a indirizzi e Orders. |
| Voce della rubrica indirizzi | Record indirizzo Customer | Relazione di indirizzo riutilizzabile. |
| Indirizzo di fatturazione/spedizione dell’Order | Snapshot Order | Evidenza storica indipendente dai dati Customer correnti. |
| Gruppo wholesale o dealer | Classificazione Customer gestita dai contribution | Appartenenza al gruppo e relative regole di prezzo/accesso. |
| Campo profilo aggiuntivo | Campo contribution o tabella personalizzata | Finalità del campo, privacy e chiave Customer. |
| Punti fedeltà o credito | Contribution loyalty/credito | Saldo, storico dei movimenti e flusso che lo governa. |
| Chiave ERP o CRM | Identificatore esterno | Identità persistente fra sistemi. |
Un’esportazione piatta dei Customers può preservare i recapiti ma perdere la relazione commerciale che rendeva il cliente un dealer, un acquirente esente da imposte o un titolare di credito.
Orders, totali, stati, pagamenti e spedizioni conservano evidenze storiche
Gli Orders osCMax possono contenere identità Customer o guest, snapshot di fatturazione e spedizione, righe Product, etichette degli attributi, quantità, prezzi, imposte, sconti, spedizione, etichette di pagamento, stati Order, commenti e record gestiti dai contribution. Il livello dei totali è particolarmente importante perché molti moduli legacy creano righe separate per subtotale, imposte, spedizione, coupon, gift voucher, supplemento, commissione per ordine minimo, sconto o credito.
Queste righe non sono intercambiabili con la configurazione corrente del checkout. Gli Orders storici dovrebbero conservare cosa è stato addebitato e perché, anche se il negozio di destinazione usa regole diverse per imposte, spedizioni, pagamenti o promozioni. Un ID transazione di un modulo di pagamento può essere una prova storica importante, ma credenziali o codice del vecchio modulo non appartengono al record Order.
| Elemento Order | Proprietario storico | Significato da preservare |
|---|---|---|
| Riga Product | Snapshot Product nell’Order | Nome, modello/SKU, quantità, prezzo e attributi selezionati al momento dell’acquisto. |
| Indirizzo | Snapshot di fatturazione/spedizione dell’Order | Indirizzo storico indipendente dai dati Customer attuali. |
| Riga di totale Order | Modulo dei totali o record totale core | Etichetta, importo, ordine di visualizzazione ed effetto sul totale finale. |
| Riferimento pagamento | Record transazione del modulo di pagamento | Chiave storica di riconciliazione senza trattarla come configurazione live. |
| Metodo di spedizione e tracking | Modulo di spedizione e contesto della spedizione | Etichetta carrier/metodo, costo, tracking ed evidenza di evasione. |
| Stato e commenti Order | Storico Order | Sequenza, data, visibilità e contesto staff/cliente. |
| Reso, voucher o credito | Record post-vendita gestito dai contribution | Collegamento all’Order, importo coinvolto e saldo residuo quando rilevante. |
Il modello Order è realmente utile quando il personale può comprendere la transazione originale senza dover ricostruire il modulo dismesso che l’aveva generata.
Contenuti, box, template, file di lingua e immagini hanno proprietari diversi
Le vetrine osCMax utilizzano spesso template, box, file di lingua, banner, pagine informative, descrizioni dei Products, descrizioni delle Categories, immagini, pulsanti e blocchi generati da contribution. Tutti questi elementi influenzano ciò che vede il cliente, ma non costituiscono un’unica entità di contenuto.
Le descrizioni di Products e Categories appartengono ai record del catalogo. Le pagine informative possono essere archiviate in una contribution di contenuto o in file statici. Titoli dei box e testo dell’interfaccia possono risiedere nei file di lingua. Il posizionamento del box appartiene al template. Pulsanti e icone sono risorse del tema. Un blocco promozionale può essere generato dalla configurazione anziché memorizzato come pagina.
| Risorsa della vetrina | Proprietario dati o presentazione | Interpretazione per la migrazione |
|---|---|---|
| Descrizione Product/Category | Record catalogo | Conservare il contenuto insieme all’entità e alla lingua. |
| Pagina informativa o policy | Contribution di contenuto o contenuto statico | Conservare identità, percorso e relazione di navigazione quando ancora attivi. |
| Titolo box o etichetta interfaccia | File di lingua | Trattarlo come testo UI, non come contenuto CMS. |
| Posizionamento box | Configurazione del template | Ricostruire il posizionamento nella destinazione separatamente dal contenuto. |
| Immagine di galleria Product | Product o contribution immagini | Conservare relazione media e relativo perimetro di opzione/variante. |
| Pulsante, icona o sfondo | Risorsa del tema | Conservarlo solo se ha ancora valore per il design. |
| URL legacy | Product, Category, contenuto o route personalizzata | Mantenere la relazione di redirect tra sorgente e destinazione. |
Questa separazione permette di trasferire contenuti e media utili senza trascinare nel negozio di destinazione meccanismi di template ormai obsoleti.
Contribution e tabelle personalizzate possono possedere record critici per il business
La principale complessità di osCMax è la proprietà dei dati introdotti dalle contribution. Una contribution può aggiungere un campo a una tabella core, creare un’entità indipendente, modificare il calcolo di un Order, introdurre un nuovo stato o mantenere una relazione tramite una chiave personalizzata. La decisione nella destinazione dipende dalla finalità di business, non dalla facilità con cui la riga può essere esportata.
| Schema della contribution | Esempio di significato | Decisione di proprietà richiesta |
|---|---|---|
| Colonne Product aggiunte | Codice fornitore, badge, garanzia, restrizione, stato del flusso dati | Rappresentare come campo nativo, attributo strutturato, chiave esterna oppure archiviare. |
| Tabella Product personalizzata | Compatibilità, componente bundle, abbonamento, prezzi a livelli | Conservare l’entità e i suoi collegamenti ai Products quando ancora attivi. |
| Estensione Customer | Approvazione, loyalty, referral, imposte, stato dealer | Conservare classificazione e regole o storico che le danno significato. |
| Estensione Order | Flag antifrode, stato esportazione, riferimento pagamento, batch di evasione | Conservare come metadato storico o ricollegare al flusso della destinazione. |
| Tabella di report/esportazione | Stato di estrazione contabile o operativo | Conservare solo se continua a essere il record autorevole per il business. |
| Logica core modificata | Regola diversa per imposte, spedizioni, prezzi o permessi | Rappresentare la regola di business nel modello della destinazione, non il vecchio meccanismo PHP. |
Quando nessun flusso attuale utilizza più un record di contribution, archiviarlo può essere più corretto che forzarlo in un generico campo personalizzato. I record ancora attivi richiedono invece una proprietà esplicita dell’entità e collegamenti stabili con Products, Customers o Orders core.
Decisioni di rappresentazione per osCMax basate sul significato di business
| Schema sorgente | Domanda corretta da porsi | Conseguenza di un’ipotesi errata |
|---|---|---|
| Tabella core familiare con colonne extra | Quali campi sono core, del pacchetto, gestiti dai contribution o personalizzati? | Dati dell’estensione vengono scambiati per campi nativi della destinazione. |
| Attributi Product più tabella stock separata | Quale combinazione possiede SKU e quantità? | Lo stock del padre sostituisce quello della combinazione vendibile. |
| Gruppo Customer o flag dealer | Quali prezzi, regole di accesso, imposte o termini di pagamento dipendono dalla classificazione? | Sopravvive il nome del gruppo ma scompare il significato commerciale. |
| Più righe di totale Order | Quale modulo ha creato ogni importo e come incide sul totale finale? | I totali storici diventano incompleti o fuorvianti. |
| Box della vetrina | Il valore è contenuto, configurazione, testo di lingua o posizionamento del template? | Il testo visibile arriva senza route o posizionamento, oppure codice obsoleto viene conservato come dato. |
| ID esportazione personalizzato | Quale sistema esterno possiede la chiave? | Products, Customers o Orders non possono essere riconciliati dopo la migrazione. |
| Tabella di contribution abbandonata | Esiste ancora un flusso attuale che dipende da questi dati? | Residui tecnici vengono portati avanti come disordine permanente nella destinazione. |
I dati osCMax restano utili quando i fatti e-commerce di base vengono separati dai meccanismi di contribution o template che in passato li presentavano o elaboravano.
Conclusione
La traduzione del modello dati osCMax inizia dalla provenienza. Products, Categories, Customers, indirizzi, Orders, produttori, recensioni e attributi possono seguire il core derivato da osCommerce, ma le estensioni possono introdurre stock separato, prezzi, voucher, classificazioni Customer, totali Order, strutture di contenuto, esportazioni e tabelle personalizzate. Anche template e file di lingua modellano la vetrina senza diventare normali entità e-commerce.
Un negozio di destinazione ben progettato preserva i fatti di business e le relazioni ancora attive: identità Product, scelte vendibili, contesto Customer, totali storici degli Orders, contenuti utili e identificatori esterni. Non presume che ogni contribution, file modificato o artefatto del vecchio template meriti un equivalente diretto nella destinazione.
Domande frequenti
Perché due negozi osCMax possono avere modelli dati diversi?
Versioni del pacchetto, contribution, template, patch al database e modifiche dell’azienda possono differire. Tabelle core apparentemente familiari possono quindi contenere campi diversi o essere interpretate da codice diverso.
Gli attributi Product di osCMax equivalgono sempre a varianti indipendenti?
No. Gli attributi core possono modificare un Product, mentre una contribution può aggiungere SKU, stock, prezzo o immagini a livello di combinazione. L’identità vendibile indipendente va dedotta dall’intera relazione, non dalle sole etichette di opzione.
Come vanno interpretati gruppi Customer o campi dealer?
Va identificato il comportamento che controllano, come prezzi, accesso, trattamento fiscale, termini di pagamento o approvazione. La sola etichetta della classificazione è incompleta senza le relative regole commerciali.
Perché i record dei totali Order di osCMax sono importanti?
Possono spiegare subtotale, imposte, spedizione, coupon, gift voucher, sconti, commissioni o crediti. Conservare soltanto il totale finale elimina la struttura che spiega come l’importo è stato calcolato storicamente.
Template, box, pulsanti e file di lingua vanno migrati come contenuti?
Solo quando contengono informazioni di business ancora utili. Posizionamento, etichette dell’interfaccia e risorse visive appartengono alla presentazione e vanno separati da record Product, Category e contenuti.
Cosa fare con i dati gestiti dai contribution o tabelle personalizzate?
Occorre identificare la contribution, i record core che estende e il flusso che continua a usarla. Le relazioni attive richiedono un proprietario esplicito nella destinazione; i record obsoleti possono essere archiviati o esclusi invece di essere forzati in campi generici.