Se EShop by Ossolution Team viene scelto come piattaforma di destinazione, la preparazione deve documentare le relazioni che collegano Products, Categories, Manufacturers, opzioni, attributi, campi personalizzati, allegati, account Customer, Orders, Tax, spedizioni, pagamenti, contenuti multilingua e presentazione Joomla. Le opzioni Product possono avere SKU, prezzo e immagini separati, mentre attributi e campi personalizzati possono descrivere o filtrare Products senza rappresentare un’unità vendibile indipendente.
Il pacchetto di preparazione dovrebbe definire ogni attività, responsabile, evidenza e condizione di preparazione prima dell’esecuzione. Deve preservare transazioni storiche e relazioni della piattaforma di origine, mantenendo invece processo di acquisto attivo, pagamenti, spedizioni, Tax, email, template e moduli sotto la responsabilità dell’implementazione sullo store di destinazione.
Mettere in sicurezza accesso a Joomla, EShop, hosting e database
Confermare l’accesso ad amministrazione Joomla, amministrazione EShop, hosting, database, filesystem, immagini e allegati Product, file scaricabili, processi pianificati, plugin di pagamento e spedizione e sistemi connessi. Registrare versioni di Joomla, EShop, PHP, database, template, lingue, plugin, moduli e personalizzazioni.
| Attività di preparazione | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Confermare gli accessi amministrativi | Amministratore Joomla/EShop | Account funzionanti e riepilogo dei ruoli | Products, opzioni, Customers, Orders, report e configurazione sono consultabili. |
| Creare backup ripristinabili | Responsabile infrastruttura | Export database, archivio filesystem/media/download e responsabile del ripristino | La piattaforma di origine può essere ripristinata senza dipendere dallo store live. |
| Registrare software ed estensioni | Responsabile tecnico | Inventario Joomla, EShop, PHP, database, template, pagamenti, spedizioni, plugin, moduli ed estensioni | Record e dipendenze legati alle versioni sono documentati. |
| Rilevare le personalizzazioni | Responsabile sviluppo | Override template, moduli/plugin personalizzati, modifiche al codice, campi personalizzati, modifiche SQL e script | Ogni personalizzazione che legge o scrive dati e-commerce ha un responsabile. |
| Mappare i sistemi connessi | Responsabili integrazioni | Endpoint ERP/PIM/WMS/CRM/contabilità/evasione/marketplace/flussi di dati e ID esterni | Sistemi che continueranno a operare e autorità dei dati sono noti. |
Preservare gli ID Product, Category, Manufacturer, opzione, valore opzione, attributo, campo personalizzato, Customer, Order, riga Order, stato, Tax, spedizione, pagamento, allegato, lingua ed esterni necessari a ricostruire le relazioni.
Preparare Products, Categories, Manufacturers, media e allegati
I Products EShop possono contenere identificatori, descrizioni, Categories, Manufacturers, prezzi, stock, dimensioni, immagini, video, opzioni, attributi, campi personalizzati, allegati, etichette, Products correlati, Reviews, metadati, file scaricabili e associazioni linguistiche. Preparare i Products in base al comportamento di vendita e alla rilevanza commerciale.
| Schema Product | Evidenze da preparare | Condizione di preparazione |
|---|---|---|
| Product fisico semplice | Product ID, SKU, prezzo, Tax, stock, Category, Manufacturer, immagini e Order di esempio | Un record identifica chiaramente l’articolo venduto. |
| Product con molte opzioni | Definizioni opzioni, valori, combinazioni, SKU/prezzi/immagini separati, relazione con lo stock e Order di esempio | Ogni scelta acquistabile è riconducibile al Product e ai valori opzione corretti. |
| Product scaricabile | File, collegamento Product, regola di accesso, storico download se utilizzato e Order completato | Proprietà del file e accesso basato sull’Order sono documentati. |
| Product in più Categories | Collegamenti Product-Category, route prioritaria e lingua | Le relazioni di scoperta sono preservate senza duplicare Products. |
| Product ricco di allegati | Documenti, manuali, specifiche, percorsi file, etichette e assegnazioni Product | Gli asset diversi dalle immagini restano collegati al Product previsto. |
| Product correlato o confrontato | Tipo di relazione, ID Product collegati, scopo di visualizzazione e priorità | Le relazioni di merchandising sono documentate separatamente dalla tassonomia. |
Registrare casi non pubblicati, featured, call-for-price, esauriti, scaricabili, multilingua, a quantità limitata e con etichette personalizzate. Questi stati richiedono una decisione esplicita sulla destinazione.
Separare opzioni, attributi, campi personalizzati e allegati Product
EShop supporta diverse strutture che in un export della piattaforma di origine possono sembrare tutte semplici attributi Product. Le opzioni possono rappresentare scelte dell’acquirente e avere SKU, prezzo o immagini separati. Gli attributi descrivono caratteristiche Product. I campi personalizzati conservano valori strutturati aggiuntivi. Gli allegati rappresentano file collegati ai Products.
| Struttura | Evidenza | Condizione di preparazione |
|---|---|---|
| Opzione Product | Nome, tipo, valori, ordinamento, stato obbligatorio/predefinito, assegnazioni Product e riga Order di esempio | I valori selezionabili dall’acquirente restano collegati agli acquisti. |
| Valore opzione con dati commerciali | Product, opzione/valore, SKU separato, variazione di prezzo, immagine, funzionamento stock e chiave esterna | I dati della scelta vendibile non vengono appiattiti in attributi descrittivi. |
| Attributo Product | Gruppo/valore attributo, assegnazioni Product, uso per filtri/confronto e lingua | Le caratteristiche descrittive restano separate dalle varianti. |
| Campo personalizzato | Definizione campo, tipo di valore, scopo aziendale, assegnazioni Product e modulo/plugin che lo utilizza | I valori personalizzati hanno un proprietario e un’interfaccia di modifica definiti. |
| Allegato | Percorso file, tipo, etichetta, lingua, collegamento Product e aspettative di accesso | I file Product restano recuperabili e correttamente correlati. |
| Scheda o etichetta Product aggiuntiva | Titolo, contenuto, lingua, assegnazione Product e responsabile della presentazione | Il contenuto editoriale non viene confuso con identità Product o dati delle opzioni. |
Creare un dizionario dei campi che registri scopo, proprietario, tipo di valore, ambito Product e trattamento in migrazione. Nomi simili non dovrebbero essere fusi quando il loro funzionamento commerciale è differente.
Preparare prezzi, stock, Tax, sconti, valute e regole sulle quantità
I prezzi EShop possono includere prezzi standard e speciali, variazioni delle opzioni, Tax, Coupons, sconti, più valute, regole quantità e funzionamenti specifici per Customer o azienda. L’inventario può appartenere a un Product, a una combinazione di opzioni, a un sistema esterno oppure a uno stato scaricabile/non gestito a stock.
| Area commerciale | Evidenze da preparare | Condizione di preparazione |
|---|---|---|
| Prezzi Product e opzioni | ID Product/opzione, valuta, valori standard/speciali, date e variazioni di prezzo | I prezzi sono collegati al corretto contesto vendibile. |
| Stock | Quantità Product/opzione, stato stock, regola di disponibilità, proprietario esterno e chiave di sincronizzazione | Quantità autorevole e identità dell’unità vendibile sono note. |
| Tax | Classe/aliquota Tax, zona geografica, assegnazione Product, contesto Customer ed esempi di Orders storici | La configurazione Tax è separata dagli importi Tax storici. |
| Coupons e sconti | Codice/regola, valore, date, limiti di utilizzo, ambito Product/Category e Orders storici | Regole promozionali attive ed evidenze storiche sono distinguibili. |
| Valuta | Codice valuta, proprietario del tasso, aspettative su decimali/arrotondamenti, prezzi Product e valuta Order | Significati storici e correnti della valuta sono documentati. |
| Regole quantità | Quantità minima/massima, confezionamento, step, prezzo quantità o logica personalizzata | Il funzionamento delle quantità non è nascosto in note o codice del template. |
Se un ERP, flusso di dati del fornitore, marketplace o sistema contabile possiede prezzo o stock, identificare se il valore EShop è autorevole, sincronizzato o soltanto uno snapshot iniziale.
Preparare Customers, Joomla Users, indirizzi, gruppi e Reviews
La preparazione dei Customers EShop dovrebbe collegare utenti Joomla, record Customer EShop, acquirenti non registrati, indirizzi di fatturazione e spedizione, campi personalizzati del processo di acquisto, identificatori aziendali o fiscali, gruppi, Reviews, wishlist, ID esterni e relazioni di consenso dove utilizzate.
| Area account | Evidenza | Responsabile | Condizione di preparazione |
|---|---|---|---|
| Customer registrato | Joomla user ID, EShop Customer ID, email, stato, indirizzi, gruppo e ID esterni | Responsabile dati Customer | Identità duplicate e relazioni tra sistemi hanno un trattamento definito. |
| Acquirente non registrato | Identità a livello Order, email, indirizzi e riferimenti Order | Responsabile dati Order | Lo storico non registrato resta utile senza creare un account. |
| Campo personalizzato fatturazione/spedizione | Definizione campo, regole required/display, valori memorizzati e proprietà Order/Customer | Responsabile assistenza Customer | I dati Customer personalizzati non vengono persi o assegnati all’oggetto sbagliato. |
| Identità aziendale/fiscale | Azienda, numero Tax, stato di validazione, gruppo e chiave account esterna | Responsabile finanza/B2B | L’identità aziendale ha una destinazione o un proprietario mantenuto chiaramente definito. |
| Review o wishlist | Product, identità di un Customer registrato o di un cliente non registrato, rating/testo/stato o relazione wishlist | Responsabile catalogo/contenuti | I dati generati dai Customers restano collegati al Product e all’identità corretti. |
| Autenticazione | Password locale, SSO/social login, flusso reset e responsabile comunicazione | Responsabile sicurezza | L’accesso agli account è pianificato senza presumere la portabilità delle password. |
Includere Customers con più indirizzi, Orders di Customers non registrati, funzionamento basato su gruppi, campi personalizzati, Reviews, wishlist, email duplicate e ID esterni importanti.
Preparare Orders, stati, pagamenti, spedizioni, fatture e download
Gli Orders storici EShop dovrebbero spiegare la transazione indipendentemente dalla configurazione corrente dello store. Preparare intestazioni Order, identità di un Customer registrato o di un cliente non registrato, indirizzi, righe Product e opzioni, allegati o articoli scaricabili, quantità, prezzi, sconti, Tax, Coupons, valuta, pagamento, spedizione, stati, commenti, fatture, rimborsi o rettifiche e riferimenti esterni.
| Evidenza Order | Responsabile | Condizione di preparazione |
|---|---|---|
| Intestazione Order e storico stati | Operazioni e-commerce | Customer registrato o cliente non registrato, date, valuta, sequenza degli stati e canale di origine sono documentati. |
| Righe Product e opzioni | Responsabili catalogo/Orders | ID Product, valori opzione, SKU, quantità, prezzo, Tax e testo snapshot sono completi. |
| Totali e rettifiche | Responsabile finanza | Subtotale, sconto, Coupon, Tax, spedizione, commissione pagamento, valuta e totale finale riconciliano. |
| Pagamento e spedizione | Responsabili finanza/evasione | Etichette storiche del metodo, ID transazione/tracking, vettore e proprietà del provider sono noti. |
| Fattura e accesso ai download | Responsabili finanza/evasione digitale | Numeri/file fattura, download Product, limiti e relazioni Order sono recuperabili. |
| Contesto rimborso/resi | Responsabili finanza/assistenza Customer | Importi, righe interessate, date, motivi, stati e riferimenti esterni sono documentati. |
| ID Order esterni | Responsabile integrazione | Chiavi ERP, contabilità, marketplace o evasione restano tracciabili. |
Scegliere Orders ordinari, Orders di clienti non registrati, con molte opzioni, scontati, multi-Tax, multilingua, scaricabili, rimborsati e tracciati quando questi schemi esistono.
Preparare menu Joomla, contenuti multilingua, URL, media e presentazione
I dati e-commerce EShop possono essere esposti tramite menu Joomla, moduli, template, route Product/Category/Manufacturer, moduli di ricerca, associazioni linguistiche, media e metadati. Queste relazioni dovrebbero essere inventariate separatamente dai dati Product.
| Area della vetrina | Evidenza | Condizione di preparazione |
|---|---|---|
| URL Product, Category e Manufacturer | Route di origine, alias, record ID, contesto menu, lingua, metadati e intento di destinazione | Le route prioritarie hanno una decisione keep, change, merge, retire o redirect. |
| Menu e moduli Joomla | Tipo Menu Item, parent, alias, lingua, accesso, posizione modulo, filtri e tipi di dati selezionati | Punti di ingresso dello store e dipendenze di scoperta sono documentati. |
| Dati multilingua | Associazioni Product/Category/Manufacturer, opzioni/attributi tradotti, menu, metadati e fallback | Le traduzioni non vengono trattate come duplicati non correlati. |
| Template e override | Template, layout EShop, chrome dei moduli, schede personalizzate e route interessate | Le dipendenze di presentazione sono separate dai dati e-commerce. |
| Media e allegati Product | Immagini, thumbnail, video, allegati, download, storage remoto e permessi file | Gli asset prioritari restano disponibili e correttamente collegati. |
| SEO e redirect | Proprietario dei metadati, estensione SEF/routing, fonte sitemap, regole redirect e URL di alto valore | La continuità URL ha un responsabile esplicito. |
L’ambito Joomla più ampio possiede CMS Articles e Pages generali. La preparazione EShop rileva soltanto le strutture Joomla che influenzano materialmente dati e route e-commerce.
Inventariare estensioni, plugin di pagamento e spedizione, dati personalizzati e sistemi esterni
Creare un registro delle dipendenze per estensioni EShop, plugin di pagamento, plugin di spedizione, moduli di ricerca/filtro, strumenti import/export, template, campi personalizzati, CRM, ERP, contabilità, evasione degli ordini, marketplace, analisi e codice su misura.
| Dipendenza | Evidenze da preparare | Condizione di preparazione |
|---|---|---|
| Estensione/plugin EShop | Nome, versione, scopo, configurazione, record posseduti e relativi ID Product/Customer/Order | I record di proprietà dell’estensione hanno una destinazione o un proprietario mantenuto. |
| Plugin pagamento/spedizione | Provider, dati transazione/tracking memorizzati, stati e dipendenze dagli Orders storici | I riferimenti storici sono separati dalla configurazione attiva del plugin. |
| Flusso import/export | Formato file, colonne, identificatori, relazioni opzioni/attributi e ultima esecuzione riuscita | I dati estratti possono essere riconciliati con le evidenze del database. |
| Campo/tabella personalizzati | Schema, chiavi, scopo aziendale e codice che li utilizza | I record personalizzati possono essere interpretati anziché copiati alla cieca. |
| Sistema esterno | Endpoint, tipi di dati autorevoli, direzione di sincronizzazione, ID e responsabile cutover | Identità e autorità tra sistemi sono documentate. |
| Dati generati | Cache, log, sessioni, export temporanei, indici e record abbandonati | I dati tecnici non autorevoli vengono esclusi intenzionalmente. |
Le estensioni inattive dovrebbero restare nel registro quando hanno creato record ancora necessari per Orders, Customers, Products, download o reportistica.
Selezionare campioni rappresentativi per il test di migrazione
Registrare ID della piattaforma di origine, SKU, URL, lingua, record correlati, chiavi esterne e motivo della selezione di ogni campione.
| Campione | Evidenze da preparare | Scopo della preparazione |
|---|---|---|
| Product semplice | Prezzo, stock, Tax, Category, Manufacturer, media e Order | Stabilisce la baseline per un normale Product EShop e il suo contesto commerciale. |
| Product con molte opzioni | Opzioni/valori, SKU/prezzi/immagini separati, funzionamento stock, attributi e riga Order | Rappresenta scelte dell’acquirente e relazioni tra opzioni vendibili. |
| Product con attributi/campi personalizzati | Gruppi attributi, campi personalizzati, allegati, schede, filtri e route Product | Rappresenta dati Product descrittivi ed estesi. |
| Customer registrato e Order non registrato | ID Joomla/Customer, indirizzi, gruppi, campi personalizzati e ID esterni | Rappresenta entrambi i modelli di identità Customer. |
| Order complesso | Righe con opzioni, Coupon, Tax, valuta, pagamento, spedizione, fattura, rimborso, download e riferimento esterno | Rappresenta il contesto commerciale storico. |
| Route multilingua | Products/Categories associati, opzioni tradotte, alias, menu, metadati e intento redirect | Rappresenta dipendenze lingua e routing Joomla. |
| Record di proprietà di un’estensione | Record core o tipo di dati, proprietario dell’estensione/plugin, tabella/campo personalizzato e chiave esterna | Espone l’ambito non core prima dell’esecuzione. |
La preparazione del test di migrazione definisce campioni ed evidenze di origine. La successiva prova sulla destinazione e l’interpretazione per il lancio appartengono alla fase di validazione.
Completare il gate finale di preparazione per EShop
| Area di preparazione | Condizione di preparazione |
|---|---|
| Accesso e ripristino | Joomla, EShop, hosting, database, file, backup e responsabilità del ripristino sono confermati. |
| Catalogo | Products, Categories, Manufacturers, opzioni, attributi, campi personalizzati, allegati, media, stock, prezzi e identificatori sono documentati. |
| Customers | Utenti Joomla, Customers, clienti non registrati, indirizzi, gruppi, campi personalizzati, Reviews, wishlist e dipendenze di autenticazione sono classificati. |
| Orders | Righe, opzioni, totali, stati, pagamento, spedizione, fatture, download, rimborsi e ID esterni hanno evidenze. |
| Vetrina | Menu, moduli, lingue, template, route, media, SEO e redirect sono documentati. |
| Dipendenze | Estensioni, plugin, importazioni, codice personalizzato, sistemi esterni e proprietari autorevoli sono registrati. |
| Campioni | Record rappresentativi coprono ogni schema rilevante di Product, Customer, Order, route, download ed estensione. |
L’ambito EShop è pronto quando ogni record rilevante dispone di un proprietario di origine, una mappa delle relazioni, un’evidenza e una decisione sulla destinazione prevista o sul sistema che continuerà a possederlo.
Conclusione
La preparazione di una migrazione verso EShop richiede evidenze coordinate su Joomla, Products, opzioni, attributi, campi personalizzati, allegati, Customers, Orders, Tax, spedizioni, pagamenti, valute, route multilingua, plugin e sistemi esterni. Queste relazioni non possono essere rappresentate in modo affidabile attraverso un semplice export piatto di Products o Orders.
Un pacchetto di preparazione completo preserva evidenze recuperabili, identifica i record autorevoli, separa le transazioni storiche dalla configurazione corrente e risolve la proprietà di ogni dipendenza rilevante.
Domande frequenti
Cosa bisogna preparare per prima cosa in una migrazione verso EShop?
Confermare l’accesso a Joomla, EShop, hosting, database, filesystem, media, download, plugin di pagamento/spedizione e integrazioni. Creare backup ripristinabili e registrare le versioni software prima di iniziare il lavoro dettagliato sul catalogo.
Qual è la differenza tra opzioni e attributi EShop durante la preparazione?
Le opzioni possono rappresentare valori selezionabili dall’acquirente e avere SKU, prezzo o immagini separati. Gli attributi descrivono caratteristiche Product e spesso sostengono filtri o confronto. Definizioni e assegnazioni Product dovrebbero restare separate.
Perché allegati Product e schede aggiuntive devono essere inventariati?
Gli allegati possono contenere manuali, specifiche, download o file di supporto, mentre le schede aggiuntive possono contenere contenuti specifici del Product. Copiare soltanto la descrizione principale può omettere informazioni commercialmente importanti.
Come devono essere preparate le identità Customer registrato e non registrato?
Registrare collegamenti tra utenti Joomla e Customers EShop, email, indirizzi, gruppi, campi personalizzati del processo di acquisto, ID esterni e relazioni Order. Lo storico non registrato dovrebbe restare evidenza a livello Order anziché essere forzato in nuovi account.
Quali Orders EShop dovrebbero essere scelti come campioni rappresentativi?
Includere Orders ordinari e Orders di clienti non registrati, Products con opzioni, sconti, Coupons, Tax o valute multiple, download, fatture, rimborsi o rettifiche, tracking e riferimenti esterni usati dalle operazioni o dalla finanza.
Come dovrebbero essere divise le attività di preparazione tra Joomla ed EShop?
La preparazione Joomla possiede contenuti CMS generali, utenti, menu, moduli, template e architettura degli accessi. La preparazione EShop possiede Products, opzioni, Customers, Orders, prezzi, stock ed estensioni e documenta soltanto le dipendenze Joomla richieste da questi record.