Migrare verso ShopWired non significa soltanto spostare Products, Customers, Orders, Categories, Reviews, Coupons e record CMS in una nuova area amministrativa. ShopWired utilizza una struttura e-commerce specifica per Products, Categories, marchi, varianti, scelte, extra, stock, identità Customer, funzionalità B2B, configurazione del checkout, impostazioni IVA e imposte sulle vendite, regole di consegna, app, comportamento API e presentazione del sito pubblico governata dal tema. Un buon piano di migrazione deve tradurre i dati dell’origine in questa struttura senza perdere il significato aziendale dei record.
La domanda centrale è semplice: quando un record dell’origine arriva in ShopWired, l’azienda continuerà a comprenderne il significato e il negozio continuerà a utilizzarlo correttamente? Un’opzione Product che prima era una semplice etichetta può dover diventare una variante, una scelta, un extra, un bundle, un campo di personalizzazione o un comportamento gestito da un’app. Un segmento Customer può diventare un record Customer, un iscritto alla newsletter, un Customer B2B, un gruppo di prezzo o un campo personalizzato. Un Order storico può restare leggibile per l’assistenza, ma non configura automaticamente checkout, consegna, pagamento, IVA, imposte sulle vendite o comportamento B2B per le transazioni future.
Il significato dei dati ShopWired diventa più chiaro quando il trasferimento dei record viene separato dalla ricostruzione operativa. Ogni valore deve essere interpretato in base alla funzione commerciale o operativa che deve continuare a supportare: guidare l’esplorazione del catalogo, controllare le combinazioni acquistabili, mantenere la cronologia Customer, supportare account B2B, spiegare Orders storici, mantenere la visibilità sui motori di ricerca, collegare sistemi esterni o sostenere il merchandising continuativo.
Priorità nella traduzione del modello dati di ShopWired
La pianificazione del modello dati dovrebbe iniziare dalle aree che possono modificare più direttamente il significato aziendale: configurazione Product, identità Customer, comportamento B2B, interpretazione degli Orders, scoperta dei Products sul sito pubblico e dipendenze dai sistemi esterni. Questi elementi determinano se il negozio migrato è soltanto popolato di record o realmente utilizzabile.
| Area del negozio di origine | Interpretazione in ShopWired | Domanda di pianificazione |
|---|---|---|
| Varianti e opzioni Product | Varianti, scelte, extra, bundle, dati di testo/file o comportamento di app | L’opzione dell’origine modifica SKU, prezzo, stock, consegna, imposte oppure soltanto la presentazione? |
| Struttura di Categories e marchi | Scoperta Product, navigazione, filtri, SEO e logica di merchandising | I Customers riescono ancora a trovare i Products prioritari attraverso i percorsi previsti? |
| Record Customer | Identità Customer basata sull’email, stato account, cronologia Orders, note, campi personalizzati e separazione B2B | Record duplicati, guest, B2B e registrati mantengono il significato corretto? |
| Gruppi Customer e account B2B | Visibilità B2B, prezzi, comportamento account e regole operative | Quali regole sono dati, quali appartengono alla configurazione ShopWired e quali richiedono revisione personalizzata? |
| Orders storici | Cronologia Customer, etichette di pagamento e consegna, valori fiscali, note Order, contesto di evasione ordini e riferimenti esterni | Gli Orders storici restano utili per assistenza e reportistica dopo la migrazione? |
| Contenuti e asset SEO | Pagine, landing page, Blog Posts, menu, redirect, metadati e visualizzazione controllata dal tema | Quali contenuti influenzano ricerca, fiducia, conversione o onboarding B2B? |
| App e integrazioni | Responsabilità sui dati esterni, comportamento API/webhook, feed stock, contabilità, evasione ordini, email, marketplace o CRM | Quali sistemi collegati devono essere riconfigurati, mappati, ricostruiti o esclusi? |
Questa prospettiva evita un errore comune: presumere che basti trovare campi con nomi simili. La somiglianza tra campi non garantisce equivalenza operativa. In ShopWired, il significato dipende da come il record partecipa alla selezione Product, al riconoscimento Customer, alla vendita B2B, al checkout, all’evasione ordini, al calcolo fiscale e alla presentazione del sito pubblico. Prima di definire la mappatura a livello di campo, una buona mappa di responsabilità collega quindi ogni valore al relativo Product, variante, Customer, account B2B, Quote, Order, record di contenuto, applicazione o sistema esterno.
Products, Categories, marchi e dati per la scoperta
I Products di ShopWired sono collegati a Categories, marchi, varianti, scelte, extra, stock, prezzi, immagini, parole chiave di ricerca, filtri, URL e relazioni di merchandising. Un catalogo di origine può conservare questi aspetti in Products, collezioni, tag, attributi, produttori, blocchi di un editor visuale di pagine o record di applicazioni. Nella destinazione, ogni significato deve essere assegnato alla struttura ShopWired che ne è realmente responsabile.
Le Categories forniscono organizzazione gerarchica dei Products, mentre i marchi identificano il produttore o il brand. I filtri Product possono esporre valori strutturati utili al confronto. Le parole chiave di ricerca influenzano la scoperta senza diventare Categories visibili. Un tema può visualizzare questi record, ma la presentazione non ne diventa il proprietario autorevole.
| Concetto del catalogo di origine | Responsabile in ShopWired | Conseguenza per la migrazione |
|---|---|---|
| Reparto o gerarchia stabile | Category e struttura padre-figlio | Mantenere appartenenza Product e significato duraturo della navigazione. |
| Produttore o marchio | Relazione Brand | Tenere l’identità del marchio separata da una Category generica o una specifica. |
| Attributo tecnico usato per restringere i risultati | Filtro Product o campo strutturato | Mantenere il valore di confronto senza creare varianti artificiali. |
| Sinonimo interno per la ricerca | Parola chiave di ricerca Product | Migliorare la reperibilità senza mostrare il termine come contenuto di catalogo. |
| Collezione promozionale | Category, landing page, promozione o relazione di presentazione curata | Seguire lo scopo commerciale invece dell’etichetta usata nell’origine. |
| Immagine principale e galleria | Relazione media Product/variante | Mantenere il ruolo dell’immagine e i media specifici della variante quando cambia la combinazione acquistabile. |
L’identità Product resta utile sul piano commerciale soltanto quando il team può determinare cosa viene venduto, dove compare, quale marchio o Category lo possiede, come viene trovato e quale record di stock e prezzo controlla l’articolo acquistabile.
Varianti, scelte, extra e significato della configurazione Product
ShopWired distingue varianti, scelte, extra, testo personalizzato, caricamenti di file, bundle, preordini, abbonamenti e altri comportamenti Product. Le piattaforme di origine chiamano spesso tutti questi elementi “opzioni”, ma le relazioni non sono equivalenti.
Una variante rappresenta una combinazione acquistabile e può possedere SKU, prezzo, stock, immagine, peso, GTIN, MPN e significato relativo all’IVA. Una scelta o un extra può aggiungere una selezione o un costo facoltativo senza creare la stessa identità gestita a inventario. I dati di testo e file conservano informazioni fornite dal Customer. Un bundle collega un’offerta ad altri record Product. Preordini e abbonamenti aggiungono relazioni temporali e transazionali che vanno oltre il catalogo statico.
| Comportamento nell’origine | Responsabile in ShopWired | Significato da mantenere |
|---|---|---|
| Combinazione taglia/colore con SKU o stock propri | Variante | Identità acquistabile, prezzo, inventario, immagine, peso e identificativi esterni a livello di combinazione. |
| Upgrade facoltativo o confezione regalo | Scelta o extra | Selezione facoltativa ed effetto sul prezzo senza creare falso inventario di variante. |
| Testo per incisione | Dato di testo personalizzato Product e fotografia del valore nella riga Order | Valore inserito dal Customer collegato alla riga acquistata. |
| File grafico o documento del Customer | Relazione di caricamento file e fotografia nella riga Order | Responsabilità sul file del Customer, sicurezza e visibilità per l’evasione ordini. |
| Kit o confezione multipla | Bundle o relazione Product-to-Product | Identità dei componenti, quantità, responsabilità sullo stock e significato negli Orders storici. |
| Product in preordine o abbonamento | Product più relazione temporale/Order | Contesto di rilascio, fatturazione, rinnovo o account non contenuto nei soli campi Product. |
| Configuratore condizionale | Logica posseduta dall’applicazione | Separare le selezioni dell’origine e i dati Order risultanti dall’applicazione che li ha generati. |
Questa distinzione previene due errori opposti: creare varianti per dati descrittivi o facoltativi e appiattire combinazioni con inventario proprio in semplice testo. Gli identificativi esterni devono restare collegati al livello Product o variante riconosciuto da magazzino, contabilità, feed e sistemi marketplace.
Dati Customer, account e marketing
ShopWired distingue profili Customer, iscritti alla newsletter, Customers B2B, punti premio, relazioni referral, provenienza dei Customers e dati Customer creati dalle applicazioni. L’email è una chiave importante per l’identità, ma email duplicate, Orders guest, account legacy e relazioni B2B possono rendere rischioso un abbinamento uno-a-uno.
Un record Customer può possedere recapiti, indirizzi, stato account, cronologia Orders, note e campi personalizzati. Lo stato newsletter rappresenta una relazione di comunicazione, non un’identità Customer sostitutiva. Lo stato B2B aggiunge significato relativo a prezzi e accesso. I punti premio formano un registro collegato al Customer. Tag di applicazioni o identificativi CRM possono restare di proprietà di sistemi esterni.
| Modello di identità nell’origine | Decisione di relazione in ShopWired |
|---|---|
| Acquirente al dettaglio registrato | Profilo Customer collegato a indirizzi e Orders storici. |
| Acquirente guest | Identità e indirizzi a livello Order senza inventare un account permanente. |
| Contatto iscritto soltanto alla newsletter | Relazione di iscrizione separata dall’account acquirente, salvo che i record rappresentino realmente la stessa persona. |
| Acquirente B2B approvato | Customer B2B più relazioni di prezzo, visibilità, imposte e account che danno significato all’approvazione. |
| Account duplicati nell’origine | Consolidare solo quando identità, consenso, indirizzi e responsabilità sugli Orders supportano la decisione. |
| Saldo premi o referral | Record di programma collegato al Customer, non nota Customer generica. |
| ID CRM o marketing | Identificativo esterno collegato al record Customer o iscritto riconosciuto dal sistema connesso. |
Il modello di destinazione non dovrebbe dedurre consenso, approvazione B2B o proprietà dell’account da un nome condiviso. Deve mantenere la relazione che rendeva il record operativo nell’origine.
Dati B2B, trade, Quote e prezzi
Le strutture B2B di ShopWired includono Customers B2B, Categories e Products riservati al B2B, prezzi B2B, fasce di prezzo, prezzi individuali, sconti globali, Quotes e relativo comportamento account. Sono record collegati, non attributi contenuti in una singola riga Customer.
L’identità dell’acquirente appartiene al Customer o Customer B2B. La regola commerciale può appartenere a una fascia di prezzo, un prezzo B2B specifico del Product, un’eccezione individuale, uno sconto globale, una relazione di visibilità o un Quote. Quotes e Orders storici mantengono gli esiti negoziati; la configurazione B2B corrente definisce il comportamento futuro degli acquisti.
| Elemento B2B nell’origine | Responsabile in ShopWired | Significato della relazione |
|---|---|---|
| Account aziendale approvato | Customer B2B | Identità dell’acquirente e stato B2B approvato. |
| Fascia all’ingrosso | Fascia di prezzo B2B o sconto globale | Trattamento commerciale condiviso per una classe di Customers B2B. |
| Prezzo contrattuale | Prezzo individuale del Customer B2B o altra relazione Product-Customer | Eccezione specifica dell’account al corretto livello Product o variante. |
| Assortimento riservato al B2B | Relazione di visibilità Product/Category | Quali acquirenti approvati possono trovare e acquistare l’articolo. |
| Quote | Record Quote collegato a Customer, Products, prezzi, note, stato e, quando applicabile, Order successivo | Fotografia commerciale negoziata, non normale carrello. |
| Condizioni da ordine di acquisto | Contesto Customer/Quote/Order più configurazione del pagamento nella destinazione | Termini storici e valori di riferimento separati dal comportamento attivo del checkout. |
| Stato IVA | Customer B2B e relazione fiscale | Prove relative all’acquirente e trattamento commerciale non devono essere ridotti a una semplice etichetta. |
Un Customer Group dell’origine, quindi, non è sufficiente da solo. Il suo significato nel modello dati è la rete di prezzi, Products, regole di visibilità, cronologia Quote, condizioni commerciali e trattamento fiscale collegata al gruppo.
Orders, stati Order, Quotes e contesto delle transazioni
Un Order ShopWired registra ciò che è avvenuto in una transazione. Le sue relazioni possono includere identità Customer o guest, righe Product e variante, scelte, extra, dati di personalizzazione, prezzi, voucher, consegna, etichette di pagamento, IVA o imposte sulle vendite, stati, note, rimborsi, resi, abbonamenti, Quotes e riferimenti a sistemi esterni.
I valori storici degli Orders sono fotografie della transazione. Non devono essere ricalcolati secondo prezzi Product o impostazioni fiscali correnti. Un’etichetta di pagamento o consegna spiega l’Order passato ma non configura il gateway o la zona di consegna nella destinazione. Un campo personalizzato Order appartiene alla transazione salvo che lo stesso valore venga deliberatamente promosso a dato Customer o Product durevole.
| Relazione Order | Significato storico da mantenere |
|---|---|
| Assegnazione Customer o guest | Chi ha effettuato l’Order e quali indirizzi sono stati usati. |
| Riga Product/variante | Identità acquistata, SKU, scelte o extra selezionati, quantità e descrizione della riga. |
| Testo/file fornito dal Customer | Istruzione per l’evasione ordini collegata alla riga acquistata o all’Order. |
| Prezzo, sconto, voucher, IVA/imposta e totale | Fotografia finanziaria registrata al momento dell’acquisto. |
| Etichetta di pagamento e consegna | Contesto del metodo per assistenza e riconciliazione senza implicare configurazione attiva. |
| Stato, rimborso, reso e cronologia | Prova del ciclo di vita e delle modifiche alla transazione originale. |
| Riferimento Quote o abbonamento | Relazione con il processo commerciale che ha preceduto o seguito l’Order. |
| ID esterno | Chiave di riconciliazione per ERP, contabilità, evasione ordini, marketplace o CRM. |
Gli Orders restano utilizzabili quando il personale può interpretare la transazione anche se catalogo corrente, tema, stack applicativo o configurazione checkout sono cambiati.
Dati di checkout, consegna, pagamento, IVA e imposte sulle vendite
ShopWired separa i dati storici delle transazioni dalla configurazione che crea gli Orders futuri. Gli Orders precedenti possono contenere nomi di consegna, addebiti, etichette di pagamento, valori IVA o imposte sulle vendite, esenzioni e risposte personalizzate del checkout. Checkout corrente, zone e tariffe di consegna, metodi di ritiro, gateway di pagamento, zone IVA, aliquote personalizzate, regole B2B e applicazioni checkout sono record di configurazione separati.
| Valore storico nell’origine | Responsabile del dato | Relazione separata nella destinazione |
|---|---|---|
| Etichetta del metodo di pagamento e riferimento transazione | Order | Configurazione gateway e credenziali per le transazioni future. |
| Metodo e costo di consegna | Order | Zona, tariffa, restrizione, ritiro e configurazione del corriere. |
| Importo IVA o imposta sulle vendite | Fotografia finanziaria Order | Zone IVA, aliquote, esenzioni e impostazioni di calcolo correnti. |
| Prova di esenzione del Customer | Customer/Customer B2B o record di conformità esterno | Regola di destinazione che applica il trattamento agli Orders futuri. |
| Risposta a domanda di checkout | Campo Order o Customer in base allo scopo | Definizione del campo checkout e regola di visibilità. |
| Condizioni offline o riferimento ordine di acquisto | Customer B2B, Quote o Order | Configurazione corrente di condizioni di pagamento e approvazione. |
| Risultato di un’applicazione checkout | Dati Order posseduti dall’applicazione | Configurazione dell’applicazione nella destinazione e relazione dati supportata. |
Questa separazione mantiene dati storici e configurazione futura nei rispettivi ruoli: i record migrati spiegano le transazioni passate, mentre i record di configurazione descrivono come ShopWired creerà quelle future. Sono collegati, ma nessuno sostituisce l’altro. La stessa distinzione si applica a esenzioni Customer e condizioni B2B: l’Order storico mantiene ciò che è avvenuto, mentre la relazione Customer o B2B registra perché un trattamento analogo possa applicarsi in futuro.
Contenuti, SEO, menu e dati dipendenti dal tema
I contenuti ShopWired possono includere pagine del sito, landing page, Blog Posts, metadati Product e Category, redirect 301, menu ed elenchi di link, informazioni aziendali, immagini, file, Products in evidenza, domande e risposte Product e altri record del sito pubblico. I temi visualizzano questi record ma non ne diventano il proprietario autorevole.
Un blocco di un editor visuale di pagine nell’origine può combinare testo, immagini, riferimenti Product, moduli e widget applicativi in un unico oggetto visivo. Il modello di destinazione dovrebbe separare contenuti durevoli dalla configurazione della presentazione e dai riferimenti e-commerce dinamici.
| Asset dell’origine | Responsabile in ShopWired | Conseguenza per la migrazione |
|---|---|---|
| Pagina informativa su policy, servizi o B2B | Pagina del sito | Mantenere corpo, metadati, link, media e significato durevole dell’URL. |
| Landing page promozionale o editoriale | Landing page più riferimenti Product/contenuto | Separare il contenuto riutilizzabile dal layout specifico del tema. |
| Articolo blog | Blog Post | Mantenere titolo, corpo, media, contesto data/autore quando rilevante, metadati e link interni. |
| Dati SEO Product o Category | Product/Category più campi SEO | Tenere l’identità canonica dell’entità separata da redirect e posizione nei menu. |
| Voce di menu | Relazione menu/elenco link | La navigazione pubblica può puntare a Product, Category, pagina, Blog Post, URL esterno o campagna. |
| Redirect | Relazione redirect 301 | Mantenere il significato del percorso origine-destinazione senza trattare il vecchio URL come contenuto della pagina. |
| Sezione o widget del tema | Presentazione del tema/applicazione | Ricreare la presentazione separatamente dai contenuti o dati Product che visualizza. |
La responsabilità sui contenuti conta sia nell’esperienza B2B sia in quella al dettaglio. Una pagina di onboarding B2B, una raccolta di specifiche Product, una pagina di policy o una landing page ad alto valore possono mantenere significato aziendale anche quando il design visivo viene sostituito.
Dati di app, API, webhook e sistemi esterni
ShopWired espone applicazioni, credenziali API e webhook, e il suo ecosistema include connessioni a contabilità, evasione ordini, stock, marketplace, marketing, fiscalità, ricerca, abbonamenti e B2B. I dati di un’applicazione dell’origine non diventano dati nativi ShopWired solo perché nella destinazione esiste un’app con uno scopo simile.
Il modello di destinazione deve identificare il sistema autorevole per ogni valore operativo. Gli ID Product e variante possono essere riconosciuti da un ERP. Gli ID Customer possono appartenere a un CRM. I riferimenti Order e spedizione possono appartenere a sistemi di evasione ordini o contabilità. Il consenso degli iscritti può appartenere a una piattaforma marketing. Un webhook è configurazione; l’identificativo esterno trasportato dal payload è un dato.
| Dipendenza | Relazione autorevole |
|---|---|
| ID Product ERP o contabile | Product o variante riconosciuti dal sistema esterno. |
| Chiave del feed stock | Product/variante con inventario più sistema responsabile dello stock disponibile. |
| Riferimento evasione ordini | Relazione Order, spedizione o pacco riconosciuta da corriere o magazzino. |
| ID Customer/azienda CRM | Relazione Customer o Customer B2B al corretto livello account. |
| ID inserzione marketplace | Relazione Product/variante/canale, non descrizione Product generica. |
| Consenso e tag marketing | Iscritto/Customer più sistema marketing esterno responsabile dello stato. |
| Campo personalizzato dell’applicazione | Valore posseduto dall’app con Product, Customer, Order o Quote padre esplicito. |
| Credenziale API o sottoscrizione webhook | Configurazione sicura nella destinazione, non dati pubblicabili o Customer. |
Paginazione API, autenticazione e gestione degli errori influenzano lo scambio dei record tra sistemi, ma non modificano chi è responsabile del dato sottostante. La mappa di responsabilità dovrebbe quindi restare stabile anche quando l’implementazione dell’integrazione viene ricostruita.
Confini di responsabilità per dati personalizzati ed esterni
I dati personalizzati ed esterni di ShopWired dovrebbero essere organizzati per responsabilità, non attraverso etichette generiche di escalation. La decisione fondamentale è se il valore appartiene a un’entità nativa ShopWired, a un’applicazione ShopWired, alla configurazione della presentazione oppure a un sistema esterno.
| Segnale del dato | Responsabile nella destinazione | Definizione della relazione richiesta |
|---|---|---|
| Specifica Product usata per il filtro | Struttura Product/filtro | Nome attributo, valore, appartenenza Product e ruolo nella visualizzazione del sito pubblico. |
| ID magazzino a livello variante | Variante più ERP/magazzino | Combinazione acquistabile e record esterno che la riconosce. |
| Riferimento contrattuale del Customer B2B | Customer B2B più CRM/contabilità | Organizzazione, contatto, account commerciale e chiave del sistema esterno. |
| Campo personalizzato utilizzato soltanto nei Quote | Quote | Contesto di negoziazione o approvazione senza trasformarlo in attributo permanente del Customer. |
| Record di abbonamento o bundle creato dall’applicazione | Applicazione più Product/Order | Product padre, relazioni di fatturazione o componenti e riferimenti alle transazioni storiche. |
| Impostazione tema che seleziona Products | Presentazione del tema | I riferimenti Product restano autorevoli nel catalogo; l’impostazione controlla soltanto la visualizzazione. |
| Tabella personalizzata dell’origine non supportata | Entità padre definita o sistema esterno | Scopo aziendale, chiave padre, ciclo di vita e responsabile nella destinazione devono essere espliciti. |
Questo modello evita due errori: forzare ogni valore dell’origine nel campo nativo più vicino e mantenere dati personalizzati senza comprenderne la relazione padre. Un valore è utilizzabile solo quando il team sa quale record lo possiede, quale sistema lo riconosce e se descrive cronologia, commercio corrente o presentazione. La responsabilità dovrebbe restare stabile anche tra esportazioni e integrazioni. Quando un valore personalizzato viene duplicato in più sistemi, devono essere identificati una singola fonte autorevole e una chiave durevole di riconciliazione, così che gli aggiornamenti successivi non creino versioni conflittuali dello stesso fatto commerciale.
Conclusione
La pianificazione del modello dati ShopWired deve concentrarsi sul significato, non sulla corrispondenza dei campi. Le differenze più importanti emergono generalmente nella configurazione Product, nel comportamento B2B, nell’identità Customer, nella cronologia Orders, nel contesto di checkout, nei contenuti e asset SEO, nelle app, nei flussi API, negli ID esterni e nei campi personalizzati. Ogni area deve essere interpretata in base all’uso aziendale che deve continuare a svolgere, non soltanto alla possibilità di importare un record.
Un modello di destinazione ShopWired solido assegna ogni valore dell’origine a un Product, variante, Customer, relazione B2B, Quote, Order, record di contenuto, applicazione, livello di presentazione o sistema esterno. Questa mappa di responsabilità mantiene il significato commerciale senza confondere dati storici e configurazione futura.
Domande frequenti
Perché le opzioni Product di ShopWired richiedono una revisione specifica durante la migrazione?
Perché le opzioni Product dell’origine possono rappresentare comportamenti diversi in ShopWired. Alcune diventano varianti con significato relativo a SKU, prezzo, stock, immagine, peso o IVA. Altre appartengono a scelte, extra, campi di personalizzazione, bundle o strutture possedute da applicazioni.
I record Customer vengono abbinati in ShopWired soltanto in base al nome?
No. L’identità Customer è fortemente legata all’indirizzo email. Email duplicate, Orders guest, account registrati, account B2B e campi personalizzati Customer devono essere esaminati con attenzione affinché cronologia Orders e significato degli account restino utilizzabili.
Gli Orders migrati configurano il checkout in ShopWired?
No. Gli Orders migrati possono mantenere, dove supportato, il contesto storico di pagamento, consegna, sconti, imposte ed evasione ordini. Il checkout attivo dipende comunque dalla configurazione ShopWired relativa a pagamenti, consegna, IVA o imposte sulle vendite, gruppi Customer, B2B e app.
Prezzi B2B e regole B2B possono essere migrati come normali dati Customer?
Non sempre. Account B2B, fasce di prezzo, prezzi individuali, relazioni Quote, visibilità Product, condizioni account e trattamento fiscale sono record commerciali collegati, non normali campi di un profilo Customer.
Quando i dati personalizzati di ShopWired richiedono un responsabile separato?
Serve un responsabile separato quando il valore appartiene a un’applicazione, sistema esterno, tabella personalizzata dell’origine, livello di presentazione o relazione che non rientra in un normale record Product, Customer, Quote, Order o contenuto.
Come devono essere tradotte le regole B2B in ShopWired?
Separando l’identità dell’acquirente e i dati Product dalla regola che modifica prezzo, visibilità, trattamento fiscale, preventivo o comportamento del checkout. Vanno mantenuti i record che portano significato durevole e poi documentata la configurazione di destinazione o il sistema collegato che applicherà la regola commerciale.