EShop è un’estensione e-commerce per Joomla con propri record di catalogo, Customer, Order, prezzi, sconti, Tax, spedizioni, pagamenti e processo di acquisto. Joomla fornisce invece il contesto circostante di identità, routing, moduli, lingue, template e sito. Una corretta traduzione del modello dati deve preservare il confine tra questi due livelli e, allo stesso tempo, distinguere i record commerciali storici dalla configurazione attiva.
Quando EShop è la piattaforma di destinazione, campi della piattaforma di origine con nomi simili possono richiedere rappresentazioni diverse. Un “attributo” di origine può essere un’opzione Product selezionabile dall’acquirente, un attributo informativo, un campo Product personalizzato, una scheda Product, un campo del processo di acquisto o un identificatore esterno. Un gruppo Customer di origine può controllare il prezzo anziché i permessi. Un percorso di pagina della piattaforma di origine può dipendere dalle Joomla Menu Items invece di appartenere direttamente al Product. Le decisioni sul modello dati devono quindi partire da significato e proprietà, non dall’etichetta.
EShop combina dati e-commerce e struttura del sito Joomla
EShop possiede i principali record dello store. Joomla possiede identità generale del sito, navigazione, moduli, template, lingue, accesso e infrastruttura delle estensioni. Plugin di pagamento, spedizione, importazione, reportistica e integrazione possono introdurre dati o riferimenti aggiuntivi.
| Livello di proprietà | Record tipici | Conseguenza per la traduzione dei dati |
|---|---|---|
| Catalogo EShop | Products, Categories, Manufacturers, opzioni, attributi, campi personalizzati, allegati, prezzi, stock | Preservare le relazioni Product e distinguere le scelte acquistabili dalle informazioni descrittive. |
| Storico commerciale EShop | Customers, gruppi, indirizzi, Orders, righe Order, Coupons, voucher, Tax, spedizione, pagamento, stati | Mantenere gli snapshot storici e le relazioni che spiegano ogni transazione. |
| Core Joomla | Users, Menu Items, moduli, lingue, alias, template, accesso | Mantenere contesto di route, identità e presentazione senza trattarlo come dati di catalogo EShop. |
| Plugin EShop e Joomla | Pagamenti, spedizioni, importazioni, moduli, campi specializzati, integrazioni | Identificare il proprietario del plugin e se il record è storico, operativo o esterno. |
| Sistemi esterni | ERP, CRM, POS, evasione degli ordini, contabilità, informazioni Product | Preservare identificatori stabili sull’entità EShop riconosciuta dal sistema esterno. |
Questa mappa di proprietà mantiene distinto un record Product dalla pagina Joomla che lo espone e separa il riferimento di pagamento di un Order dalla configurazione del plugin di pagamento usata per le transazioni future.
Products, Categories, Manufacturers e relazioni del catalogo
Un Product EShop può partecipare a numerose relazioni di catalogo: collocazione nelle Categories, identità Manufacturer, media, prezzi, stock, classe Tax, misure, opzioni, attributi, campi personalizzati, schede, allegati, Products correlati, metadati, alias e valori specifici per lingua. Una piattaforma di origine può combinare o separare questi concetti in modo diverso.
Le Categories possono formare una gerarchia e ricevere assegnazioni Product. I Manufacturers costituiscono un’entità separata simile al brand. Products correlati, dati di confronto, wishlist, filtri, moduli e ricerca possono dipendere dall’identità del Product senza diventare campi Product.
| Concetto di origine | Possibile rappresentazione EShop | Relazione da preservare |
|---|---|---|
| Famiglia Product con SKU figli separati | Product padre con opzioni oppure Products separati collegati tramite relazioni di merchandising | Identità acquistabile, stock, prezzo, media e ID esterni al livello corretto |
| Brand o vendor | Manufacturer | Relazione Product-Manufacturer senza fondere il Manufacturer nella tassonomia Category |
| Albero di reparti | Gerarchia Category EShop | Struttura padre-figlio, assegnazione Product, alias, metadati e contesto linguistico |
| Articolo correlato o complementare | Relazione con Product correlato | Direzione e scopo dell’associazione Product-Product |
| Download, manuale o scheda tecnica | Allegato Product o scheda Product | Proprietà del file, relazione Product, titolo, lingua e visibilità |
| Informazioni tecniche Product | Attributo, campo personalizzato o scheda Product | Significato descrittivo senza creare scelte inutili per l’acquirente |
La rappresentazione di destinazione dovrebbe preservare la logica di gestione del catalogo di origine. Due Products con SKU e identità di magazzino differenti non dovrebbero essere uniti soltanto perché condividono il titolo. Viceversa, un sistema di origine che crea un record per ogni taglia può essere rappresentato meglio tramite opzioni Product EShop quando le combinazioni appartengono a un unico Product padre di merchandising.
Opzioni Product, attributi, campi personalizzati e schede non sono intercambiabili
EShop distingue le scelte dell’acquirente dalle informazioni descrittive del Product. Le opzioni Product rappresentano selezioni effettuate dal Customer prima di aggiungere il Product al carrello, come taglia o colore. Gli attributi descrivono informazioni usate per dettaglio o confronto. I campi personalizzati possono contenere ulteriori valori specifici del Product. Schede e allegati possono fornire contenuti estesi, video, documentazione o file.
| Struttura EShop | Significato principale | Esempi dalla piattaforma di origine |
|---|---|---|
| Opzione Product | Scelta selezionabile dall’acquirente che può influire sulla riga acquistata | Taglia, colore, confezione, finitura, livello di servizio |
| Valore opzione | Selezione consentita all’interno di un’opzione | Small, medium, blue, confezione regalo |
| Attributo Product | Caratteristica informativa usata per descrizione o confronto | Materiale, processore, capacità, compatibilità |
| Campo Product personalizzato | Valore strutturato aggiuntivo non coperto dai normali campi Product | Codice normativo, classificazione interna, riferimento esterno |
| Scheda Product | Sezione di contenuto esteso nella pagina Product | Specifiche, garanzia, video, istruzioni di manutenzione |
| Allegato | Relazione di un file con un Product | Manuale, certificato, datasheet, documento scaricabile |
Un’opzione della piattaforma di origine dovrebbe diventare un’opzione EShop soltanto quando la selezione del Customer fa parte della riga Product acquistata. Una specifica tecnica che non modifica la scelta vendibile appartiene invece a un attributo, a un campo personalizzato o a una sezione di contenuto. Appiattire queste strutture può creare combinazioni impossibili di opzioni, pagine Product duplicate o righe Order che non mostrano più ciò che l’acquirente aveva selezionato.
Anche il significato commerciale a livello di opzione richiede attenzione. Quando le selezioni di origine influenzano prezzo, SKU, peso, immagine, stock o disponibilità, la rappresentazione di destinazione deve mantenere collegate queste relazioni. Un’etichetta senza il relativo funzionamento commerciale non costituisce un modello dati equivalente.
Customers, Joomla Users, gruppi Customer e indirizzi hanno significati diversi
I Customers EShop possono essere collegati a identità Joomla User, ma i dati Customer includono relazioni specifiche dell’e-commerce come indirizzi, Orders, wishlist, contesto reward e assegnazione a gruppi. Il processo di acquisto per clienti non registrati può creare identità storiche dell’acquirente e dati indirizzo senza un account registrato permanente.
I gruppi Customer sono particolarmente importanti perché EShop può utilizzarli per prezzi differenziati. Un Joomla User group, invece, rappresenta normalmente permessi o accesso. Un “gruppo” della piattaforma di origine deve quindi essere classificato prima di essere tradotto nel modello di destinazione.
| Record di origine | Significato di destinazione in EShop o Joomla |
|---|---|
| Login registrato | Identità Joomla User collegata al Customer EShop appropriato, dove supportato |
| Customer e-commerce | Profilo acquirente EShop, indirizzi, relazioni con Orders e contesto commerciale del gruppo |
| Acquirente non registrato | Identità storica e indirizzo conservati con gli Orders senza inventare un account permanente |
| Tier wholesale o di prezzo | Gruppo Customer EShop quando governa prezzo commerciale o idoneità |
| Ruolo amministratore o contenuti | Joomla User group e struttura dei permessi, non gruppo Customer EShop |
| Organizzazione e contatti | Modello separato organizzazione/contatti quando un semplice record Customer non preserva la relazione |
La traduzione degli indirizzi dovrebbe inoltre distinguere gli indirizzi Customer riutilizzabili dagli snapshot degli Orders. Un Customer può modificare l’indirizzo dopo un acquisto, ma l’Order storico deve comunque conservare i dati di fatturazione e spedizione registrati al momento della transazione.
Gli Orders preservano scelte Product, dati del processo di acquisto e storico commerciale
Un Order EShop può preservare identità di un Customer registrato o di un cliente non registrato, indirizzi di fatturazione e spedizione, righe Product, valori delle opzioni selezionate, quantità, prezzi, sconti, Coupons, voucher, Tax, spedizione, riferimenti di pagamento, valuta, stati, campi personalizzati del processo di acquisto, note e timestamp. Questi dati spiegano ciò che è accaduto; non sono istruzioni su come la destinazione debba calcolare le transazioni future.
| Elemento Order | Significato storico |
|---|---|
| Riga Product | Identità e descrizione del Product acquistato al momento della vendita |
| Valori delle opzioni selezionate | Configurazione effettiva del Product scelta dall’acquirente |
| Campo personalizzato del processo di acquisto | Partita IVA, istruzione di consegna, dettaglio di ritiro, riferimento aziendale o altro valore raccolto |
| Prezzo, sconto, Coupon, voucher e Tax | Snapshot monetario che non dovrebbe essere ricalcolato secondo nuove regole |
| Metodo e importo di spedizione | Scelta per l’evasione dell’ordine e costo registrati sull’Order |
| Metodo di pagamento e riferimento transazione | Contesto storico del pagamento, non configurazione attiva del gateway |
| Valuta | Valuta usata per la transazione e relativi totali registrati |
| Storico stati | Evidenza del ciclo operativo usata per assistenza e reportistica |
I campi personalizzati del processo di acquisto meritano una mappatura specifica. Alcuni valori descrivono il Customer, altri un indirizzo, altri valgono soltanto per un singolo Order e altri ancora identificano un’azienda esterna o un flusso di consegna. Spostare ogni valore del processo di acquisto sul profilo Customer può creare dati obsoleti o errati; conservarli tutti soltanto come testo nell’Order può invece rendere inaccessibili identificatori aziendali riutilizzabili.
Prezzi, sconti, Tax, spedizioni e pagamenti hanno un lato storico e uno di configurazione
EShop supporta prezzi Product, prezzi per gruppi Customer, sconti quantità, Coupons, voucher, aliquote Tax, zone geografiche, valute, plugin di spedizione e plugin di pagamento. Questi concetti hanno due ruoli differenti nel modello dati.
Da una parte, gli Orders storici contengono il risultato commerciale: prezzi addebitati, sconti applicati, Tax registrata, spedizione selezionata, riferimenti di pagamento e totali in valuta. Dall’altra, lo store di destinazione contiene le regole attive e la configurazione dei plugin che determinano il funzionamento futuro.
| Area commerciale | Record storico | Struttura operativa attiva |
|---|---|---|
| Prezzo per gruppo Customer | Prezzo o sconto riflesso nelle righe degli Orders precedenti | Relazione corrente Product-gruppo per la determinazione del prezzo |
| Coupon o voucher | Codice ed effetto dello sconto registrati su un Order | Definizione Coupon/voucher, idoneità, date e utilizzi residui |
| Tax | Importo ed etichetta Tax sull’Order storico | Classe Tax, aliquota, zona geografica e regole di calcolo correnti |
| Spedizione | Etichetta del metodo, costo, indirizzo e contesto tracking | Plugin di spedizione abilitato e condizioni tariffarie correnti |
| Pagamento | Etichetta del metodo, riferimento transazione e stato | Plugin di pagamento abilitato, credenziali e configurazione di elaborazione corrente |
| Valuta | Valuta e totali registrati sull’Order | Valute pubblicate e funzionamento attuale dei tassi di cambio |
Separare questi due lati impedisce che i dati storici vengano sovrascritti dalle regole correnti e che un vecchio Order venga scambiato per una configurazione operativa completa.
Dati e-commerce multilingua e route Joomla formano un modello combinato
EShop supporta dati dello store in più lingue, mentre Joomla fornisce relazioni più ampie tra lingue dei contenuti, Menu, moduli e route. Products, Categories, Manufacturers, opzioni, attributi, campi personalizzati, etichette e testo della vetrina possono avere valori specifici per lingua. Joomla Menu Items e moduli possono esporre route o contenuti di supporto diversi per ciascuna lingua.
Una piattaforma di origine che conserva tutte le traduzioni su un unico Product può richiedere valori EShop specifici per lingua. Una piattaforma che usa record Product separati può richiedere logiche di associazione o identificazione per preservare l’equivalenza. Traduzioni dell’interfaccia e override linguistici dovrebbero restare separati dai contenuti aziendali tradotti.
| Record linguistico o di route | Significato nella destinazione |
|---|---|
| Campo Product o Category tradotto | Contenuto e-commerce rivolto al cliente per una lingua specifica |
| Lingua contenuto Joomla | Assegnazione linguistica usata dai record del sito e dei componenti |
| Menu Item specifica per lingua | Punto di ingresso pubblico, alias e contesto di navigazione per una lingua |
| Modulo specifico per lingua | Blocco di supporto della vetrina mostrato in determinati contesti linguistici |
| Stringa lingua dell’interfaccia | Testo dell’estensione o del template, non contenuto Product o Category |
| Alias Product e metadati | Valori SEO e di route collegati al relativo record e-commerce |
Il record Product e la route che lo espone devono restare distinguibili. Una Joomla Menu Item può puntare a una vista EShop e influenzare il percorso pubblico, mentre alias Product e router EShop contribuiscono al significato complessivo della route. Tradurre soltanto il titolo Product non preserva questa struttura combinata.
Moduli, template, temi e override dei layout sono relazioni di presentazione
EShop può visualizzare Products attraverso pagine del componente, moduli Joomla, Joomla Articles, ricerca, filtri e layout personalizzati. Template e override possono modificare l’output di Product, Category, carrello, processo di acquisto e account senza modificare i dati e-commerce sottostanti.
| Oggetto di presentazione | Interpretazione nel modello dati |
|---|---|
| Modulo Product o Category | Visualizzazione riutilizzabile che interroga i record EShop |
| Joomla Article che incorpora output Product | Record di contenuto che contiene o richiama una relazione EShop |
| Override del template | Logica di rendering, non campo Product portabile |
| Impostazione tema o layout | Configurazione di presentazione separata dalla proprietà del catalogo |
| Modulo filtro o ricerca | Interfaccia di scoperta che usa attributi Product, Categories, Manufacturers o altri dati indicizzati |
| Landing page personalizzata | Contenuto Joomla o di un page builder che fa riferimento a Products e Categories EShop |
Questa separazione consente ai dati di catalogo di restare autorevoli anche quando la destinazione utilizza un page builder, template o layout della vetrina diverso.
Plugin, importazioni, tabelle personalizzate e sistemi esterni estendono il modello core
EShop supporta plugin di pagamento e spedizione, importazioni ed esportazioni, moduli, integrazioni, campi personalizzati e layout personalizzati. Gli store attivi da lungo tempo possono inoltre contenere tabelle modificate, integrazioni SQL dirette, sincronizzazioni pianificate, report personalizzati o identificatori provenienti da ERP, CRM, POS, contabilità e sistemi di evasione degli ordini.
| Segnale di proprietà di un’estensione | Interpretazione richiesta |
|---|---|
| Riferimento transazione di pagamento | Relazione storica Order/pagamento che può servire per assistenza o riconciliazione |
| Identificatore vettore o evasione | Relazione Shipment o Order usata da un sistema esterno |
| Chiave di importazione Product | Identificatore Product o opzione stabile usato per sincronizzazioni ripetute |
| Tabella processo di acquisto personalizzata | Valori a livello di Order, Customer, indirizzo o organizzazione che richiedono proprietà esplicita |
| ID Product o Customer esterno | Identificatore che deve restare collegato all’entità di destinazione riconosciuta dal sistema connesso |
| Stato o metadati creati da plugin | Significato definito dal plugin anziché da un normale campo EShop |
La destinazione non deve copiare ogni tabella di origine. Deve però avere un responsabile esplicito per ogni valore critico per l’azienda e una decisione deliberata su dove il valore debba diventare un campo EShop nativo, un record di proprietà di un plugin, una relazione Joomla o un riferimento di sistema esterno.
Conclusione
Una migrazione verso EShop è una traduzione tra livelli di catalogo, transazioni, Joomla, presentazione, plugin e sistemi esterni. Products, opzioni, attributi, campi personalizzati, Customers, gruppi, indirizzi, Orders, campi del processo di acquisto, prezzi, Tax, spedizioni, pagamenti, lingue, route Menu e moduli hanno ciascuno significati differenti in termini di proprietà e relazioni.
Un modello di destinazione coerente preserva queste distinzioni prima della trasformazione dei record. In questo modo le scelte dell’acquirente restano collegate alle righe Product, i totali storici restano collegati agli Orders, i gruppi commerciali restano distinti dai permessi Joomla, le traduzioni rimangono collegate ai record e-commerce corretti e gli identificatori esterni restano associati alle entità usate dai sistemi connessi.
Domande frequenti
Le opzioni Product e gli attributi EShop sono la stessa cosa?
No. Le opzioni rappresentano scelte selezionabili dall’acquirente che possono comparire sulla riga acquistata. Gli attributi descrivono informazioni Product usate per dettaglio o confronto. Campi personalizzati, schede e allegati svolgono ulteriori funzioni descrittive.
Ogni variante Product della piattaforma di origine dovrebbe diventare un’opzione EShop?
Soltanto quando i record di origine rappresentano scelte all’interno di un unico Product di merchandising. SKU separati con URL, ciclo di vita, inventario, media o identità esterne indipendenti possono dover restare Products separati o richiedere un modello padre-figlio più deliberato.
I Joomla User groups equivalgono ai gruppi Customer EShop?
No. I Joomla User groups controllano normalmente permessi e accesso. I gruppi Customer EShop possono rappresentare segmentazione commerciale, come prezzi differenziati. Un gruppo di origine dovrebbe essere mappato in base a ciò che governa.
Dove dovrebbero essere memorizzati i campi personalizzati del processo di acquisto?
La destinazione dipende dal significato. I valori di identità riutilizzabili possono appartenere a un Customer o a un’organizzazione, i valori di indirizzo a un indirizzo e istruzioni o riferimenti specifici della transazione all’Order.
Gli Orders storici definiscono il funzionamento futuro di Tax, spedizioni e pagamenti?
No. Gli Orders preservano importi, etichette, riferimenti e scelte registrati al momento dell’acquisto. Calcoli ed elaborazione futuri dipendono dalle regole correnti della destinazione e dai plugin abilitati.
Come dovrebbero essere gestite le Joomla Menu Items attorno a Products e Categories EShop?
Le Menu Items dovrebbero restare record di route e navigazione che puntano alle viste EShop. Possono influenzare alias, gerarchia, lingua, accesso e contesto del template, ma non sostituiscono il Product o la Category EShop sottostante.