I problemi nelle migrazioni verso VTEX raramente derivano da un singolo campo mancante. Emergono quando un’architettura e-commerce collegata viene trattata come una semplice destinazione per Products, Customers e Orders. Un record può esistere mentre la relazione SKU, il contesto della trade policy, la responsabilità seller, il percorso di evasione, il collegamento Master Data o l’identificativo di un sistema esterno non conservano più il significato necessario alle operations.
I problemi ricorrenti seguenti sono organizzati attorno ai punti in cui queste relazioni tendono a rompersi. Per ciascuno vengono descritti ciò che non funziona, i segnali che consentono di individuarlo in anticipo, l’approccio di prevenzione, una raccomandazione pratica e la condizione che dimostra che il rischio è sotto controllo.
Mappa di prevenzione dei problemi VTEX
| Area operativa | Problema nascosto ricorrente | Priorità di prevenzione |
|---|---|---|
| Catalog | I record Product esistono, ma relazioni SKU e specification sono incomplete. | Conservare la catena Product-SKU-Category-specification. |
| Contesto commerciale | Un prezzo valido viene applicato nel canale di vendita o contesto seller errato. | Mappare separatamente responsabilità del prezzo, trade policy e offerte seller. |
| Marketplace | Products e Orders perdono responsabilità di seller, offerta, commissione o evasione. | Conservare relazioni marketplace e seller, non soltanto le etichette. |
| Logistics | I totali di inventario vengono trasferiti senza warehouse, dock, carrier o significato della consegna. | Ricostruire la rete di evasione attorno a responsabili espliciti. |
| Orders | I totali restano leggibili, ma composizione dei package, riferimenti invoice, cancellazioni o IDs esterni scompaiono. | Conservare contesto storico della transazione e tracciabilità. |
| Dati personalizzati | Master Data e record posseduti da app vengono appiattiti in normali campi Customer. | Classificare ogni oggetto personalizzato per schema, relazione e responsabile. |
| Integrazioni | ERP, PIM, WMS o sistemi marketplace vengono ricollegati con IDs o direzioni di aggiornamento errati. | Conservare identificativi e stabilire un’unica autorità per ogni dominio dati. |
| Storefront | La presenza nel Catalog viene scambiata per funzionamento completo di Search, Checkout e contenuti. | Assegnare implementazione storefront e Checkout separatamente dai record migrati. |
Problema 1: trattare VTEX come un unico Store autosufficiente
Che cosa non funziona
La migrazione viene progettata come se VTEX fosse un solo database e un solo storefront. In pratica Catalog, Pricing, Promotions, Checkout, Orders, Inventory e shipping, relazioni marketplace, Master Data, implementazione storefront e sistemi esterni possono possedere ciascuno una parte del modello operativo. I record possono apparire corretti in un modulo mentre un altro applica disponibilità, prezzo, seller o modalità di evasione differenti.
Questo crea una falsa impressione di completezza. Il team approva i conteggi di Products e Orders anche se nessuno sa spiegare quale sistema controlla i valori che clienti e operations utilizzeranno realmente.
Segnali iniziali
| Segnale | Conseguenza probabile |
|---|---|
| Il perimetro elenca soltanto Products, Customers e Orders. | Dipendenze da trade policy, seller, Logistics o dati personalizzati restano invisibili. |
| Un unico revisore approva tutte le aree dati. | Contesto importante viene accettato senza il responsabile aziendale competente. |
| I sistemi esterni sono descritti soltanto come “integrazioni”. | Responsabilità dei campi e direzione degli aggiornamenti restano indefinite. |
| Si presume che lo storefront segua automaticamente i record Catalog. | Problemi di Search, contenuti, Checkout e navigazione emergono dopo il caricamento dei record. |
Prevenzione
Modellare la destinazione per dominio operativo. Per ogni valore importante, identificare se il responsabile futuro è VTEX Catalog, Pricing, Promotions, Checkout, Orders, Inventory e shipping, Master Data, un seller, l’implementazione storefront o un sistema esterno. Utilizzare almeno uno scenario rappresentativo che attraversi più domini, così che i passaggi di responsabilità diventino visibili.
Esempio di raccomandazione
Seguire uno SKU di alto valore dal Catalog attraverso specification, contesto prezzo, responsabilità first-party o seller, ubicazione dell’inventario, promessa di consegna, selezione Checkout, creazione dell’Order e identificativo nel back-office esterno. Lo stesso scenario dovrebbe avere revisori nominati per merchandising, commercial operations, Logistics e integrazioni.
Condizione di superamento
Ogni dominio dati critico per il lancio ha un responsabile dichiarato e il team sa spiegare come un Product rappresentativo passa da scoperta nel Catalog a prezzo, disponibilità, Checkout, Order, evasione e riconciliazione esterna.
Problema 2: appiattire il significato di Product, SKU e specification
Che cosa non funziona
Products e varianti della sorgente vengono compressi in record Product VTEX generici. Scelte a livello SKU, immagini, dimensioni, riferimenti stock e valori specification perdono la relazione con l’unità vendibile. Le Product specifications possono essere copiate come testo anche quando dovrebbero supportare informazione o navigazione, mentre SKU specifications necessarie alla selezione del buyer vengono associate al livello errato.
Un Product può quindi esistere ma restare non disponibile, difficile da trovare o impossibile da selezionare correttamente. Il difetto è strutturale, non cosmetico.
Segnali iniziali
| Segnale Catalog | Problema risultante |
|---|---|
| Campi Product e SKU vengono esaminati in un unico foglio piatto. | Le varianti vendibili perdono identificativi e attributi propri. |
| Taglia, voltaggio o colore sono memorizzati come testo Product. | Selezione SKU e filtri non rappresentano più l’unità acquistabile. |
| Le immagini vengono conservate soltanto a livello Product. | Lo SKU selezionato mostra media errati. |
| Le specifications vengono contate ma non classificate per funzione. | Search, filtri, dettagli Product o integrazioni ricevono valori inutilizzabili. |
Prevenzione
Classificare ogni valore sorgente come dato Product, dato SKU, Product specification, SKU specification, media, identificativo esterno o presentazione esclusiva dello storefront. Conservare l’ordine di creazione e dipendenza tra Categories, gruppi specification, campi, Products, SKUs, valori specification e file SKU. Non dedurre il successo dal solo SKU predefinito.
Esempio di raccomandazione
Per un elettrodomestico disponibile in più voltaggi e finiture, mantenere il modello generale come Product, ciascuna combinazione acquistabile come SKU, voltaggio e finitura come valori di selezione SKU quando appropriato, informazioni tecniche come Product specifications e immagini/dimensioni specifiche collegate all’unità vendibile reale.
Condizione di superamento
Le famiglie Product rappresentative conservano relazione Product-SKU, differenze selezionabili, specifications, immagini, identificativi e unità vendibili attive senza dipendere da testo descrittivo appiattito.
Problema 3: interrompere le dipendenze tra Category e specification
Che cosa non funziona
Le Categories vengono copiate come semplici etichette di navigazione senza preservare il modo in cui governano organizzazione Catalog e requisiti delle specifications. Gruppi o campi specification vengono creati dopo Products e SKUs, collegati alla Category sbagliata oppure popolati con valori incoerenti. Una modifica tardiva a Category o specification può disattivare SKUs, frammentare i filtri o lasciare Products importanti senza informazioni obbligatorie.
Il Catalog risultante può contenere tutti i record previsti mentre Search e attivazione Product si comportano in modo imprevedibile.
Segnali iniziali
| Segnale di dipendenza | Rischio creato |
|---|---|
| La profondità delle Categories viene copiata senza un modello di navigazione target. | La gerarchia Catalog diventa più difficile da gestire e utilizzare per la scoperta. |
| I campi specification vengono creati indipendentemente dalle Categories. | Valori obbligatori e filtri divergono tra Products correlati. |
| Nuove SKU specifications vengono aggiunte dopo il caricamento massivo dei Products. | Gli SKUs associati possono diventare inattivi finché i valori non vengono completati. |
| Valori equivalenti usano ortografia o unità incoerenti. | I filtri si dividono in scelte duplicate o fuorvianti. |
Prevenzione
Progettare il modello Category-specification prima del caricamento massivo dei Products. Definire quali Categories richiedono quali Product o SKU specifications, normalizzare i valori controllati e conservare la sequenza necessaria per creare e associare i record. Trattare successive modifiche allo schema come cambiamenti Catalog controllati, non come semplici modifiche ai contenuti.
Esempio di raccomandazione
Per un Catalog di elettronica, definire department, Category, gruppi specification, campo voltaggio, campo capacità e valori ammessi prima di creare gli SKUs. Popolare una famiglia completa e verificarne stato attivo, filtraggio e selezione nello storefront prima di estendere il pattern.
Condizione di superamento
Categories, gruppi specification, campi, valori, Products e SKUs formano una catena di dipendenze coerente e gli SKUs rappresentativi restano attivi e trovabili dopo l’applicazione dello schema target.
Problema 4: trasferire i prezzi senza contesto trade policy e seller
Che cosa non funziona
La migrazione conserva un prezzo per SKU mentre l’operazione reale differenzia prezzi, promotions, disponibilità, Logistics o pagamenti in base a canale di vendita, trade policy, seller, segmento Customer o sistema esterno responsabile del pricing. Un valore numericamente corretto può quindi essere commercialmente sbagliato nel contesto in cui il cliente lo vede.
Anche le promotions storiche possono essere scambiate per configurazione corrente, con il rischio di ricreare sconti obsoleti o dimenticare regole commerciali attive.
Segnali iniziali
| Segnale commerciale | Problema nascosto |
|---|---|
| Viene confrontato soltanto un prezzo base. | Pricing specifico per canale, seller o segmento non viene considerato. |
| Le trade policy vengono discusse dopo il caricamento del Catalog. | Contesti di prezzo, promotion, Logistics e pagamenti possono richiedere rilavorazione. |
| I nomi delle promotions vengono considerati prova sufficiente. | Condizioni, idoneità e comportamento di combinazione non vengono preservati. |
| La responsabilità dell’ERP o pricing engine non è chiara. | I valori migrati vengono sovrascritti o entrano in conflitto con aggiornamenti esterni. |
Prevenzione
Mappare il contesto commerciale separatamente dai dati Product. Per ciascuno SKU prioritario identificare responsabile del prezzo, canale di vendita o trade policy applicabile, seller, dipendenze dalle promotions, contesto Customer e direzione di aggiornamento. Conservare l’evidenza dei prezzi storici soltanto quando rimane utile; configurare il comportamento commerciale corrente presso il responsabile reale nel target.
Esempio di raccomandazione
Utilizzare uno SKU venduto sia direttamente sia tramite marketplace, con prezzo B2C, contesto B2B e una promotion attiva. Documentare quali valori entrano in VTEX, quali arrivano da un servizio esterno e quali condizioni determinano il risultato finale mostrato al cliente.
Condizione di superamento
Gli SKUs prioritari mostrano esiti di prezzo e promotion spiegabili in ogni contesto commerciale previsto, senza conflitti irrisolti tra valori migrati, configurazione VTEX, seller e sistemi esterni.
Problema 5: perdere la responsabilità di seller e offerte
Che cosa non funziona
I dati marketplace vengono trattati come normali dati Product. Identità seller, proprietà dell’offerta, corrispondenza SKU, responsabilità su prezzo e stock, contesto commissione, aspettative sui livelli di servizio e responsabilità di evasione vengono appiattiti in note o eliminati. I Products possono comparire nel marketplace, ma le operations non riescono a determinare chi possiede l’offerta o chi deve evadere l’Order risultante.
Il problema è particolarmente grave quando più seller offrono lo stesso SKU oppure quando un’azienda opera sia come marketplace sia come seller in altri contesti.
Segnali iniziali
| Segnale marketplace | Problema ricorrente |
|---|---|
| Seller IDs vengono salvati come attributi Product. | La responsabilità marketplace non può governare offerte e gestione Orders. |
| Si creano Products duplicati per le offerte seller. | Catalog matching e logica buy-box si frammentano. |
| Orders marketplace e seller vengono esaminati insieme. | Responsabile Checkout e responsabile evasione vengono confusi. |
| Riferimenti seller esterni vengono eliminati. | Riconciliazione e aggiornamenti dei connettori creano duplicati. |
Prevenzione
Separare identità Catalog da identità dell’offerta seller. Conservare identificativi seller, riferimenti di corrispondenza SKU, responsabilità per prezzo e quantità, riferimenti Orders marketplace, responsabilità di evasione e chiavi dei connettori esterni. Definire se l’account di destinazione opera come marketplace, seller o entrambi in ciascuna relazione.
Esempio di raccomandazione
Per un Product di marca fornito da tre seller, mantenere una sola identità Catalog marketplace e tre offerte distinte con seller, prezzo, stock e responsabilità di consegna propri. Esaminare un Order che seleziona uno dei seller e confermare che la parte corretta lo riceva e lo evada.
Condizione di superamento
I Products marketplace rappresentativi conservano offerte seller, responsabilità, corrispondenze, prezzo, stock, routing Orders ed evasione corretti senza creare identità Catalog duplicate.
Problema 6: appiattire inventario e Logistics in una sola quantità
Che cosa non funziona
La migrazione trasferisce una quantità disponibile ma perde warehouses, record inventario, loading docks, carrier, policy di consegna, pickup location, relazioni trade policy o responsabilità del WMS esterno. Lo storefront può mostrare stock mentre il Checkout non riesce a produrre la promessa di consegna prevista, oppure la posizione errata viene considerata origine dell’evasione.
Una quantità iniziale è inoltre poco affidabile quando un ERP o WMS diventerà immediatamente la fonte autorevole continuativa.
Segnali iniziali
| Segnale Logistics | Conseguenza operativa |
|---|---|
| Una quantità totale sostituisce lo stock per ubicazione. | La disponibilità non può essere assegnata al punto di evasione corretto. |
| L’inventario viene caricato prima che esistano le relazioni Logistics. | Le simulazioni Checkout producono opzioni di consegna incomplete o fuorvianti. |
| Pickup e delivery vengono trattati come lo stesso percorso. | Impegni di ubicazione e livello di servizio vengono persi. |
| Aggiornamenti ERP o WMS non vengono sospesi o sequenziati. | Le quantità migrate vengono sovrascritte prima della riconciliazione. |
Prevenzione
Mappare la rete di evasione, non soltanto i valori stock. Identificare ubicazioni inventario, relazioni Logistics, percorsi delivery e pickup, responsabilità esterna, identificativi SKU e sequenza tra inventario iniziale e sincronizzazione continuativa. Conservare le etichette shipping storiche separatamente dalla configurazione corrente della consegna.
Esempio di raccomandazione
Per uno SKU presente in due warehouses e disponibile per pickup soltanto in alcune regioni, verificare quale inventario viene offerto in ogni canale, quale promessa di consegna compare nel Checkout e quale sistema pubblica la quantità continuativa.
Condizione di superamento
Gli SKUs rappresentativi hanno disponibilità corretta a livello di ubicazione, risultati delivery o pickup spiegabili e un unico responsabile continuativo documentato per ogni aggiornamento stock.
Problema 7: ridurre gli Orders a totali ed etichette di stato
Che cosa non funziona
Gli Orders vengono migrati con numero Order, Customer, totale e stato generico, ma composizione dei package, relazione seller, sostituzioni articoli, dati shipping, riferimenti invoice, storico cancellazioni, rimborsi, tracking, IDs esterni o contesto marketplace non restano più interpretabili. L’assistenza può trovare l’Order ma non spiegare che cosa sia successo.
Lo storico può inoltre essere scambiato per prova che la configurazione corrente di Checkout, pagamenti, tax ed evasione funzioni.
Segnali iniziali
| Evidenza Order | Significato mancante |
|---|---|
| È visibile un totale finale. | Sconti, tax, shipping, rimborsi o rettifiche non possono essere spiegati. |
| Viene conservato un solo stato. | Ciclo di vita sorgente e significato aziendale corrente sono ambigui. |
| I nomi Product sono leggibili. | Relazioni SKU, seller, package ed evasione sono assenti. |
| I riferimenti esterni vengono omessi. | Riconciliazione ERP, WMS, marketplace o accounting si interrompe. |
Prevenzione
Definire l’uso storico degli Orders e conservare le prove necessarie per assistenza, finance, operations seller e riconciliazione. Includere identificativi item/SKU, relazione Customer, contesto seller e marketplace, componenti finanziarie, dati package e shipment, riferimenti invoice o tracking, storico stati quando significativo e chiavi esterne. Mantenere la configurazione Checkout live fuori dall’interpretazione degli Orders storici.
Esempio di raccomandazione
Esaminare un Order diretto, uno marketplace, uno multi-package, uno cancellato e uno rimborsato. Un operatore dell’assistenza dovrebbe poter spiegare articoli, seller, risultato finanziario, stato di evasione e tracciabilità esterna senza aprire il sistema sorgente.
Condizione di superamento
Gli Orders storici rappresentativi restano comprensibili rispetto a Customer, SKU, seller, dimensione finanziaria, package, invoice, evasione, cancellazione o rimborso e sistemi esterni senza riaprire la piattaforma di origine.
Problema 8: trattare Master Data come normali campi Customer
Che cosa non funziona
Entità Master Data, schemi personalizzati, record correlati, oggetti posseduti da app e riferimenti esterni vengono compressi in pochi campi Customer o Order. Le relazioni tra aziende, contatti, approvazioni, loyalty, richieste di servizio o entità operative scompaiono perché gli schemi sorgente e target non vengono trattati come oggetti strutturati.
Il profilo Customer visibile può sembrare completo mentre processi e integrazioni perdono i record da cui dipendono realmente.
Segnali iniziali
| Segnale sui dati personalizzati | Rischio creato |
|---|---|
| Ogni record personalizzato viene descritto come campo Customer. | Entità separate e relazioni uno-a-molti vengono perse. |
| Gli schemi sono elencati senza chiavi di relazione. | I record non possono essere ricollegati dopo il caricamento. |
| Oggetti posseduti da app sono assenti dai campioni. | Processi operativi falliscono fuori dai record e-commerce standard. |
| Dati personali vengono copiati senza una regola di responsabilità. | Aspettative su privacy, retention e accesso diventano poco chiare. |
Prevenzione
Inventariare gli oggetti personalizzati per schema, chiave primaria, relazione, finalità aziendale, sensibilità, responsabile corrente, responsabile di destinazione e applicazione o processo che continuerà a utilizzarlo. Conservare soltanto dati con un uso valido nel target e mantenere strutturate le relazioni strutturate. I dati personalizzati che rimangono esterni devono conservare gli identificativi necessari per collegarsi in sicurezza ai record VTEX.
Esempio di raccomandazione
In un’operazione B2B, separare identità azienda, contatti buyer, record di ruolo o approvazione, riferimenti commerciali e profili Customers. Conservare le chiavi che li collegano anziché concatenare tutti i valori in note.
Condizione di superamento
Ogni oggetto personalizzato critico per l’azienda ha schema, relazione, responsabile e uso nel target espliciti, senza entità strutturate nascoste dentro campi Customer o Order generici.
Problema 9: ricollegare ERP, PIM e WMS con identità interrotte
Che cosa non funziona
I sistemi esterni vengono ricollegati usando nuovi VTEX IDs senza conservare source reference IDs, tabelle di corrispondenza, direzione degli aggiornamenti o sequenza degli eventi. Il PIM crea Products duplicati, l’ERP sovrascrive prezzi, il WMS pubblica inventario sullo SKU errato oppure gli aggiornamenti Orders falliscono perché ogni sistema identifica lo stesso record in modo differente.
Una connessione API tecnicamente riuscita può quindi danneggiare immediatamente i dati migrati.
Segnali iniziali
| Segnale d’integrazione | Fallimento probabile |
|---|---|
| I nuovi VTEX IDs sono considerati gli unici identificativi. | I sistemi esterni non riescono a trovare i record migrati. |
| Creazione e aggiornamento non vengono distinti. | La prima sincronizzazione duplica oggetti esistenti. |
| Due sistemi possono scrivere lo stesso campo. | I valori oscillano o si sovrascrivono a vicenda. |
| Orders storici e live usano un feed indistinto. | I vecchi record innescano elaborazioni operative non previste. |
Prevenzione
Creare un contratto di identità e responsabilità per ciascuna integrazione. Conservare gli IDs sorgente quando necessari, registrare gli IDs VTEX, definire comportamento create-versus-update, stabilire un solo writer per campo o dominio e sequenziare la prima sincronizzazione dopo la riconciliazione dei record migrati. Separare dati storici dagli eventi operativi live.
Esempio di raccomandazione
Per un’integrazione PIM e WMS, creare una tabella di corrispondenza per identificativi Product, SKU e inventario. Il PIM può possedere i contenuti descrittivi del Catalog, mentre il WMS possiede lo stock per ubicazione; nessuno dei due dovrebbe sovrascrivere campi di responsabilità dell’altro.
Condizione di superamento
Ogni sistema esterno aggiorna esattamente una volta il record VTEX previsto, utilizza riferimenti incrociati stabili e dispone di un confine read/write documentato che impedisce duplicazioni e conflitti di sovrascrittura.
Problema 10: presumere che i dati Catalog creino storefront e Checkout
Che cosa non funziona
I record Catalog vengono trattati come esperienza Customer completa in VTEX. Indicizzazione Search, faccette, componenti delle pagine Product, contenuti, navigazione, visualizzazione seller, simulazione carrello, campi Checkout, pagamenti, shipping, tax e integrazioni storefront restano aspetti di implementazione separati. I Products possono esistere ma essere difficili da trovare o impossibili da acquistare attraverso il percorso previsto.
Il fallimento viene spesso diagnosticato come cattiva migrazione anche quando il responsabile mancante è storefront, Search, Checkout o implementazione delle integrazioni.
Segnali iniziali
| Segnale nel percorso Customer | Lacuna nascosta |
|---|---|
| I Products vengono controllati soltanto nell’Admin. | Problemi Search, filtraggio, pagina Product e visualizzazione seller restano nascosti. |
| URL di alto valore non hanno una mappa di destinazione. | Contenuti e percorsi organici di ingresso perdono continuità. |
| Etichette storiche di pagamento e shipping vengono riutilizzate come configurazione. | I metodi Checkout correnti restano non implementati. |
| Componenti headless o componibili non hanno responsabili assegnati. | Dati corretti non raggiungono l’esperienza rivolta al cliente. |
Prevenzione
Separare i record migrati dall’implementazione storefront e Checkout. Definire modello Search e faccette, requisiti dati delle pagine Product, destinazioni di contenuti e URL, presentazione seller, contratti cart/Checkout e servizi esterni. Utilizzare gli stessi scenari rappresentativi Product e Order tra Catalog, storefront e responsabilità Checkout in modo che le lacune non possano nascondersi tra i team.
Esempio di raccomandazione
Per un Product prioritario, confermare che l’URL previsto si risolva, Search lo trovi, i filtri espongano le specifications corrette, SKU e seller giusti siano selezionabili, la simulazione cart restituisca prezzo e disponibilità correnti e Checkout riceva il contesto di consegna e Customer richiesto.
Condizione di superamento
I percorsi Customer prioritari utilizzano correttamente i record migrati attraverso scoperta, selezione Product, contesto seller, cart e Checkout, con ogni comportamento non legato ai dati assegnato a un responsabile target nominato.
Conclusione
Una migrazione VTEX riesce quando sopravvivono relazioni e responsabilità, non soltanto i record. Struttura Product-SKU, specifications, trade policy, seller, Logistics, Orders, Master Data, integrazioni, Search e Checkout devono restare collegati attraverso identità e responsabilità esplicite. L’approccio di prevenzione più sicuro consiste nel seguire scenari commerciali rappresentativi attraverso questi confini e richiedere una condizione di superamento chiara per ogni problema ricorrente.
Domande frequenti
Perché Products VTEX possono esistere ma restare non disponibili ai clienti?
Un Product può non avere ancora uno SKU attivo, valori specification obbligatori, immagini, prezzo, inventario, offerta seller, relazione trade policy o visibilità storefront. La disponibilità dipende dal Catalog collegato al contesto commerciale, non dalla sola presenza del Product.
Qual è la relazione del Catalog VTEX più importante da preservare?
La relazione Product-SKU è centrale, ma dipende da Categories, gruppi specification, Product e SKU specifications, media, identificativi e unità vendibili attive. Appiattire questi record elimina la struttura utilizzata da buyer e integrazioni.
Perché le trade policy devono essere esaminate separatamente dai prezzi?
Le trade policy possono raggruppare Catalog, prezzo, promotion, Logistics, segmentazione e impostazioni di pagamento per strategie di vendita distinte. Un prezzo può essere numericamente corretto e comunque applicarsi nel contesto commerciale sbagliato.
Come devono essere gestiti i dati dei seller marketplace?
Conservare identità seller, proprietà dell’offerta, corrispondenza SKU, responsabilità su prezzo e stock, riferimenti Orders e responsabilità di evasione. Le informazioni seller non devono essere ridotte a un attributo Product o a una nota di testo libero.
Conservare gli Orders storici dimostra che VTEX Checkout è pronto?
No. Gli Orders storici preservano evidenza delle transazioni. Checkout, pagamenti, shipping, tax, promotion ed evasione correnti devono essere implementati dai rispettivi responsabili attuali.
Perché gli identificativi esterni sono critici in una migrazione VTEX?
ERP, PIM, WMS, marketplace e sistemi di supporto utilizzano spesso identificativi propri. Riferimenti incrociati stabili impediscono creazioni duplicate, aggiornamenti sul record errato e riconciliazione interrotta quando questi sistemi vengono ricollegati.