Bagisto non tratta un catalogo e-commerce come una raccolta piatta di Products e campi personalizzati. La sua architettura basata su Laravel separa tipi di Product, attributi Product, attribute family, Categories, canali, lingue, valute, fonti di inventario, Customer Groups, Orders, CMS Pages, record di marketing, pacchetti, API e livelli e-commerce opzionali come marketplace o funzionalità B2B. Un campo dello store di origine diventa utile in Bagisto soltanto quando raggiunge la struttura che possiede il suo significato commerciale.
Questa distinzione cambia l’ambito della migrazione. Un valore di taglia può essere contenuto descrittivo, attributo filtrabile o parte della relazione di un configurable Product. Una quantità può appartenere a una specifica fonte di inventario invece che al Product nel suo complesso. Una vetrina può corrispondere a un canale Bagisto con propria root Category, lingua, valuta, tema e assegnazione di inventario. Un account Company o un record venditore può dipendere da un pacchetto Bagisto installato anziché dal modello Customer principale.
La domanda centrale non è quindi se Bagisto disponga di un campo con un’etichetta simile. È se lo store di destinazione rappresenti la stessa relazione: a cosa appartiene il record, cosa controlla e quali altri record devono restare collegati affinché i dati migrati mantengano il loro significato aziendale.
Bagisto traduce i record attraverso più livelli e-commerce
Bagisto combina entità e-commerce principali con configurazioni e strutture possedute dalle estensioni. Due valori affiancati in un export della sorgente possono appartenere a livelli diversi sul target. L’identità Product appartiene al catalogo. I campi disponibili per quel Product sono governati dalla sua attribute family. L’ambito della vetrina appartiene ai canali. La responsabilità dello stock appartiene alle fonti di inventario. La segmentazione Customers appartiene ai Customer Groups o a un livello B2B/marketplace installato. La presentazione può appartenere a CMS Pages, temi o a una vetrina headless.
| Significato nella sorgente | Probabile struttura responsabile in Bagisto | Conseguenza della traduzione |
|---|---|---|
| Articolo vendibile | Product con tipo Product definito | Il tipo determina record figli, scelte di acquisto, evasione ordini e comportamento dei prezzi. |
| Specifica Product | Attributo assegnato tramite attribute family | Un valore di testo visibile non diventa automaticamente filtrabile, confrontabile o riutilizzabile. |
| Store, mercato o dominio | Canale con lingua, valuta, root Category, tema e relazioni di inventario | L’ambito della vetrina deve restare collegato al catalogo e al contesto di localizzazione corretti. |
| Quantità di magazzino | Assegnazione e quantità della fonte di inventario | Un numero stock globale può perdere la responsabilità della sede. |
| Segmento Customer | Customer Group o struttura account posseduta da un pacchetto | Il significato di prezzi e accesso può non rientrare in un singolo campo Customer. |
| Vendita storica | Order con righe, totali, indirizzi, fatture, spedizioni, rimborsi e transazioni | Il solo conteggio Orders non mantiene la storia commerciale. |
| Funzionamento e-commerce personalizzato | Pacchetto Bagisto, modulo personalizzato, record posseduto da API o sistema esterno | La semplice mappatura verso campi core non basta quando un altro componente possiede la relazione. |
Questa responsabilità distribuita rende inaffidabile una mappatura uno-a-uno dei campi. Lo stesso valore di origine può richiedere una destinazione Bagisto diversa a seconda che controlli selezione Product, gestione del catalogo, localizzazione, inventario, trattamento dell’account, reporting o continuità delle integrazioni.
I tipi di Product definiscono le relazioni vendibili
Bagisto supporta diversi tipi di Product, tra cui simple, configurable, virtual, bundle, grouped, downloadable e Products orientati alle prenotazioni. Il tipo Product non è soltanto un’etichetta dell’Admin: definisce cosa viene venduto, se esistono Products figli o collegati, quali campi hanno significato, come vengono interpretati prezzo e stock e cosa seleziona l’acquirente.
Un Product padre di origine con figli per colore e taglia può diventare un configurable Product le cui varianti mantengono SKU, prezzi, quantità, immagini o visibilità proprie. Un kit è adatto a un bundle soltanto se componenti e regole di selezione corrispondono alla relazione bundle di Bagisto. Un grouped Product rappresenta un insieme di Products vendibili collegati, non un unico SKU con inventario. Un downloadable Product richiede relazioni con file e diritti di accesso. Un Product orientato alle prenotazioni aggiunge disponibilità e pianificazione che non esistono in una normale riga Product.
| Modello della sorgente | Relazione Bagisto da distinguere | Implicazione sull’ambito |
|---|---|---|
| Product padre con SKU figli | Configurable Product e varianti | Contenuto del padre e valori commerciali dei figli non devono essere appiattiti. |
| Kit con componenti opzionali | Bundle Product e selezioni bundle | Scelta dei componenti, quantità e comportamento dei prezzi possono richiedere traduzione strutturale. |
| Set di merchandising composto da articoli indipendenti | Grouped Product e Products collegati | Ogni Product collegato resta vendibile e gestito a inventario in modo indipendente. |
| Servizio non fisico | Virtual Product o struttura posseduta da un pacchetto | Il significato di spedizione ed evasione è diverso da quello dei Products fisici. |
| Articolo digitale | Downloadable Product, file, link e regole di accesso | La relazione con il file è distinta dal testo Product. |
| Servizio o noleggio programmato | Booking Product o struttura di pacchetto personalizzata | Disponibilità e risorse non possono essere rappresentate come semplici opzioni. |
La decisione sul tipo Product influenza anche lo storico Orders. Una riga Order deve rimanere comprensibile anche se il target rappresenta il Product in modo diverso dalla sorgente. Mantenere il nome Product senza conservare variante scelta, selezione bundle, download o contesto di prenotazione produrrebbe uno storico tecnicamente presente ma semanticamente incompleto.
Attributi e attribute family governano il significato del catalogo
Gli attributi Bagisto definiscono informazioni Product strutturate. Le attribute family raggruppano gli attributi disponibili per una classe di Products. I campi personalizzati del catalogo di origine non devono quindi essere copiati indiscriminatamente in un unico modello Product universale.
Un campo usato per il filtraggio richiede un trattamento diverso da uno usato soltanto come riferimento interno. Un valore che crea una scelta configurabile deve essere distinto da una specifica descrittiva. Titolo localizzato, prezzo, SKU univoco, flag booleano della vetrina e specifica tecnica multi-select non condividono lo stesso tipo di input, validazione, indicizzazione o comportamento per canale e lingua.
La progettazione delle attribute family trasforma quindi le convenzioni del catalogo di origine in uno schema governato dello store di destinazione. Un’azienda che vende abbigliamento, macchinari, manuali scaricabili e servizi prenotabili può richiedere family separate perché ogni gruppo Product necessita di attributi e relazioni commerciali differenti.
| Funzione del campo nella sorgente | Interpretazione Bagisto | Cosa deve restare vero |
|---|---|---|
| L’acquirente sceglie il valore | Attributo configurabile o scelta specifica del tipo Product | Il valore selezionato identifica la variante o il risultato vendibile corretto. |
| Il cliente filtra in base al valore | Attributo Product filtrabile | I valori restano normalizzati abbastanza da produrre filtri utili. |
| Il personale confronta Products tramite il valore | Attributo strutturato o confrontabile | Fatti equivalenti non rimangono nascosti nelle descrizioni. |
| Il campo vale soltanto per una classe Product | Attributo assegnato a una family specifica | Products non correlati non vengono forzati in uno schema universale sovraccarico. |
| Il valore varia per lingua o canale | Dato localizzabile o con ambito di canale dove supportato | Il contesto di vetrina corretto riceve il valore corretto. |
| Il valore è metadato interno di integrazione | Attributo personalizzato, record di pacchetto o identificatore esterno | Gli identificatori operativi non vengono esposti o riutilizzati come contenuto di vetrina. |
Questa separazione evita una distorsione frequente: trattare opzioni, specifiche, tag, campi di app e codici interni come lo stesso tipo di attributo Product. Bagisto può contenere dati Product ricchi, ma il valore di questa flessibilità dipende dall’assegnare ogni informazione alla family e al funzionamento corretti.
Categories, canali, lingue, valute e fonti di inventario definiscono l’ambito della vetrina
Le Categories organizzano i Products, ma le relazioni con i canali determinano quale catalogo e quale contesto di localizzazione utilizza una vetrina. Un canale può includere hostname, root Category, lingue, valute, tema e assegnazioni delle fonti di inventario. Di conseguenza, uno store regionale, un sito per lingua o una vetrina per business unit della sorgente può richiedere più di un semplice albero Category.
Le Categories possono rappresentare navigazione per l’acquirente, landing page di merchandising, classificazione interna o struttura legacy. Bagisto deve ricevere le relazioni che restano utili, non ogni etichetta Category storica. La root Category assegnata a un canale è particolarmente importante perché definisce la parte superiore della gerarchia di catalogo di quella vetrina.
Le fonti di inventario aggiungono una dimensione separata di responsabilità. Un Product può avere stock distribuito su più sedi. La quantità di origine deve quindi essere letta insieme al contesto di magazzino, filiale, fornitore, punto di ritiro o evasione. Sommare tutte le ubicazioni in un unico numero può mantenere le unità totali ma distruggere la disponibilità per sede.
| Livello di ambito | Relazione rappresentata in Bagisto | Ambiguità tipica della sorgente |
|---|---|---|
| Category | Gerarchia padre-figlio, assegnazioni Product, contenuto localizzato e significato URL | Le Categories di origine possono mescolare navigazione, SEO e classificazione interna. |
| Canale | Dominio, root Category, lingua, valuta, tema e contesto delle fonti di inventario | Uno “store” della sorgente può essere in realtà mercato, lingua, brand o business unit. |
| Lingua | Valori tradotti di Product, Category e contenuti | Le traduzioni possono essere record duplicati o campi, anziché relazioni collegate. |
| Valuta | Visualizzazione della vetrina e contesto commerciale | La valuta degli Orders storici deve restare distinta dalla configurazione corrente del canale. |
| Fonte di inventario | Stock posseduto dalla sede | Una quantità Product può nascondere diversi magazzini o pool di stock. |
Un Product può esistere correttamente in Bagisto e restare invisibile o commercialmente errato se è collegato alla root Category sbagliata, non disponibile nel canale previsto, privo dei valori localizzati oppure assegnato alla fonte di inventario errata. Sono errori di relazione anche quando tutti i record Product sono presenti.
Customers, gruppi, venditori marketplace e account B2B sono identità differenti
I record Customer core di Bagisto comprendono identità, contatti, indirizzi e relazioni di gruppo. I Customer Groups possono influenzare il trattamento commerciale, inclusi prezzi di gruppo e idoneità alle regole. Tuttavia, venditori marketplace, Company B2B, utenti Company, ruoli di approvazione, requisition list, preventivi e purchase Orders possono appartenere a pacchetti Bagisto opzionali invece che al record Customer principale.
Un tag Customer di origine come wholesale, dealer, distributor, employee, tax-exempt, approved buyer o marketplace seller deve essere interpretato per funzione. Alcuni valori appartengono a un Customer Group core. Altri rappresentano account Company, organizzazione venditore, ruolo di permesso, relazione di credito o classificazione CRM esterna. Appiattirli in un campo di testo mantiene l’etichetta ma elimina la relazione che la rendeva operativa.
| Identità di origine | Domanda sulla destinazione Bagisto | Relazione da mantenere |
|---|---|---|
| Cliente individuale | Customer core e indirizzi | Identità, contatti, associazione account e storico Orders. |
| Segmento commerciale | Customer Group o relazione di prezzo | Il segmento resta distinto da tag arbitrari. |
| Acquirente aziendale | Company B2B e struttura utenti Company quando presente | Gli utenti restano collegati a Company, ruolo e contesto commerciale corretti. |
| Venditore marketplace | Record seller/vendor posseduto dal pacchetto marketplace | Products, Orders, commissioni, payout e utenti del venditore restano collegati. |
| Account ERP o CRM esterno | Customer più identificatore esterno | Il target può riconciliare il Customer con l’account autorevole esterno. |
La destinazione corretta dipende dall’installazione Bagisto effettiva. Bagisto core, Multi Vendor Marketplace, B2B Marketplace, B2B eCommerce e pacchetti multi-tenant non espongono un unico schema Customer universale. I loro record devono essere trattati come domini di responsabilità distinti.
Gli Orders mantengono il contesto commerciale storico
Un Order Bagisto è collegato a identità Customer o senza account, indirizzi, righe Order, configurazioni Product selezionate, prezzi, sconti, imposte, spedizione, etichette di pagamento, stati, fatture, spedizioni, rimborsi e transazioni. Questi record spiegano cosa è accaduto; l’header Order da solo non basta.
Gli Orders storici contengono anche snapshot. Nomi Product, prezzi, imposte, indirizzi e opzioni selezionate possono riflettere il momento dell’acquisto anche se Product o Customer correnti sono cambiati. Sostituire questi snapshot con valori attuali altererebbe la storia. Al contrario, importare soltanto i totali senza dettagli delle righe e contesto degli stati renderebbe inaffidabili assistenza e reporting.
| Relazione Order | Significato storico |
|---|---|
| Riga Order | Identità Product, SKU, quantità, prezzo, configurazione selezionata e snapshot descrittivo. |
| Indirizzo | Informazioni di fatturazione e spedizione al momento dell’acquisto. |
| Fattura | Importo riconosciuto o fatturato, che può differire dalla fase del ciclo di vita dell’Order. |
| Spedizione | Record di evasione e quantità spedite. |
| Rimborso | Valore stornato e righe o importi interessati. |
| Transazione | Riferimento del sistema di pagamento ed evidenza dello stato quando disponibile. |
| Stato Order | Significato del ciclo di vita nella sorgente che può richiedere un equivalente deliberato sul target. |
L’ambito deve mantenere il livello di dettaglio Order necessario per assistenza Customer, storico account, reporting e riconciliazione con sistemi esterni. Pagamento, spedizione, imposte e notifiche correnti appartengono alla configurazione dello store di destinazione; etichette e importi storici appartengono al contesto dell’Order migrato.
CMS, URL, record di marketing e ricerca hanno responsabilità separate
Bagisto include CMS Pages, riscritture URL, sitemap, termini e sinonimi di ricerca, iscrizioni newsletter, Reviews, cart rules e catalog rules. Questi record non devono essere riuniti in una generica categoria “contenuti” perché servono a scopi differenti.
Le CMS Pages contengono contenuto e identità URL. I metadati Product e Category appartengono ai relativi record del catalogo. Le riscritture URL mantengono relazioni di percorso. Termini e sinonimi influenzano la ricerca. Le Reviews appartengono a Customers e Products. Le iscrizioni newsletter rappresentano consenso e pubblico. Cart rules e catalog rules codificano condizioni e azioni, non semplici valori di sconto.
| Risorsa di origine | Struttura responsabile in Bagisto | Confine di traduzione |
|---|---|---|
| Pagina informativa | CMS Page | Contenuto, percorso, metadati e relazione di navigazione sono aspetti distinti. |
| Metadati Product o Category | Record del catalogo | I campi SEO devono restare collegati all’entità e alla lingua corrette. |
| URL o redirect legacy | URL rewrite o struttura di redirect | Relazione tra vecchio percorso e destinazione deve restare esplicita. |
| Sinonimo di ricerca | Record search synonym | Una coppia di keyword non è normale contenuto di pagina. |
| Product Review | Relazione Product-Customer | Rating, autore, stato e associazione Product sono rilevanti. |
| Regola promozionale | Cart rule o catalog rule | Condizioni, azioni, date, canali e Customer Groups formano un’unica struttura. |
I record di marketing sono particolarmente sensibili alla perdita di significato. Un Coupon senza condizioni di idoneità, date, ambito Customer, storico d’uso o azione di sconto non rappresenta la stessa promozione in Bagisto. Dove non esiste una struttura equivalente, il record va conservato come evidenza storica o ridisegnato nella configurazione di destinazione, non forzato in una mappatura ingannevole.
Pacchetti, API, vetrine headless e tabelle personalizzate estendono il modello
Bagisto è progettato per essere esteso tramite pacchetti Laravel, tipi di Product personalizzati, moduli, API REST o GraphQL, webhook o codice di integrazione e vetrine headless. Queste capacità creano dati che possono non apparire nelle tabelle core di Product, Customer o Order.
Un pacchetto può introdurre entità, relazioni pivot, configurazioni, stati, permessi e identificatori esterni propri. Una vetrina headless può utilizzare i dati core Bagisto mantenendo altrove composizione delle pagine o indici di ricerca. ERP, PIM, WMS, CRM, connettori marketplace o app mobili possono considerare Bagisto soltanto un partecipante in un sistema dati più ampio.
| Responsabile dei dati | Esempi | Implicazione per la migrazione |
|---|---|---|
| Bagisto core | Products, Categories, Customers, Orders, attributi, canali, fonti di inventario | Mappare secondo la semantica nativa di entità e relazioni. |
| Pacchetto installato | Venditori marketplace, Company B2B, risorse booking, abbonamenti, tipi Product personalizzati | Ispezionare lo schema del pacchetto e mantenere i collegamenti ai record core. |
| Modulo Laravel personalizzato | Tabelle su misura, campi, record di flusso o storico eventi | Definire per ogni relazione attiva una destinazione o una decisione di archiviazione. |
| Livello di presentazione headless | Composizione pagina, indice di ricerca, contenuti frontend, identificatori cache | Non presumere che la presentazione della vetrina sia memorizzata nel core Bagisto. |
| Sistema esterno | ID articolo ERP, ID account CRM, codice magazzino, ID listing marketplace | Mantenere gli identificatori necessari per ricollegare il target al sistema autorevole. |
La domanda decisiva è chi possiede il dato. Un valore memorizzato vicino a un Product non appartiene automaticamente al Product. Può appartenere a un pacchetto, un sistema esterno o un livello di presentazione. L’ambito è completo soltanto quando queste relazioni sono nominate e viene definita una destinazione per i record che restano operativamente necessari.
Decisioni di traduzione in base al significato aziendale
La decisione finale sul modello dati deve collegare ogni modello della sorgente alla struttura Bagisto responsabile e alla conseguenza di una responsabilità errata.
| Modello della sorgente | Domanda corretta | Conseguenza di un’ipotesi errata |
|---|---|---|
| Opzioni con SKU figli e stock | È una relazione configurable Product? | Identità variante, inventario o prezzo diventano inesatti. |
| Specifiche riutilizzate per una classe Product | Appartengono ad attributi e attribute family? | Filtraggio e governance del catalogo restano incoerenti. |
| Store regionali separati | Sono canali, lingue, valute o installazioni indipendenti? | Products e contenuti appaiono nel contesto di vetrina sbagliato. |
| Quantità per magazzino | Quale fonte di inventario possiede ogni quantità? | Il totale può essere corretto mentre la disponibilità per sede è errata. |
| Customers wholesale o aziendali | Il significato è gruppo, Company B2B, utente Company o account esterno? | Prezzi, accesso e relazioni account vengono appiattiti. |
| Products e Orders posseduti da venditori | Un pacchetto marketplace possiede la relazione seller? | Scompaiono responsabilità del vendor, commissioni e payout. |
| Campi personalizzati di un pacchetto | Quale entità del pacchetto e quale record core sono collegati? | I dati vengono copiati senza il flusso che li utilizza. |
Una migrazione Bagisto diventa coerente quando Products, attributi, canali, inventari, Customers, Orders, contenuti, pacchetti e identificatori esterni vengono tradotti come strutture collegate. In questo modo si mantiene non soltanto la presenza dei dati, ma il significato commerciale necessario al funzionamento dello store di destinazione.
Conclusione
La migrazione verso Bagisto richiede la traduzione delle relazioni tra catalogo, vetrina, inventario, Customer, Order, contenuti, estensioni e integrazioni. I tipi Product definiscono strutture vendibili. Le attribute family governano le informazioni Product. I canali collegano catalogo, localizzazione e inventario. Customer Groups e pacchetti B2B o marketplace opzionali definiscono relazioni account differenti. Gli Orders dipendono da righe, snapshot, fatture, spedizioni, rimborsi e transazioni. Pacchetti e sistemi esterni possono possedere dati che il core Bagisto non gestisce.
Le decisioni più solide identificano il responsabile di ogni valore commercialmente importante e mantengono i collegamenti tra record. Una mappatura basata soltanto sui nomi dei campi può nascondere perdite semantiche dietro la flessibilità di Bagisto. Una mappatura basata su funzione e relazione fornisce invece al target un catalogo e uno storico commerciale ancora comprensibili e utilizzabili.
Domande frequenti
In cosa differiscono i configurable Products Bagisto dalle normali opzioni Product?
Un configurable Product collega un Product padre a varianti vendibili create da attributi scelti. Le varianti possono avere SKU, prezzo, quantità, immagine o visibilità propri. Un’opzione testuale che non identifica una variante gestita indipendentemente non deve diventare automaticamente la stessa struttura.
Perché le attribute family sono importanti durante una migrazione Bagisto?
Determinano quali attributi appartengono a una classe Product. Evitano che ogni Product riceva un insieme di campi sovradimensionato e mantengono la differenza tra specifiche di abbigliamento, dati tecnici, contenuti scaricabili, dettagli di prenotazione e altre informazioni specifiche.
Uno store di origine può sempre diventare un singolo canale Bagisto?
No. Uno “store” può rappresentare dominio, lingua, valuta, brand, regione, catalogo o business unit indipendente. Il modello corretto può usare un canale con più lingue, diversi canali oppure installazioni separate, a seconda delle relazioni che devono restare indipendenti.
Come deve essere rappresentato lo stock di magazzino in Bagisto?
Quando la sede conta, lo stock deve mantenere la responsabilità della fonte di inventario. Sommare tutte le quantità in un totale Product può eliminare contesto di magazzino, ritiro, fornitore o evasione pur mantenendo corretto il numero aggregato.
Venditori marketplace e Company B2B sono normali Customers Bagisto?
Non necessariamente. Le relazioni seller e Company possono essere possedute da pacchetti marketplace o B2B e includere utenti organizzativi, ruoli, cataloghi, commissioni, payout, credito, preventivi o purchase Orders che non rientrano nel record Customer core.
Come devono essere trattati i dati di pacchetti o moduli personalizzati Bagisto?
Identificare pacchetto o modulo, record core estesi e processo aziendale che utilizza i dati. Le relazioni attive richiedono una destinazione esplicita e identificatori mantenuti; i record obsoleti possono essere archiviati o esclusi senza fingere che siano campi Product o Customer nativi.