Quando Square viene valutato come piattaforma di destinazione, il rischio di migrazione si concentra soprattutto ai confini tra sistemi. Square collega un catalogo articoli tipizzato al Point of Sale, a inventario legato alle sedi, Customers, Orders, pagamenti, evasione degli ordini e Square Online. Un record può quindi essere presente e generare comunque rischio operativo se viene collegato all’oggetto di catalogo sbagliato, alla sede sbagliata, a un’identità Customer errata, al contesto di transazione sbagliato o all’applicazione sbagliata.
L’assunzione più pericolosa consiste nel trattare Square come un database generico di negozio online. Non lo è. Articoli, varianti, opzioni, modificatori, Categories, imposte, sconti e attributi personalizzati svolgono ruoli differenti. L’inventario appartiene a relazioni tra variante e sede. Gli Orders storici conservano evidenze della transazione ma non configurano il comportamento corrente di pagamenti, imposte o evasione. Square Online introduce responsabilità su sito e percorsi che sono separate dal trasferimento del catalogo.
Una revisione utile dei rischi segue una catena completa: assunzione dell’origine, vincolo Square, conseguenza della migrazione, impatto operativo, direzione di mitigazione e segnale che dimostra che il rischio è sotto controllo.
Il rischio in Square parte dalla proprietà di oggetti e sistemi
I domini Square relativi a catalogo, inventario, Customer, Order e sito online sono collegati, ma non condividono un record universale. Il rischio aumenta quando un campo dell’origine viene spostato nella destinazione visivamente più vicina invece che nell’oggetto Square che possiede lo stesso significato aziendale.
| Assunzione dell’origine | Vincolo Square | Conseguenza della migrazione | Impatto operativo | Indicazione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| Una riga Product contiene l’intero articolo vendibile. | Square separa articoli, varianti e altri oggetti Catalog. | SKU, prezzo, stock, immagine o dati di misura possono finire al livello sbagliato. | Il personale vende o analizza la variante sbagliata e le integrazioni non riescono a riconoscere l’articolo di stock previsto. | Definire l’articolo padre e ogni variante gestita in modo indipendente prima di mappare i campi. | Ogni identificativo vendibile dell’origine risolve una specifica variante Square prevista. |
| Ogni scelta dell’acquirente è una variante. | Square distingue opzioni, varianti e modificatori applicati al momento della vendita. | Extra opzionali diventano false unità di inventario oppure vere varianti perdono la propria identità di stock. | La selezione al POS diventa confusa e i conteggi inventariali poco affidabili. | Classificare le scelte in base al fatto che creino un articolo con prezzo, stock o identità propri. | Strutture di varianti e modificatori corrispondono al modo in cui il personale vende ed evade l’articolo. |
| Una sola quantità di stock è sufficiente. | L’inventario Square è sensibile a variante e sede e registra cambiamenti di stato. | Una quantità aggregata può essere assegnata alla sede o variante sbagliata. | Sovravendite, indisponibilità e differenze di riconciliazione emergono tra sedi. | Dichiarare il proprietario dell’inventario e mappare la quantità a livello variante-sede. | Conteggio iniziale e assegnazione della sede corrispondono al modello operativo dichiarato. |
| Gli Orders storici ricreano l’operatività attiva. | Gli Orders conservano il contesto della transazione; pagamenti, imposte ed evasione correnti sono configurati separatamente. | Lo storico importato viene scambiato per una configurazione attiva di checkout o evasione. | L’azienda può consultare vecchie vendite ma non elaborarne di nuove in modo affidabile. | Mantenere evidenza storica e configurazione operativa attiva come controlli separati. | Il personale interpreta gli Orders storici senza considerarli prova della preparazione corrente. |
| Square Online viene ricreato dal trasferimento del catalogo. | Il sito online ha proprie relazioni per pagine, navigazione, dominio, percorsi e presentazione. | Gli articoli esistono ma percorsi chiave dell’acquirente, contenuti o continuità URL restano incompleti. | Si perdono traffico e capacità di scoperta anche se il conteggio del catalogo è corretto. | Assegnare una destinazione online a ogni percorso e contenuto di origine ad alto valore. | I percorsi prioritari conducono alla destinazione Square Online prevista. |
Questa mappa della proprietà è la base delle catene di rischio dettagliate che seguono. Senza di essa, i controlli successivi possono dimostrare che i record esistono senza dimostrare che Square sia in grado di utilizzarli correttamente.
Confondere articoli, varianti, opzioni e modificatori
Il rischio principale del catalogo è la compressione semantica. Una piattaforma di origine può usare una sola tabella di opzioni per taglia, colore, confezione regalo, preferenza di preparazione, incisione, selezione bundle e specifiche tecniche. Square non tratta tutti questi valori nello stesso modo.
Una variante rappresenta una versione acquistabile di un articolo. Un’opzione dell’articolo può standardizzare i valori che definiscono tali varianti. Un modificatore rappresenta una modifica o un’aggiunta scelta al momento della vendita. Un attributo personalizzato può conservare informazioni strutturate senza diventare una scelta dell’acquirente. Se questi ruoli vengono confusi, il catalogo visibile può apparire ragionevole mentre il comportamento reale di vendita e reportistica è errato.
| Catena di rischio | Causa e conseguenza | Impatto operativo | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|---|
| Gli SKU figli dell’origine vengono appiattiti in un unico articolo. | L’articolo padre riceve scelte descrittive, ma scompaiono SKU, prezzo, inventario, immagine o relazioni di misura a livello variante. | Il personale POS non identifica l’articolo corretto; inventario e corrispondenza con sistemi esterni diventano ambigui. | Conservare ogni figlio gestito in modo indipendente come variante prevista dell’articolo. | Gli articoli rappresentativi con molte varianti mantengono identificativi e valori commerciali univoci. |
| Gli extra opzionali diventano varianti. | Confezione regalo, preferenze di preparazione o servizi opzionali creano combinazioni che non sono veri articoli di stock. | Il catalogo si espande, lo stock si frammenta e il personale affronta scelte inutili. | Rappresentare le aggiunte al momento della vendita tramite modificatori quando non definiscono identità di inventario. | Gli extra compaiono sulla riga Order senza creare falsi record di stock. |
| Vere varianti diventano modificatori. | Scelte come taglia o colore restano visibili ma non possiedono più SKU, stock, prezzo o immagine. | L’acquirente può scegliere un’etichetta, ma l’azienda non può gestire l’articolo selezionato come unità vendibile distinta. | Usare varianti per le combinazioni con identità commerciale indipendente. | La riga Order selezionata punta alla variante e al record inventariale corretti. |
| Le specifiche Product diventano scelte dell’acquirente. | Fatti descrittivi vengono inseriti in strutture di opzioni o modificatori. | Il personale mantiene combinazioni irrilevanti e i Customers incontrano input confusi. | Conservare i fatti non selezionabili nelle descrizioni o in attributi personalizzati adeguati. | Le specifiche restano informative senza cambiare la variante acquistata. |
| I bundle vengono trattati come un normale articolo singolo. | Identità dei componenti e proprietà dello stock vengono perse. | Il prezzo visualizzato può restare corretto mentre disponibilità dei componenti ed evasione non sono più spiegabili. | Definire se il bundle è un’offerta di catalogo, una relazione di sconto, una struttura posseduta da un’applicazione o un assemblaggio esterno. | Il sistema che possiede lo stock dei componenti continua a identificare ogni elemento incluso. |
I responsabili coinvolti sono amministratori del catalogo, personale retail, team di inventario e sistemi collegati. La mitigazione non consiste nel ricreare ogni tabella dell’origine, ma nel preservare la più piccola unità commerciale che Square, il personale e i sistemi esterni riconoscono in modo coerente.
Interpretare male sedi e stati dell’inventario
L’inventario Square deriva da conteggi fisici e cambiamenti di stato. Può inoltre essere influenzato da Orders completati e applicazioni esterne. Per questo la migrazione dell’inventario è più complessa della copia di una colonna quantità.
Il primo vincolo riguarda la granularità: la quantità appartiene a una variante in una sede. Il secondo riguarda l’autorità: Square può essere il proprietario dell’inventario oppure ricevere aggiornamenti da magazzino, ERP, hub marketplace o altro sistema autorevole. Il terzo riguarda il tempo: un conteggio iniziale non dovrebbe riprodurre vendite o rettifiche storiche come nuovi eventi.
| Assunzione | Vincolo Square | Conseguenza della migrazione | Impatto operativo | Indicazione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| I magazzini di origine possono essere sommati in sicurezza. | Le sedi Square conservano la proprietà operativa dello stock. | Un conteggio aggregato elimina l’informazione su quale filiale, magazzino o punto di evasione possiede le unità. | Decisioni di ritiro, vendita e riapprovvigionamento usano disponibilità errate. | Mappare i pool di stock dell’origine alle sedi Square previste prima di assegnare le quantità. | I totali per sede si riconciliano con il modello operativo dichiarato. |
| Lo stock a livello Product può essere copiato sull’articolo padre. | Square traccia l’inventario sulle varianti degli articoli. | La quantità viene separata dallo SKU vendibile. | Un Product appare disponibile mentre la variante selezionata è indisponibile o non tracciata. | Collegare lo stock alla variante usata da POS, Orders e integrazioni. | Ogni identificativo vendibile tracciato ha una relazione inventariale chiara. |
| Gli eventi inventariali storici devono essere riprodotti. | Square calcola l’inventario tramite transizioni di stato ordinate e conteggi fisici. | Lo storico importato può applicare nuovamente decrementi o alterare la posizione iniziale prevista. | I conteggi divergono immediatamente e il personale perde fiducia nell’inventario. | Stabilire lo stato iniziale previsto e conservare gli eventi passati soltanto nel loro proprietario storico. | Il conteggio iniziale è spiegabile senza riprodurre il commercio passato. |
| Un conteggio una tantum risolve la sincronizzazione futura. | I sistemi esterni proprietari dell’inventario continuano a pubblicare modifiche dopo la migrazione. | Square parte correttamente ma diverge perché gli aggiornamenti usano ID mancanti o errati. | Le differenze di stock riappaiono tra canali e sedi. | Conservare identificativi di variante, sede e sistema esterno usati dall’integrazione futura. | Un aggiornamento del sistema autorevole raggiunge variante e sede previste. |
| Zero, indisponibile e non soggetto a stock significano la stessa cosa. | La disponibilità Square dipende da impostazioni di catalogo e inventario, non soltanto da un numero. | Servizi, articoli senza limite, esauriti e inattivi vengono interpretati nello stesso modo. | Articoli validi diventano non vendibili oppure articoli indisponibili restano esposti. | Classificare separatamente casi tracciati a stock, non a stock, servizi e indisponibili. | Ogni classe mostra il comportamento di vendita previsto senza quantità fuorvianti. |
Il rischio inventariale incide direttamente sui ricavi. Il controllo strutturale consiste nel fare in modo che la stessa identità variante-sede sia compresa da Square, dal personale del negozio e da ogni sistema che continuerà a possedere lo stock.
Confini tra Orders storici, pagamenti, rimborsi ed evasione
Gli Orders Square possono includere righe, riferimenti alle varianti, modificatori, imposte, sconti, costi di servizio, mance, relazioni Customer, origine, sede, evasione, pagamenti e rimborsi. La migrazione storica può conservare gran parte di questo contesto, ma non può trasformare un vecchio gateway, un processo di spedizione o un modello di stato dell’origine nella configurazione Square corrente.
| Catena di rischio | Conseguenza della migrazione | Impatto operativo | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|---|
| Le etichette di stato dell’origine vengono copiate senza interpretazione. | Una sola etichetta può combinare significati di pagamento, evasione, annullamento o reso che Square registra separatamente. | Il personale interpreta male se un Order è stato pagato, evaso, rimborsato o richiede ancora azione. | Tradurre il significato storico in un contesto leggibile di Order, pagamento, rimborso ed evasione. | Orders rappresentativi complessi possono essere compresi senza consultare il sistema di origine. |
| Le righe Order sono collegate soltanto agli articoli padre. | La variante acquistata o la selezione del modificatore viene persa. | Assistenza e riconciliazione non possono identificare cosa il Customer ha effettivamente acquistato. | Conservare le istantanee delle righe e riferimenti affidabili a variante o modificatore quando disponibili. | La riga mostra identità acquistata e scelte effettuate al momento della vendita. |
| I riferimenti storici di pagamento vengono trattati come dati di pagamento riutilizzabili. | L’evidenza della transazione viene scambiata per un metodo o una credenziale di pagamento attivi. | I team presumono di poter effettuare rimborsi o nuovi addebiti tramite dati che documentano soltanto il passato. | Conservare riferimenti non sensibili per la riconciliazione mantenendo separata la configurazione dei pagamenti attivi. | Il personale può tracciare la transazione senza esporre o usare impropriamente credenziali. |
| Lo storico di evasione viene trattato come configurazione di consegna corrente. | Vecchi vettori, ritiri, spedizioni o etichette di consegna vengono copiati senza una responsabilità operativa corrente. | I nuovi Orders seguono percorsi di evasione incompleti o errati. | Conservare l’evidenza storica dell’evasione e definire indipendentemente i metodi correnti. | Record storici e correnti di evasione sono chiaramente distinguibili. |
| Gli Orders importati producono effetti di stock indesiderati. | L’attività storica degli Orders viene confusa con nuovo commercio che modifica l’inventario. | Lo stock viene ridotto una seconda volta o le quantità iniziali diventano incoerenti. | Separare le responsabilità dello storico Orders da quelle dell’inventario iniziale. | Lo storico è leggibile mentre la posizione iniziale dello stock resta stabile. |
I responsabili coinvolti sono assistenza clienti, finanza, operations e inventario. La mitigazione consiste nel preservare l’evidenza della transazione senza attribuire autorità operativa attiva ai record storici.
Identità Customer, gruppi, fidelizzazione e profili posseduti dalle app
I profili Customer Square possono contenere identità, contatti, indirizzi, gruppi, segmenti, preferenze, ID di riferimento e attributi personalizzati. Altri prodotti Square e applicazioni collegate possono possedere relazioni di fidelizzazione, appuntamenti, ristorazione, abbonamenti, consegna o CRM. Una tabella “Customer” dell’origine può quindi mescolare più identità che non appartengono a un unico profilo Square.
| Assunzione | Vincolo della piattaforma | Conseguenza della migrazione | Indicazione di mitigazione | Segnale di controllo |
|---|---|---|---|---|
| L’email da sola dimostra l’identità. | Vendite guest, indirizzi condivisi, email cambiate, account duplicati e ID esterni possono rappresentare persone o storie differenti. | Customers non correlati vengono fusi oppure una sola persona diventa più profili scollegati. | Usare una gerarchia di identità documentata che includa ID origine, email, telefono, collegamenti Orders e chiavi esterne. | Customers ad alto valore o soggetti a duplicazione risolvono nel profilo previsto. |
| Ogni record acquirente deve diventare un Customer persistente. | Il contesto di una transazione guest può esistere senza relazione di account durevole. | Profili artificiali gonfiano l’elenco Customers e distorcono consenso o segmentazione. | Conservare l’identità guest nell’Order salvo che una relazione Customer durevole sia giustificata. | Lo storico guest resta utilizzabile senza inventare significato di account non supportato. |
| I gruppi dell’origine ricreano fidelizzazione o segmentazione Square. | Gruppi Customer, segmenti, programmi fedeltà e membership possedute da app hanno proprietari diversi. | Le etichette restano, ma idoneità, saldo o funzionamento del programma scompaiono. | Separare il raggruppamento descrittivo dal sistema che possiede benefici e attività. | Il sistema di fidelizzazione o segmentazione futuro riconosce la stessa chiave Customer. |
| Lo stato marketing è un normale dato di contatto. | Consenso e preferenze di comunicazione hanno scopo e provenienza propri. | Contatti importati possono essere trattati come contattabili senza una relazione valida. | Conservare soltanto dati di preferenza supportati con significato e proprietà chiari. | I sistemi marketing distinguono identità di contatto e stato del consenso. |
| I campi personalizzati sono innocue note profilo. | Sistemi esterni o app possono dipendere da attributi Customer strutturati e ID di riferimento. | Assistenza, reportistica o sincronizzazione perdono il collegamento con l’account autorevole. | Mappare identificativi durevoli a campi strutturati o alla relazione con l’applicazione futura. | Un CRM o un’app collegata risolve correttamente il Customer Square. |
Il controllo non consiste nell’importare il massimo numero possibile di Customers. Consiste in un modello di identità che impedisca fusioni errate, account non supportati e relazioni applicative orfane.
Square Online, contenuti, navigazione e continuità degli URL
Square Online utilizza i dati commerciali ma aggiunge responsabilità proprie a livello di sito. Products e Categories possono esistere nel catalogo mentre il negozio online continua a non disporre delle pagine previste, dei percorsi di menu, del comportamento del dominio, dei contenuti o della continuità URL.
La catena di rischio spesso parte dall’idea che migrare il catalogo ricrei il negozio online. Il vincolo di Square è che proprietà del catalogo e proprietà del sito sono collegate ma separate. La conseguenza è un catalogo popolato senza un percorso d’acquisto completo. L’impatto operativo è perdita di capacità di scoperta, traffico e conversioni.
| Risorsa di origine | Vincolo e rischio | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|
| Percorso Product o Category | Square Online può generare un percorso e un contesto di presentazione differenti. | Assegnare una destinazione canonica e una relazione di redirect ai percorsi prioritari dell’origine. | I vecchi URL ad alto valore risolvono nella destinazione live prevista. |
| CMS Page o contenuto legale | Il contenuto può richiedere una pagina Square Online o un altro proprietario definito. | Separare il contenuto della pagina dalla navigazione e dal posizionamento nel tema. | Il contenuto ha una destinazione autorevole e un percorso raggiungibile. |
| Blog o archivio editoriale | Supporto e struttura di pubblicazione possono differire dall’origine. | Definire se il contenuto resta in Square Online, in un altro CMS o in un archivio intenzionale. | I link editoriali non portano a pagine mancanti o non correlate. |
| Gerarchia di menu | Le Categories degli articoli non riproducono necessariamente la navigazione del sito. | Ricostruire la navigazione come relazione di sito che punta alle destinazioni corrette di catalogo o contenuto. | I percorsi prioritari dell’acquirente non dipendono da menu orfani o da assunzioni sulle Categories. |
| Script e widget incorporati | Snippet, applicazioni e codice specifico dell’origine hanno proprietari diversi. | Ricreare soltanto il comportamento di integrazione o presentazione necessario nel livello sito supportato. | Il risultato aziendale esiste senza copiare codice dell’origine obsoleto. |
| Media e link interni | I file possono essere spostati mentre i percorsi incorporati restano legati al dominio di origine. | Riscrivere i riferimenti nei contenuti e preservare la proprietà degli allegati. | Immagini e link interni risolvono dalle pagine previste. |
Il rischio strutturale è controllato quando proprietà dei contenuti, intento dei percorsi e destinazione futura sono espliciti. La verifica a livello pagina può quindi testare queste relazioni dichiarate senza ridefinirle.
Applicazioni collegate, attributi personalizzati e rischio dei sistemi esterni
Square può collegarsi ad applicazioni di contabilità, inventario, fidelizzazione, appuntamenti, ristorazione, consegna, CRM, abbonamenti, analytics e altre funzioni. La presenza di un campo nell’origine non dimostra che il core Square possieda il record corrispondente.
| Assunzione sulla dipendenza | Vincolo Square | Conseguenza della migrazione | Impatto operativo | Indicazione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| Applicazioni simili usano lo stesso modello dati. | Ogni applicazione può possedere entità, stati e identificativi distinti. | I dati vengono inseriti in campi generici senza il processo che li utilizza. | Il personale vede valori che nessun sistema mantiene o comprende. | Identificare l’entità applicativa reale e il proprietario futuro prima di tradurre i dati. | L’applicazione di destinazione riesce a risolvere il proprio Item, Customer o Order padre. |
| Gli ID esterni possono essere rigenerati. | ERP, CRM, magazzino, marketplace e contabilità possono considerare autorevole la chiave esistente. | Riconciliazione e sincronizzazione puntano a record nuovi o duplicati. | Aggiornamenti di stock, Customer e Order falliscono o si collegano all’oggetto sbagliato. | Conservare identificativi stabili alla stessa granularità dell’oggetto Square usata dal sistema esterno. | Una ricerca andata e ritorno restituisce il record Square previsto. |
| Gli attributi personalizzati preservano il comportamento personalizzato. | Un attributo personalizzato conserva dati ma non riproduce script o processi dell’origine. | Il valore arriva, mentre scompaiono logiche di prezzo, visibilità, approvazione o automazione. | Automazioni o regole commerciali smettono di funzionare anche se il campo è presente. | Separare il dato descrittivo dal comportamento che lo utilizza. | Il proprietario di destinazione sia del valore sia del comportamento è documentato. |
| Lo storico delle applicazioni appartiene al core Square. | Prenotazioni, fidelizzazione, abbonamenti, ristorazione e consegna possono vivere in domini separati. | Lo storico specializzato viene appiattito in note Customer o Order. | L’assistenza non riesce a capire diritto, pianificazione, saldo o stato di partecipazione. | Conservare record specializzati soltanto in un dominio compatibile o in un archivio intenzionale. | Il personale può accedere allo storico dell’applicazione futura tramite il suo proprietario reale. |
| La connettività API garantisce equivalenza di migrazione. | L’accesso API espone risorse definite ma non crea semantiche aziendali mancanti. | I team sovrastimano ciò che può essere rappresentato con oggetti standard Catalog, Customer o Order. | Le lacune di ambito emergono dopo la ricostruzione delle integrazioni. | Valutare proprietà delle risorse e compatibilità delle relazioni, non la sola presenza dell’API. | Ogni integrazione futura dispone di una mappa esplicita delle entità origine-destinazione. |
I responsabili coinvolti comprendono ingegneri delle integrazioni, operations, finanza, marketing e amministratori delle applicazioni. La mitigazione richiede un registro delle responsabilità, non un semplice inventario di campi personalizzati.
Responsabilità dei rischi tra più domini
I rischi Square si amplificano quando più domini condividono una stessa assunzione debole. Una variante appiattita può influire contemporaneamente su inventario, Orders, POS, Square Online ed ERP. Un Customer fuso può influire su assistenza, fidelizzazione, marketing e rimborsi. Un URL interrotto può danneggiare il traffico di ricerca anche se il catalogo è corretto.
| Rischio tra domini | Proprietario principale | Proprietari di supporto | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|---|
| Identità del catalogo | Amministratore catalogo | Retail, inventario, integrazioni | Definire articoli padre, varianti vendibili, modificatori e ID durevoli. | Tutti i sistemi dipendenti fanno riferimento alla stessa unità vendibile. |
| Autorità sull’inventario | Responsabile inventario o operations | Responsabili sedi, integrazioni | Definire proprietà variante-sede e responsabilità dello stato iniziale. | I conteggi si riconciliano senza doppia applicazione di eventi storici. |
| Storico transazioni | Responsabile assistenza clienti o finanza | Operations, pagamenti, evasione | Conservare istantanee leggibili e relativa evidenza finanziaria/di evasione. | Orders storici complessi possono essere spiegati end-to-end. |
| Identità Customer | Responsabile operations Customer | Marketing, fidelizzazione, CRM | Definire matching, trattamento guest, consenso e chiavi esterne. | Non restano fusioni errate materiali né profili orfani. |
| Continuità online | Responsabile sito | SEO, contenuti, catalogo | Assegnare percorsi, navigazione, contenuti e redirect separatamente dalla migrazione degli articoli. | I percorsi di traffico prioritari raggiungono destinazioni utilizzabili. |
| Continuità applicativa | Responsabile applicazione | Responsabili integrazioni e dati | Mappare record specializzati e identificativi al sistema che continuerà a possederli. | Il processo di destinazione riconosce gli stessi oggetti aziendali padre. |
Un rischio è controllato quando il responsabile può spiegare il vincolo Square, la mitigazione prevista e l’evidenza che dimostra la coerenza della relazione. In questo modo una semplice avvertenza diventa una condizione governabile e verificabile.
Conclusione
I vincoli della migrazione verso Square derivano dal modo in cui oggetti Catalog, sedi, stati inventariali, Customers, Orders, Square Online e applicazioni dividono la proprietà. Le assunzioni a rischio più elevato sono che tutte le scelte dell’acquirente siano varianti, che lo stock sia un solo numero Product, che gli Orders storici configurino le operazioni attive, che i Customers possano essere associati soltanto tramite email e che il trasferimento del catalogo ricrei il negozio online.
Una migrazione controllata preserva la più piccola identità vendibile, mappa l’inventario alla variante e sede corrette, separa transazioni storiche e configurazione corrente, protegge chiavi Customer e dei sistemi esterni e assegna ogni record online o applicativo a un proprietario futuro. Questi controlli affrontano la conseguenza operativa alla radice invece di affidarsi soltanto ai conteggi dei record.
Domande frequenti
Qual è il rischio più importante nel catalogo Square?
Il rischio principale è confondere articoli, varianti, opzioni e modificatori. Una struttura errata può apparire accettabile nella Dashboard ma indebolire identità SKU, inventario, selezione POS, significato delle righe Order e corrispondenza con sistemi esterni.
Perché il rischio inventariale in Square dipende dalla sede?
L’inventario Square è collegato a una variante e a una sede ed è influenzato da conteggi e cambiamenti di stato. Una quantità aggregata può conservare il totale ma assegnare le unità alla filiale, al magazzino o al punto di evasione sbagliati.
Gli Orders storici possono dimostrare che Square è pronto per nuove vendite?
No. Gli Orders storici conservano evidenza delle transazioni. Comportamento corrente di pagamenti, imposte, sconti, evasione, notifiche e inventario appartiene alla configurazione Square attiva e ai sistemi collegati.
Perché il conteggio dei Customers può essere corretto mentre la migrazione Customer resta rischiosa?
I conteggi non mostrano fusioni errate, identità duplicate, trattamento dei guest, significato del consenso, proprietà della fidelizzazione o identificativi CRM interrotti. Il rischio è sotto controllo soltanto quando le relazioni Customer e applicative previste restano coerenti.
Spostare il catalogo Square ricrea Square Online?
No. Square Online richiede anche pagine del sito, navigazione, percorsi, domini, presentazione, riferimenti ai media e relazioni di redirect. La presenza del catalogo è una dipendenza del sito, non l’intero modello del sito.
Come vanno trattati i dati Square posseduti da applicazioni?
Identificare l’entità dell’applicazione, il relativo Item, Customer o Order padre e l’identificativo stabile usato dal processo futuro. Lo storico specializzato deve restare in un dominio applicativo compatibile o in un archivio deliberato, invece di essere appiattito in note generiche.