Le migrazioni verso PrestaShop falliscono più spesso quando i record sono presenti ma le loro relazioni con negozio, lingua, combinazione, modulo o logica commerciale cambiano significato. La prevenzione deve quindi seguire la relazione operativa dietro ogni record, invece di affidarsi ai soli conteggi. I dieci problemi seguenti descrivono schemi di errore ricorrenti che possono lasciare un catalogo apparentemente completo mentre si indeboliscono acquisto, scoperta, assistenza o integrazioni.
Problema 1: appiattire le combinazioni in normali campi Product
Cosa va storto
Un Product di origine può arrivare con il record principale intatto mentre la struttura delle varianti vendibili perde significato. Le combinazioni di PrestaShop contengono le differenze di acquisto che distinguono una scelta vendibile da un’altra, mentre le caratteristiche descrivono i Products e i campi di personalizzazione raccolgono valori inseriti dall’acquirente. Trattare questi tre livelli come intercambiabili può creare Products duplicati, prezzi di variante mancanti, proprietà dello stock errata oppure un sito pubblico che mostra informazioni senza conservare la scelta di acquisto prevista.
Segnali di allarme iniziali
Il segnale non è un conteggio basso di Products. È una discrepanza tra ciò che i clienti possono selezionare e ciò che il personale può gestire. I record più a rischio sono i Products le cui opzioni modificano SKU, prezzo, peso, immagine, disponibilità o stock.
| Segnale | Significato probabile | Problema immediato |
|---|---|---|
| Ogni opzione è diventata una caratteristica | Strutture descrittive e vendibili sono state unite | Il Product può mostrare scelte che non controllano l’articolo effettivamente acquistato |
| Ogni combinazione è diventata un Product separato | La relazione Product padre-combinazione è stata appiattita | Categories, SEO e merchandising possono frammentarsi |
| Lo stock esiste solo sul Product principale | L’inventario a livello di combinazione non è stato conservato | Le scelte vendibili possono essere vendute in eccesso o risultare non disponibili |
Prevenzione
Classificare ogni opzione di origine in base alla sua funzione di business prima della mappatura. Una scelta che modifica lo SKU acquistato appartiene alla logica delle combinazioni; un valore usato per il confronto appartiene alle caratteristiche; testo o file inseriti dall’acquirente appartengono alla personalizzazione. Includere Products rappresentativi con più dimensioni di opzioni, variazioni di prezzo, immagini e comportamento dello stock. Conservare identificativi esterni stabili quando ERP o sistema di magazzino riconoscono la combinazione anziché soltanto il Product padre.
Esempio di raccomandazione
Per una giacca venduta per taglia e colore, mantenere un solo Product con combinazioni per le scelte vendibili. Conservare SKU della combinazione, variazione di prezzo, relazione con l’immagine e stock. Mantenere invece “grado di impermeabilità” come caratteristica e un eventuale messaggio per ricamo come personalizzazione, anziché creare Products separati per ogni valore.
Condizione di superamento
L’acquirente può selezionare ogni scelta richiesta, lo SKU e il prezzo corretti vengono inseriti nel carrello, lo stock delle combinazioni cambia in modo indipendente dove previsto e il personale può ricondurre ogni scelta vendibile allo stesso identificativo operativo utilizzato dai sistemi collegati.
Problema 2: perdere la proprietà multistore pur conservando i record
Cosa va storto
Il multistore PrestaShop può rendere uno stesso record visibile, prezzato, tradotto o configurato in modo diverso tra negozi o gruppi di negozi. Una migrazione che conserva Product, Category, Customer o record CMS ma perde il relativo contesto di negozio può esporre il catalogo sbagliato, unire contenuti regionali oppure assegnare record condivisi a un negozio in cui non avrebbero mai dovuto comparire.
Segnali di allarme iniziali
Il rischio è maggiore quando il team parla del “negozio PrestaShop” come se esistesse un unico sito pubblico. Differenze di dominio, lingua, valuta, catalogo, tema, prezzi o responsabilità operative indicano che il contesto del negozio fa parte del significato dei dati.
| Area | Domanda multistore | Errore se ignorata |
|---|---|---|
| Products e Categories | Sono condivisi globalmente o assegnati selettivamente? | Il negozio sbagliato può pubblicare o nascondere il record |
| Prezzi e promozioni | Sono condivisi o specifici del negozio? | La logica commerciale regionale può essere appiattita |
| CMS e traduzioni | Contenuto comune o localizzato per negozio? | Un mercato può sovrascriverne un altro |
Prevenzione
Creare una matrice di proprietà dei negozi per ogni famiglia di record inclusa nell’ambito. Distinguere dati realmente condivisi da valori che cambiano per negozio, lingua o regione. Utilizzare identificativi di negozio espliciti invece di dedurre la proprietà da dominio o lingua. Quando la piattaforma di destinazione rappresenta i siti pubblici in modo diverso, definire la relazione di destinazione per ogni valore specifico del negozio invece di copiare soltanto il record comune.
Esempio di raccomandazione
Un’azienda gestisce negozi francese e belga con catalogo Product condiviso ma descrizioni, presentazione fiscale e promozioni differenti. Conservare l’identità Product condivisa assegnando però contenuti localizzati e valori commerciali ai siti pubblici corretti, invece di scegliere un negozio come sorgente universale.
Condizione di superamento
Ogni sito pubblico di destinazione espone soltanto Products, Categories, contenuti, lingua e contesto commerciale previsti; i record condivisi restano condivisi quando appropriato e nessun valore specifico del negozio viene promosso silenziosamente a valore predefinito globale.
Problema 3: migrare i gruppi Customer senza il loro significato commerciale
Cosa va storto
I gruppi Customer possono influire su visibilità, prezzi, sconti, visualizzazione fiscale o aspettative di accesso. Copiare i nomi dei gruppi senza conservare le relazioni che controllano crea account che sembrano classificati nel Back Office ma ricevono un trattamento ordinario sul sito pubblico. Il problema è facile da perdere quando la revisione guarda i profili Customer senza confrontare il risultato di acquisto per ogni gruppo.
Segnali di allarme iniziali
Le etichette dei gruppi possono esistere mentre scompaiono i risultati commerciali collegati. Il rischio aumenta quando i gruppi di origine combinano logiche B2B, wholesale, dipendenti, fedeltà, imposte o regioni.
| Segnale di allarme | Cosa suggerisce | Effetto sul business |
|---|---|---|
| I gruppi esistono ma tutti gli acquirenti vedono lo stesso prezzo | La relazione di prezzo non è stata rappresentata | Le aspettative wholesale o negoziate non vengono rispettate |
| Products con accesso limitato sono visibili a tutti | La proprietà della visibilità è stata persa | I controlli del catalogo privato scompaiono |
| La visualizzazione fiscale è identica per tutti i gruppi | Il contesto fiscale legato al gruppo è stato appiattito | Totali mostrati e addebitati possono divergere dalle policy |
Prevenzione
Documentare il risultato controllato da ogni gruppo di origine, non soltanto il nome. Mappare la relazione Customer-gruppo separatamente dalla configurazione di destinazione che attribuisce significato al gruppo. Consolidare deliberatamente gruppi duplicati o obsoleti. Quando più gruppi di origine sono codificati in un unico tag o campo personalizzato, stabilire se la destinazione supporta un’appartenenza equivalente oppure richiede una gerarchia normalizzata.
Esempio di raccomandazione
Per un gruppo wholesale, conservare l’appartenenza dei Customers e definire il responsabile lato destinazione per prezzi wholesale, Products riservati e presentazione fiscale. Non approvare il gruppo soltanto perché la parola “Wholesale” compare sul record Customer.
Condizione di superamento
Customers rappresentativi accedono al contesto account corretto e ricevono visibilità Product, prezzi, sconti e presentazione fiscale previsti per il loro gruppo, con eventuali differenze intenzionali documentate come comportamento della destinazione.
Problema 4: interrompere la scoperta tramite Categories pur conservando la struttura
Cosa va storto
Un’importazione di Categories può riprodurre nomi e relazioni padre-figlio e allo stesso tempo indebolire il modo in cui i clienti scoprono i Products. Navigazione PrestaShop, filtri stratificati, uso delle caratteristiche, merchandising e funzionamento del tema possono dipendere da più della sola struttura. Categories vuote, Products assegnati alla Category predefinita sbagliata o caratteristiche descrittive che non supportano più i filtri possono rendere difficile da esplorare un catalogo apparentemente completo.
Segnali di allarme iniziali
I conteggi delle Categories risultano spesso corretti anche quando la scoperta è danneggiata. I segnali emergono nei percorsi del sito pubblico, nel posizionamento dei Products, nei filtri e nel comportamento della Category predefinita.
| Controllo | Schema di errore | Perché conta |
|---|---|---|
| Category predefinita | Il Product ha più assegnazioni ma il contesto principale è sbagliato | Breadcrumb e comportamento canonico possono cambiare |
| Copertura delle caratteristiche | I valori delle caratteristiche esistono solo su parte di una famiglia Product | La navigazione a filtri diventa incoerente |
| Profondità delle Categories | Rami profondi sono stati appiattiti o duplicati | I clienti perdono i percorsi di navigazione attesi |
Prevenzione
Definire i risultati di scoperta attesi per famiglie Product rappresentative. Conservare tutte le assegnazioni Category necessarie e identificare la Category predefinita quando il comportamento di PrestaShop ne dipende. Normalizzare nomi e valori delle caratteristiche prima di usarli per i filtri. Ritirare Categories obsolete soltanto con un redirect esplicito o una destinazione di merchandising, non eliminandole senza pianificazione dei percorsi.
Esempio di raccomandazione
Per un catalogo di calzature, verificare che una scarpa rimanga nelle Categories Uomo, Running e Saldi mantenendo la Category predefinita prevista. Confermare che caratteristiche come taglia, superficie e impermeabilità siano abbastanza complete da supportare l’esperienza di filtraggio sulla destinazione.
Condizione di superamento
Le famiglie Product prioritarie sono raggiungibili attraverso i percorsi Category previsti, breadcrumb e contesto predefinito sono coerenti, i filtri utilizzano valori completi e normalizzati e i rami ritirati indirizzano i clienti verso una destinazione intenzionale.
Problema 5: presumere che gli URL descrittivi conservino automaticamente l’identità dei percorsi
Cosa va storto
Chiavi URL di origine, percorsi riscritti, prefissi di lingua e percorsi CMS non ricreano automaticamente lo stesso indirizzo pubblico in un nuovo ambiente PrestaShop. Un record può essere presente mentre il suo percorso di valore elevato cambia, entra in conflitto con un altro percorso o risolve verso il negozio o la lingua sbagliati. Il problema risultante influisce su clienti, campagne, collegamenti interni e visibilità nella ricerca.
Segnali di allarme iniziali
I segnali più forti sono valori riscritti duplicati, suffissi di lingua non spiegati, contesto del negozio mancante o pagine prioritarie la cui destinazione non è mai stata dichiarata.
| Tipo di percorso | Problema comune di migrazione | Decisione necessaria |
|---|---|---|
| Percorso Product o Category | Il vecchio rewrite non corrisponde alla struttura di destinazione | Scegliere la destinazione canonica e reindirizzare il percorso di origine |
| Percorso multilingue | Slug specifici della lingua vengono ridotti a un unico valore | Conservare destinazioni specifiche per locale |
| Percorso CMS o campagna | La pagina esiste con un nuovo percorso | Aggiornare i collegamenti interni e reindirizzare il percorso storico |
Prevenzione
Creare un registro dei percorsi per Products, Categories, pagine CMS e destinazioni di campagna prioritarie. Includere URL di origine, lingua, negozio, percorso previsto sulla destinazione e responsabile del redirect. Verificare l’unicità nel contesto di routing della destinazione. Conservare slug significativi quando possibile, ma preferire una destinazione canonica coerente invece di creare percorsi duplicati o concorrenti.
Esempio di raccomandazione
Un percorso Product francese e uno belga condividono lo stesso nome tradotto ma appartengono a negozi diversi. Assegnare ciascuno alla destinazione corretta per negozio e lingua e creare redirect da entrambi i percorsi storici, invece di conservare soltanto quello con più traffico.
Condizione di superamento
Ogni percorso storico prioritario risolve direttamente o tramite un unico redirect intenzionale verso il Product, la Category o la destinazione CMS corretti nel negozio e nella lingua previsti, senza loop o collisioni.
Problema 6: trattare moduli, override e logica del tema come dati migrati
Cosa va storto
Moduli e override PrestaShop possono creare campi, modificare il checkout, aggiungere corrieri o funzionamento dei pagamenti, cambiare la presentazione Product o memorizzare identificativi di integrazione. I temi possono determinare come vengono visualizzate le strutture del catalogo. Copiare i record standard non riproduce questo funzionamento e copiare tabelle dei moduli senza capire quale modulo le utilizza può creare dati inutilizzabili o rischiosi.
Segnali di allarme iniziali
Il rischio è evidente quando risultati critici per il business vengono descritti soltanto con il nome di un modulo, quando tabelle personalizzate non hanno un responsabile o quando il tema di destinazione si aspetta campi e hook differenti.
| Dipendenza | Domanda da risolvere | Proprietario probabile |
|---|---|---|
| Campo creato da un modulo | Quale processo attuale lo legge? | Modulo continuativo, integrazione o campo di destinazione ristrutturato |
| Override o codice personalizzato | Quale comportamento predefinito modifica? | Implementazione sulla destinazione anziché migrazione dei record |
| Contenuto specifico del tema | Il valore è un dato o configurazione di presentazione? | Configurazione del tema/contenuti sulla destinazione |
Prevenzione
Inventariare moduli, override, tabelle personalizzate, hook e dipendenze del tema in base al risultato di business. Conservare un valore soltanto quando esiste un utilizzatore sulla destinazione. Separare la migrazione dei record dalla reinstallazione, configurazione, sostituzione o ricostruzione del funzionamento. Evitare di trasferire dati di moduli inattivi soltanto perché presenti nel database.
Esempio di raccomandazione
Se un modulo conserva un riferimento fornitore usato da un’esportazione ERP, mantenere quel riferimento in un campo o record di integrazione sulla destinazione che il processo ERP continuativo possa leggere. Non copiare la tabella del modulo se il modulo stesso non esisterà nell’ambiente di destinazione.
Condizione di superamento
Ogni modulo o override critico per il business ha un proprietario di destinazione dichiarato, i dati necessari restano leggibili per tale proprietario e nessun processo del sito pubblico o operativo viene considerato automaticamente continuativo soltanto perché sono stati migrati i record standard.
Problema 7: appiattire la proprietà dello stock tra combinazioni e ubicazioni
Cosa va storto
L’inventario può apparire corretto a livello Product mentre le combinazioni vendibili hanno quantità o disponibilità sbagliate. Sistemi esterni di stock, cronologia avanzata dell’inventario, flussi dati di magazzino o inventario specifico del negozio possono aggiungere ulteriori livelli di proprietà. Appiattire questi valori può causare vendite oltre la disponibilità, falsi stati di esaurimento o una quantità di destinazione immediatamente sovrascritta da un sistema collegato.
Segnali di allarme iniziali
Una sola quantità per Product, identificativi di combinazione mancanti, stock negativo non spiegato o disaccordo tra negozio e sistema esterno indicano un problema di proprietà, non un semplice errore di importazione.
| Segnale di inventario | Causa probabile | Focus di prevenzione |
|---|---|---|
| Il totale del Product padre equivale alla somma di tutte le varianti | La proprietà delle varianti è stata ignorata | Conservare quantità a livello di combinazione o chiave esterna dello stock |
| La quantità sulla destinazione cambia dopo la sincronizzazione | Il sistema esterno rimane autorevole | Definire saldo iniziale e proprietario dopo la migrazione |
| Un negozio mostra lo stock di un altro | Il contesto del negozio è stato appiattito | Conservare la relazione negozio/ubicazione |
Prevenzione
Dichiarare il sistema autorevole per l’inventario di ogni famiglia Product e ubicazione. Conservare SKU delle combinazioni e identificativi esterni. Definire se la migrazione fornisce un saldo iniziale, un riferimento storico o un valore di inventario continuativo. Escludere tabelle di stock obsolete che non governano più la disponibilità.
Esempio di raccomandazione
Per un Product con combinazioni di taglia gestite da un sistema di magazzino, migrare la quantità iniziale per combinazione e conservare lo SKU di magazzino. Pianificare che la connessione al magazzino diventi autorevole dopo il cutover invece di trattare il totale del Product padre come valore permanente dello stock.
Condizione di superamento
La combinazione vendibile corretta è disponibile nel negozio o nell’ubicazione corretti, le variazioni di stock avvengono sotto il proprietario di sistema previsto e la riconciliazione collega ogni quantità di destinazione a un identificativo stabile di Product o combinazione.
Problema 8: conservare Orders storici senza il contesto che li spiega
Cosa va storto
Totale e stato di un Order non bastano a conservare ciò che è accaduto. Orders storici possono dipendere da combinazioni Product, gruppi Customer, imposte, corrieri, sconti, rimborsi, messaggi e cronologia degli stati. Se queste relazioni vengono appiattite, il personale vede la transazione ma non riesce a spiegare l’importo, identificare la variante acquistata o capire quale azione di evasione degli ordini o rimborso sia avvenuta.
Segnali di allarme iniziali
Gli Orders sembrano completi nell’elenco ma diventano ambigui quando vengono aperti. Dettagli delle opzioni mancanti a livello di riga, stati generici, contesto degli sconti assente o record Customer scollegati sono segnali tipici.
| Contesto dell’Order | Errore se assente | Conseguenza per il servizio |
|---|---|---|
| Dettaglio di combinazione o personalizzazione | L’articolo acquistato non può essere identificato | Resi e decisioni di assistenza diventano inaffidabili |
| Cronologia degli stati e messaggi | La sequenza operativa viene persa | Il personale non può spiegare evasione o annullamento |
| Righe di sconto, imposta e spedizione | Il totale non può essere riconciliato | Finanza e assistenza clienti perdono fiducia |
Prevenzione
Conservare identità Product a livello di riga e contesto descrittivo dell’acquisto anche quando la destinazione non può ricreare ogni stato del processo storico. Mappare gli stati in base al significato anziché alla somiglianza delle etichette. Mantenere distinguibili le righe finanziarie. Conservare numeri Order di origine e riferimenti esterni quando altri sistemi li utilizzano per le ricerche.
Esempio di raccomandazione
Per un Order rimborsato che contiene una combinazione taglia-colore e un voucher, conservare descrizione della combinazione acquistata, importi originali, riga di sconto, contesto del rimborso, associazione al Customer e riferimento di origine invece di rappresentarlo come un generico Order completato.
Condizione di superamento
Il personale può identificare ciò che il Customer ha acquistato, come si è formato il totale, quale sequenza di stati si è verificata e quale contesto di rimborso o evasione rimane rilevante, senza consultare il negozio di origine dismesso per le normali richieste di assistenza.
Problema 9: trasferire una localizzazione incoerente in un catalogo condiviso
Cosa va storto
I contenuti multilingue contengono spesso traduzioni parziali, slug duplicati, testo di fallback, differenze HTML e campi creati da moduli tradotti in modo incoerente. Migrare ogni valore esattamente come è memorizzato può esporre contenuti nella lingua di origine nel negozio sbagliato oppure produrre sezioni vuote del sito pubblico dove la destinazione si aspetta un valore specifico per locale.
Segnali di allarme iniziali
Products con nome tradotto ma descrizione assente, slug Category in conflitto tra lingue o un negozio che utilizza contenuti copiati che dovrebbero rimanere distinti.
| Problema di localizzazione | Risultato visibile | Controllo |
|---|---|---|
| Valore locale mancante | Contenuto vuoto o di fallback sul sito pubblico | Definire una regola di fallback o completamento approvata |
| Stesso slug in contesti incompatibili | Collisione di percorso o destinazione errata | Assegnare percorsi consapevoli di lingua e negozio |
| Collegamenti incorporati al dominio di origine | I Customers tornano al vecchio negozio | Riscrivere i collegamenti verso le destinazioni corrette |
Prevenzione
Verificare la completezza delle traduzioni per famiglie di record e lingue di maggior valore. Normalizzare codifica e HTML. Decidere dove il fallback è accettabile e dove il contenuto mancante deve rimanere non pubblicato finché non viene completato. Trattare collegamenti, riferimenti ai media e campi SEO come relazioni localizzate, non come semplice testo.
Esempio di raccomandazione
Un Product ha contenuti francesi completi e soltanto il nome in inglese. Pubblicare normalmente la versione francese, applicare la policy di fallback inglese approvata ed evitare che una descrizione inglese incompleta erediti un collegamento al dominio francese di origine.
Condizione di superamento
Ogni lingua pubblicata mostra il linguaggio previsto, percorsi e media risolvono nel corretto contesto di negozio e le traduzioni mancanti seguono una regola deliberata di fallback o pubblicazione anziché un’eredità accidentale.
Problema 10: conservare identificativi esterni senza conservarne gli utilizzatori
Cosa va storto
I database di origine contengono spesso ID ERP, chiavi fornitore, ID marketplace, riferimenti Product legacy e valori di ricerca specifici dei moduli. Copiarli in un campo note arbitrario conserva i caratteri ma non la funzione. Ometterli può interrompere la riconciliazione; duplicarli può far sì che sistemi collegati aggiornino il record sbagliato.
Segnali di allarme iniziali
I team sanno elencare gli identificativi ma non possono dire quale sistema li possiede, se devono essere univoci o come verranno interrogati dopo la migrazione.
| Identificativo | Domanda sull’utilizzatore | Requisito sulla destinazione |
|---|---|---|
| ID ERP Product o combinazione | Quale processo di sincronizzazione lo usa? | Campo stabile e univoco esposto all’integrazione |
| ID inserzione marketplace | L’inserzione rimane attiva? | Relazione continuativa con il canale oppure ritiro deliberato |
| Riferimento Order legacy | Chi lo cerca? | Riferimento storico visibile e ricercabile |
Prevenzione
Creare un contratto degli identificativi: campo di origine, proprietario del record, posizione di destinazione, regola di unicità, formato e sistema che lo utilizza. Conservare soltanto identificativi attivi o con valore di evidenza. Mantenere distinte le chiavi del Product padre e delle combinazioni. Testare ricerca e aggiornamento tramite l’integrazione o il processo operativo che continuerà a usarli.
Esempio di raccomandazione
Se un ERP aggiorna lo stock tramite il riferimento della combinazione, collocare quel riferimento sulla combinazione vendibile di destinazione o sul record di integrazione. Non conservarlo soltanto sul Product padre o in una nota amministrativa che il processo di sincronizzazione non può interrogare.
Condizione di superamento
Ogni identificativo esterno richiesto è univoco dove previsto, recuperabile dal sistema che continuerà a utilizzarlo, associato al livello di record corretto e dimostra di supportare la riconciliazione o il funzionamento dell’integrazione.
Priorità di prevenzione comuni ai diversi problemi
I rischi ricorrenti di PrestaShop possono essere controllati attraverso tre percorsi di revisione collegati.
| Priorità di prevenzione | Cosa protegge | Evidenza richiesta prima dell’approvazione |
|---|---|---|
| Conservare il significato di combinazioni e stock | Combinazioni, attributi, ubicazioni e inventario vendibile | Products rappresentativi mantengono scelte, identificativi, proprietà dello stock e disponibilità corretti. |
| Conservare contesto multistore e commerciale | Proprietà dei negozi, gruppi Customer, localizzazione, Categories e prezzi | I record compaiono nel corretto negozio, lingua, valuta, gruppo e contesto di navigazione. |
| Separare moduli e integrazioni dai record migrati | Override, temi, identificativi esterni e sistemi operativi che continuano a consumarli | Ogni dipendenza non core ha un proprietario sulla destinazione, una decisione di implementazione e un metodo di validazione. |
Conclusione
Un risultato PrestaShop affidabile nasce da relazioni esplicite: Products con combinazioni, Categories con percorsi di scoperta, Customers con gruppi, record con negozi e lingue e valori personalizzati con moduli o integrazioni che continueranno a utilizzarli. Quando queste relazioni vengono definite e testate attraverso scenari di business rappresentativi, la migrazione può conservare il modo in cui il negozio opera, non soltanto ciò che contiene il database.
Domande frequenti
Perché le combinazioni di PrestaShop rappresentano un rischio importante nella migrazione?
Le combinazioni possono possedere differenze di SKU, prezzo, immagine, peso e stock. Appiattirle in caratteristiche o Products separati modifica la struttura vendibile e può influire sul comportamento di carrello e inventario.
Il multistore richiede copie separate di ogni record?
Non necessariamente. Alcuni dati possono essere condivisi mentre altri valori sono specifici del negozio. La migrazione deve conservare la proprietà prevista invece di duplicare tutto o trattare un negozio come universale.
Ogni tabella di un modulo deve essere migrata?
No. Un record del modulo dovrebbe essere conservato soltanto quando un componente di destinazione o un processo operativo continuativo ne ha bisogno. Dati di moduli inattivi o orfani non dovrebbero essere copiati per semplice completezza.
Come devono essere valutati i gruppi Customer?
Valutare il risultato commerciale collegato a ogni gruppo, come prezzi, visibilità, visualizzazione fiscale o accesso, non soltanto se esiste l’etichetta del gruppo.
Qual è il modo più sicuro per conservare gli URL di PrestaShop?
Utilizzare un registro dei percorsi che riporti percorso di origine, negozio, lingua, destinazione e responsabile del redirect per Products, Categories, pagine CMS e campagne prioritarie.
Cosa dimostra che gli identificativi esterni sono stati conservati correttamente?
Il processo ERP, magazzino, marketplace o assistenza che continua a operare riesce a trovare e aggiornare il record di destinazione previsto utilizzando l’identificativo conservato al corretto livello Product, combinazione, Customer o Order.