EasyStore combina un componente commerciale dedicato con i livelli Joomla di identità, accesso, routing, moduli e costruzione delle pagine. Products, varianti, Categories, tag, brand, collezioni, Customers, Orders, coupon, Reviews e record commerciali appartengono a EasyStore, mentre Joomla e SP Page Builder possono determinare come questi record vengono raggiunti e presentati.
Quando EasyStore è la piattaforma di destinazione, la domanda centrale sul modello dati non è se un record di origine possa essere copiato in un campo dal nome simile. La domanda è quale oggetto EasyStore debba essere responsabile del significato e quale relazione Joomla o di presentazione debba restare separata. Un catalogo di origine può contenere Products, opzioni, specifiche, collezioni, navigazione, landing page, identità degli acquirenti e storico delle transazioni in un unico modello; EasyStore distribuisce queste responsabilità tra record commerciali e record che compongono il sito.
EasyStore utilizza livelli distinti di responsabilità tra commercio e Joomla
EasyStore archivia il modello di vendita principale, mentre Joomla fornisce il framework del sito circostante. SP Page Builder può quindi utilizzare i dati EasyStore e comporre la presentazione della vetrina senza diventare il sistema autorevole per inventario Product, identità Customer o storico Order.
| Livello | Record tipici | Conseguenza per la traduzione del modello |
|---|---|---|
| Commercio EasyStore | Products, varianti, prezzi, inventario, Categories, tag, brand, collezioni, Customers, Orders, coupon, Reviews | Questi record formano il grafo dei dati commerciali e devono conservare le loro relazioni interne. |
| Core Joomla | Utenti, livelli di accesso, Menu, moduli, lingue, media, alias | Questi record possono controllare identità, raggiungibilità, visibilità e contesto del sito senza sostituire le entità EasyStore. |
| SP Page Builder | Layout delle pagine e blocchi di contenuto EasyStore | La presentazione fa riferimento ai record EasyStore ma non diventa il sistema autorevole di Product o Order. |
| Integrazioni di pagamento e spedizione | Gateway, vettori e riferimenti di transazione | I riferimenti storici appartengono agli Orders; il funzionamento operativo futuro appartiene all’integrazione sulla destinazione. |
| Estensioni e integrazioni personalizzate | Campi aggiuntivi, webhook, ID esterni, flussi specializzati | La responsabilità deve essere identificata prima di assegnare i valori agli oggetti di destinazione. |
Questa divisione evita due errori comuni: trattare contenuti Joomla come se fossero dati commerciali e trattare l’output visivo di Page Builder come se contenesse il modello Product autorevole.
Products, varianti e combinazioni richiedono una traduzione a livello di relazione
Un Product EasyStore può contenere titolo, alias, descrizione, media, prezzi, trattamento fiscale, misure di spedizione, identificativi, funzionamento dell’inventario, Category, tag, accesso e valori SEO. Quando vengono aggiunte variazioni, EasyStore crea significato commerciale a livello di variante. Prezzi e inventario si spostano dal contesto del Product principale alla sezione Product Variants, dove ogni combinazione può avere prezzo, sconto, peso, SKU, identificativo standardizzato, quantità, disponibilità e visibilità propri.
Una piattaforma di origine può rappresentare la stessa merce come Products separati, un singolo Product con opzioni, una matrice di combinazioni, record figli configurabili o campi personalizzati. La destinazione deve decidere quali record di origine diventano il Product principale EasyStore e quali diventano varianti.
| Schema del catalogo di origine | Domanda sulla rappresentazione EasyStore | Significato a rischio |
|---|---|---|
| Un Product per taglia o colore | I record devono essere consolidati sotto un unico Product principale con varianti? | URL, Reviews, media, inventario e ID esterni possono essere duplicati o accorpati in modo errato. |
| Product principale con SKU figli | Quali attributi dei figli definiscono i valori delle variazioni EasyStore? | Le combinazioni acquistabili possono perdere identità di SKU, prezzo, stock o visibilità. |
| Opzione testuale libera in un Order | Il valore è una variante acquistabile o metadato storico della riga Order? | Le selezioni del Customer possono essere forzate in una struttura di varianti che non corrisponde all’origine. |
| Campi di specifica Product | I valori devono diventare Additional Data EasyStore anziché varianti? | Gli attributi informativi possono essere confusi con scelte selezionabili dall’acquirente. |
| Stock a livello Product più stock delle opzioni | Quale livello di inventario è autorevole? | La destinazione può conteggiare due volte lo stock o mostrare combinazioni non disponibili. |
Le varianti EasyStore non sono semplici etichette di visualizzazione. Una volta aggiunte le variazioni, ogni variante risultante può avere attributi commerciali propri. Gli identificativi di origine devono quindi restare collegati al livello acquistabile riconosciuto da sistemi esterni, processi di magazzino e Orders storici.
Additional Data, tag, brand, collezioni e Products correlati svolgono ruoli diversi
EasyStore offre più strutture per descrivere e raggruppare Products. Additional Data può contenere specifiche strutturate. I tag supportano scoperta e classificazione flessibile. I brand identificano la marca o il produttore. Le Categories organizzano la gerarchia principale del catalogo. Le collezioni possono curare gruppi di Products per il merchandising. Le relazioni di upsell e cross-sell collegano un Product ad altri Products.
Queste strutture non devono essere appiattite in un’unica tassonomia generica.
| Struttura EasyStore | Ruolo principale | Dati di origine che possono corrispondervi |
|---|---|---|
| Category | Organizzazione principale del catalogo e assegnazione Product | Categories o reparti di origine con significato di navigazione durevole |
| Tag | Etichetta flessibile per la scoperta | Parole chiave, temi, casi d’uso o classificazioni non gerarchiche |
| Brand | Identità del brand o produttore Product | Record di brand, vendor o produttore quando i significati coincidono |
| Collezione | Raggruppamento Product curato | Gruppi di campagna, assortimenti stagionali, gamme in evidenza o collezioni editoriali |
| Additional Data | Specifiche Product informative | Attributi tecnici, materiali, dimensioni, compatibilità o fatti descrittivi |
| Relazione upsell/cross-sell | Collegamento di merchandising Product-Product | Riferimenti correlati, complementari, sostitutivi o a maggiore valore |
Una “collection” della piattaforma di origine può essere una Category, un gruppo basato su regole, una landing page o una campagna. La rappresentazione di destinazione deve seguire lo scopo operativo, non l’etichetta. Lo stesso principio vale per gli attributi: una taglia selezionabile dall’acquirente appartiene alla struttura delle variazioni, mentre una specifica tecnica non selezionabile appartiene ad Additional Data o a un altro campo descrittivo.
Le Categories EasyStore non sono Menu Joomla o layout Page Builder
Le Categories EasyStore organizzano Products all’interno del modello commerciale. I Menu Items Joomla rendono raggiungibili le pagine e possono definire alias, percorsi, accesso, lingua e contesto del template. I layout SP Page Builder dispongono componenti e blocchi EasyStore nelle pagine. Una singola landing page della vetrina può dipendere da tutti e tre i livelli.
| Concetto della vetrina | Responsabile EasyStore | Relazione Joomla o di presentazione |
|---|---|---|
| Gerarchia degli elenchi Product | Albero Category EasyStore | Un Menu Item può esporre un percorso Category o una pagina curata. |
| URL Product | Alias Product EasyStore e routing del componente | Il contesto del Menu Joomla può influire sul percorso pubblico. |
| Landing page di campagna | Riferimenti a Products o collezioni EasyStore | Un layout SP Page Builder può comporre il contenuto della campagna. |
| Etichetta di navigazione | Menu Item Joomla | Può puntare a una Category EasyStore, una collezione, un Product o una pagina personalizzata. |
| Blocco Product | Origine dati EasyStore | Il blocco SP Page Builder controlla posizione e presentazione. |
Questa separazione è importante quando la piattaforma di origine archivia navigazione e raggruppamento del catalogo nello stesso oggetto. Ricreare soltanto l’albero Category può non ricreare la navigazione pubblica, mentre copiare soltanto i layout delle pagine può lasciare Products scollegati dalle relazioni autorevoli con Categories e collezioni.
Customers e utenti Joomla possono essere collegati senza essere lo stesso record
EasyStore può mantenere record Customer e può convertire un utente Joomla esistente in Customer. Questa relazione non rende i due concetti identici. Joomla gestisce identità di accesso, stato dell’account, gruppi utente e permessi. EasyStore gestisce il profilo dell’acquirente e le relazioni commerciali necessarie all’attività della vetrina.
Una piattaforma di origine può contenere Customers registrati, acquirenti non registrati, amministratori che non hanno mai acquistato e Customers il cui storico transazionale utilizza un indirizzo email diverso dall’account corrente. Questi schemi non devono essere normalizzati in un unico modello account senza conservarne il significato storico.
| Schema di identità di origine | Decisione sulla relazione EasyStore |
|---|---|
| Acquirente registrato con login equivalente a Joomla | Collegare il Customer EasyStore all’utente Joomla corretto quando la destinazione supporta tale identità. |
| Acquirente non registrato | Conservare dati dell’acquirente e indirizzo con gli Orders storici senza inventare un account permanente. |
| Più account di origine con la stessa email | Decidere se le identità restano separate, vengono consolidate o richiedono una chiave esterna. |
| Account staff o amministratore | Mantenere l’identità dei permessi separata dallo stato Customer salvo che la persona sia anche un acquirente. |
| Contatto B2B collegato a un’organizzazione | Non accorpare significati di organizzazione, contatto, prezzo e permesso in un semplice record Customer. |
Anche i gruppi utente Joomla devono restare distinti dai segmenti commerciali. Un gruppo utilizzato per permessi amministrativi o contenuti riservati non equivale automaticamente a un gruppo Customer, un pubblico destinatario di sconti o una fascia wholesale.
Gli Orders conservano istantanee commerciali, non configurazione attiva
Un Order EasyStore rappresenta una transazione storica. Il suo significato utile può comprendere identità Customer o non registrata, indirizzi, selezioni Product e variante, quantità, prezzi, sconti, imposte, spedizione, riferimenti di pagamento, stato, rimborsi o annullamenti, note e timestamp. Questi valori sono istantanee di ciò che è accaduto al momento dell’acquisto.
I dati Order storici non devono essere usati come sostituto della configurazione corrente di Product, imposte, spedizione, pagamento o processo di acquisto. Un’etichetta di spedizione su un vecchio Order registra il metodo utilizzato allora; non definisce la configurazione del vettore sulla destinazione. Un riferimento di pagamento conserva il contesto della transazione; non configura un gateway.
| Relazione Order | Significato storico da conservare |
|---|---|
| Riferimento Product o variante | Quale articolo acquistabile è stato comprato, incluso l’identificativo di origine quando necessario |
| Descrizione della riga e valori selezionati | L’articolo e la selezione visibili all’acquirente così come registrati al momento dell’acquisto |
| Relazione Customer o non registrata | Chi ha effettuato l’Order e quali indirizzi sono stati utilizzati |
| Prezzo, sconto, imposta e totale | L’istantanea commerciale, non un ricalcolo secondo le regole correnti |
| Riferimento di spedizione e pagamento | Metodo e contesto della transazione registrati per quell’Order |
| Stato e sequenza temporale | Evidenze del ciclo di vita necessarie per assistenza e analisi |
| Informazioni su rimborso o annullamento | La modifica storica alla transazione originale |
Quando la piattaforma di origine archivia le righe Order indipendentemente dai record Product correnti, tali istantanee devono restare leggibili anche se il catalogo attuale è cambiato, uno SKU è stato ritirato o una variante è stata riorganizzata.
Coupon, Reviews e altre relazioni richiedono responsabili propri
Coupon e Reviews sono collegati al catalogo e ai Customers ma non sono campi Product. Un coupon può contenere idoneità, tipo di sconto, data, utilizzo e relazioni con Product, Category o Customer. Una Review può collegare un Customer o un’identità non registrata a Product, valutazione, testo, stato e timestamp.
Trattare questi record come contenuti decorativi fa perdere il significato delle relazioni. Una Review senza il corretto collegamento Product diventa orfana. Un coupon copiato come semplice codice senza vincoli può rappresentare una regola commerciale diversa. Wishlist, evento di analisi o record di carrello abbandonato possono appartenere a un’altra area EasyStore o a un servizio esterno e non devono essere dedotti dai dati Customer o Order principali.
L’integrazione SP Page Builder rappresenta riferimenti di presentazione
EasyStore può fornire Products ed elementi commerciali ai layout SP Page Builder. I blocchi Page Builder possono mostrare elenchi Product, ricerca, Categories, filtri, prezzi, valutazioni, titoli, controlli del carrello, wishlist, contenuti Reviews e altri elementi della vetrina. Questi blocchi fanno riferimento ai dati commerciali; non sono responsabili dell’inventario Product o dello storico Order.
Un builder visivo di origine può incorporare riferimenti al catalogo direttamente nei JSON di pagina o nei record di layout. Il modello di destinazione deve separare contenuto editoriale riutilizzabile, configurazione statica del layout e riferimenti dinamici EasyStore.
| Elemento Page Builder | Interpretazione dei dati |
|---|---|
| Blocco elenco Product | Query di presentazione o riferimento a Products EasyStore |
| Blocco Category | Relazione di visualizzazione con una Category EasyStore |
| Blocco prezzo, valutazione, titolo o miniatura | Campi renderizzati dal contesto Product |
| Controllo carrello o wishlist | Elemento interattivo della vetrina, non dati storici del carrello |
| Blocco statico di testo o immagine | Contenuto di pagina che può richiedere migrazione indipendente |
| Override di layout personalizzato | Implementazione di presentazione anziché entità commerciale standard |
Questa distinzione consente a Products e Categories di restare autorevoli mentre i layout vengono ricreati o tradotti secondo il modello di presentazione della destinazione.
Impostazioni, integrazioni e dati personalizzati devono essere classificati per responsabilità
Le impostazioni EasyStore possono definire imposte, funzionamento del processo di acquisto, pagamenti, spedizione, notifiche email, inventario e regole di visualizzazione. Queste impostazioni influenzano l’operatività attiva ma non equivalgono a Products, Customers o Orders. I record storici possono fare riferimento ai loro risultati senza trasportare la configurazione futura.
Vettori di spedizione personalizzati, integrazioni di pagamento, estensioni sviluppate ad hoc, campi di database personalizzati, webhook e identificativi di sistemi esterni possono aggiungere ulteriori livelli di responsabilità. Il modello di destinazione deve identificare se ciascun valore appartiene a un record EasyStore principale, a un’identità o percorso Joomla, a un riferimento SP Page Builder, a un record di integrazione o a una chiave di sistema esterno.
| Segnale di dati personalizzati | Requisito di traduzione del modello |
|---|---|
| ID ERP o magazzino a livello di variante | Conservare sull’esatta variante acquistabile, non soltanto sul Product principale. |
| Campo Customer personalizzato | Determinare se il valore appartiene a EasyStore, ai dati utente Joomla o a un profilo esterno. |
| Riferimento transazione del gateway | Conservare con l’Order storico e il contesto di pagamento. |
| Identificativo di spedizione specifico del vettore | Conservare con l’Order o la relazione di evasione che lo utilizza. |
| Origine dati personalizzata di Page Builder | Identificare l’entità EasyStore referenziata e la configurazione di presentazione separata. |
| Tabella gestita da estensione | Definire entità principale, scopo operativo e responsabile di destinazione prima della traduzione del modello. |
Un modello di migrazione EasyStore pulito è quindi una mappa delle responsabilità: le entità commerciali restano in EasyStore, accesso e permessi restano in Joomla, la composizione visiva resta in SP Page Builder o nel livello di presentazione della destinazione e gli identificativi esterni restano collegati ai record riconosciuti dai sistemi connessi.
Conclusione
La migrazione dei dati EasyStore richiede più che creare Products e Customers. I Products possono contenere record commerciali a livello di variante; Categories, tag, brand, collezioni e specifiche svolgono ruoli diversi nella scoperta; utenti Joomla e Customers EasyStore possono essere collegati senza diventare la stessa entità; gli Orders conservano istantanee storiche; i layout SP Page Builder fanno riferimento ai dati commerciali senza esserne responsabili.
Mantenere espliciti questi confini produce un modello di destinazione capace di sostenere gestione del catalogo, identità Customer, assistenza sullo storico, presentazione della vetrina e continuità dei sistemi connessi senza appiattire i livelli Joomla ed EasyStore in un insieme ambiguo di record.
Domande frequenti
Le variazioni EasyStore sono soltanto opzioni di visualizzazione?
No. Una volta create le variazioni, le varianti EasyStore possono avere prezzo, sconto, trattamento fiscale, dati di spedizione, SKU, identificativi standardizzati, inventario, disponibilità e visibilità propri. Devono essere tradotte come record acquistabili quando la piattaforma di origine utilizza combinazioni equivalenti.
Le specifiche Product devono diventare variazioni?
Solo quando il valore definisce una combinazione acquistabile selezionabile dal Customer. Le specifiche informative sono meglio rappresentate tramite Additional Data o un’altra struttura descrittiva, così da non creare varianti artificiali.
Le Categories EasyStore sono uguali ai Menu Items Joomla?
No. Le Categories EasyStore organizzano Products. I Menu Items Joomla creano navigazione e contesto di routing e possono puntare a Category, Product, collezione o pagina Page Builder.
Un utente Joomla e un Customer EasyStore possono essere collegati?
Sì. EasyStore supporta la conversione di un utente Joomla in Customer, ma l’utente Joomla resta l’identità di accesso mentre EasyStore gestisce il profilo commerciale e le relative relazioni Customer.
Gli Orders migrati configurano pagamento, spedizione o imposte?
No. Gli Orders conservano il contesto storico della transazione. Il funzionamento futuro di pagamento, spedizione, imposte e processo di acquisto appartiene alle impostazioni EasyStore e alle integrazioni attive sulla destinazione.
Come devono essere trattati i layout della vetrina SP Page Builder?
Devono essere separati in contenuto statico della pagina, configurazione di presentazione e riferimenti alle entità EasyStore. I dati Product e Order devono restare autorevoli in EasyStore anche quando Page Builder controlla il modo in cui gli elementi vengono mostrati nella vetrina.