Déplacer des données commerciales vers Square n’est pas un exercice de copie de champs. Square représente le catalogue, le stock, les Customers et les transactions du marchand au moyen d’objets reliés ayant chacun un rôle opérationnel distinct. Un Product source peut devenir un article du catalogue avec une ou plusieurs variations. Une valeur sélectionnable peut définir une item option, une variation vendable, un modifier ou une information saisie par l’acheteur. Le stock appartient à une variation précise dans le contexte d’un point de vente. Un Order historique conserve ce qui s’est produit, mais il ne devient pas la configuration qui régit les futurs paiements, le traitement des commandes, la fiscalité ou la présentation en ligne.
La question centrale n’est donc pas de savoir si Square possède un champ au nom familier. Il faut déterminer quel objet Square doit posséder l’enregistrement cible et si celui-ci reste relié aux autres enregistrements qui lui donnent son sens commercial. Lorsque ces relations sont conservées, le personnel peut vendre la bonne variation, comprendre le stock par point de vente, retrouver Customers et Orders, réconcilier les identifiants externes et publier un contenu Square Online cohérent. Lorsqu’elles sont aplaties, les données peuvent sembler complètes tout en produisant un fonctionnement incorrect.
Le sens des données Square repose sur des objets commerciaux reliés
Le catalogue Square se compose d’objets typés plutôt que d’un enregistrement Product universel. Les catalog items décrivent des produits ou services. Les item variations représentent les versions achetables. Les item options peuvent standardiser les valeurs qui définissent les variations. Les modifier lists décrivent les changements ou ajouts choisis au moment de la vente. Les Categories organisent les articles. Taxes, remises, règles tarifaires, images, unités de mesure et custom attributes peuvent participer à la relation catalogue plus large.
Une plateforme source peut stocker plusieurs de ces significations dans une seule table Product, un Product configurable ou une structure appartenant à une application. La migration doit séparer l’enregistrement source en objets cibles correspondant réellement à chaque fonction.
| Hypothèse côté boutique source | Sens de la relation dans Square | Conséquence pour la représentation cible |
|---|---|---|
| Une ligne Product représente l’unité vendable complète | L’article et sa variation peuvent être des objets distincts mais reliés | Conserver l’article parent tout en attribuant SKU, prix, stock et autres identifiants vendables à la bonne variation. |
| Toute option est une variante | Certains choix définissent des variations ; d’autres sont des modifiers ou des informations saisies par l’acheteur | Classer l’effet commercial du choix avant de créer les enregistrements cibles. |
| Une seule quantité de stock appartient au Product | Le stock est relié à une variation et au contexte d’un point de vente | Une quantité est incomplète sans la variation vendable et le point de vente opérationnel. |
| Les Categories recréent tout le storefront | Les Categories du catalogue et la structure du site Square Online sont reliées mais non équivalentes | Conserver la classification du catalogue séparément des pages, de la navigation et des URL. |
| L’historique Customer recrée le fonctionnement du compte | Les profils Customers conservent identité et relations commerciales, mais pas tous les modèles d’accès ou d’adhésion de la source | Séparer les données Customer durables des règles d’accès et fonctions propres à la source. |
| Les Orders importés configurent les ventes futures | Les Orders décrivent les transactions ; la configuration reste possédée par les paiements, le traitement des commandes, la fiscalité et les autres paramètres Square | Conserver l’instantané de transaction sans l’interpréter comme une configuration opérationnelle. |
Cette vision par objets explique aussi pourquoi les identifiants externes sont importants. Un identifiant Product source, une clé d’entrepôt, un identifiant CRM Customer ou une référence comptable doit être attaché à l’objet Square reconnu par le système connecté. Une note générique sur l’article parent ne remplace pas correctement un identifiant d’entrepôt propre à une variation lorsque l’entrepôt considère chaque variation comme un article de stock distinct.
Articles, variations, options et modifiers portent des significations de vente différentes
La distinction la plus importante du catalogue oppose l’article et sa variation. L’article décrit la famille de produit ou de service. Une variation identifie une version achetable et peut posséder son propre SKU, prix, unité de mesure, relation d’image et sens pour le stock. Même un Product source sans options visibles peut devenir un article Square avec une variation unique ou par défaut, car c’est la variation qui représente l’objet vendable utilisé par les autres relations Square.
Les item options standardisent les caractéristiques qui définissent les variations, comme la taille, la couleur ou le style. Une variation peut référencer les valeurs choisies, ce qui permet à Square de comprendre la combinaison au lieu de dépendre d’un simple nom d’affichage. Les variantes source doivent donc être interprétées à partir de leur Product parent et des valeurs qui rendent chaque combinaison vendable distincte.
Les modifiers ont un autre rôle. Ils représentent un changement ou un ajout sélectionné au moment de la vente et ne créent pas automatiquement une identité distincte avec stock propre. Un supplément fromage, un emballage cadeau, une préférence de préparation ou un service optionnel correspondent souvent à des modifiers. Une taille ayant son propre SKU et son propre stock correspond généralement davantage à une variation. Transformer un modifier en variation crée de faux enregistrements de stock ; transformer une véritable variation en modifier supprime l’identité vendable dont le stock et les systèmes externes ont besoin.
| Modèle source | Responsable Square probable | Sens à préserver |
|---|---|---|
| Product simple avec un SKU | Article et une variation | Description au niveau de l’article ; SKU, prix et identité de stock au niveau de la variation. |
| Combinaisons taille/couleur | Item options, valeurs d’options et variations | Chaque combinaison achetable reste distincte et reliée au bon article parent. |
| Supplément ou service optionnel | Modifier list et modifier | Choix au moment de la vente et effet sur le prix sans inventer un SKU avec stock propre. |
| Gravure ou instruction de l’acheteur | Modifier, saisie personnalisée, note de ligne Order ou enregistrement d’application selon le fonctionnement pris en charge | La valeur fournie par le client reste attachée à la ligne achetée et visible pour le traitement. |
| Kit, bundle ou package | Article, relation entre composants, règle tarifaire, application connectée ou système externe | Identité des composants, formation du prix, responsabilité du stock et finalité du reporting sont attribuées explicitement. |
| Service, rendez-vous, abonnement ou droit numérique | Article du catalogue plus le produit Square ou système connecté qui possède la planification, la récurrence ou l’accès | L’enregistrement catalogue reste distinct du système qui contrôle le temps, la facturation ou le droit d’accès. |
Images, taxes, remises, unités de mesure et custom attributes doivent être attribués avec la même rigueur. Une image peut appartenir à un article, une variation ou une relation de Category. Une taxe ou remise peut être un objet réutilisable référencé par des articles et Orders. Un custom attribute doit avoir un consommateur connu, comme le personnel, le reporting, une intégration ou un autre processus Square. Une valeur sans responsable cible ne préserve pas un sens métier : elle ajoute seulement du bruit.
Categories, menus, images et relations de merchandising
Les Categories source remplissent souvent plusieurs fonctions à la fois : hiérarchie, navigation, merchandising, reporting, contrôle d’accès, pages d’atterrissage SEO et campagnes. Les Square Catalog Categories conservent la classification du catalogue tandis que les pages, la navigation et la présentation merchandising dans Square Online peuvent introduire des relations distinctes. La migration doit préserver la fonction durable de classification sans supposer que l’ancienne arborescence du storefront peut être recréée uniquement avec les enregistrements Category.
Une hiérarchie source profonde peut devenir une classification plus simple du catalogue combinée à une navigation ou une structure de pages Square Online. Une collection source peut représenter un département permanent, une campagne temporaire, un résultat de filtre ou une page d’atterrissage éditoriale. Ces sens ne doivent pas être fusionnés simplement parce qu’ils étaient tous présentés comme des liens dans l’ancien storefront.
| Structure source | Question de responsabilité dans la cible |
|---|---|
| Hiérarchie permanente de départements | Quelles Square Categories doivent conserver la classification durable des Products ? |
| Collection de campagne temporaire | La relation appartient-elle à une Category, une page Square Online, une présentation merchandising ou une règle de prix/remise ? |
| Regroupement par marque ou fabricant | Relève-t-il de la classification catalogue, d’un custom attribute, d’un contenu recherchable ou d’un système externe d’information Product ? |
| Filtre technique | La valeur sert-elle à la comparaison, la recherche, le reporting ou la sélection de Products, et quel objet Square ou système connecté en est responsable ? |
| Galerie Product et image de variation | Quelle image appartient à la famille de l’article et laquelle identifie une variation vendable précise ? |
| Libellé de menu et page d’atterrissage | L’élément pointe-t-il vers une Category, un article, une page Square Online, une URL externe ou une destination de campagne ? |
Cette séparation protège à la fois le commerce et le contenu. Une Category peut rester la référence pour la classification des Products tandis qu’une page Square Online contrôle la manière dont le groupe est présenté. Un lien de menu peut pointer vers la bonne destination sans devenir propriétaire de la relation catalogue. Les images peuvent rester attachées au bon article ou à la bonne variation même si la mise en page en ligne change.
Les points de vente et le stock forment une relation opérationnelle
Le stock Square n’est pas une quantité unique copiée sur un article. Il est relié à une variation d’article et au point de vente auquel l’état de stock s’applique. Square enregistre aussi le stock au moyen de comptages physiques et de transitions d’état : la quantité actuelle est donc le résultat d’un historique de stock, pas un champ Product isolé.
Une boutique, un entrepôt, une agence, un stock mutualisé ou un canal source ne correspond pas nécessairement à un point de vente Square à l’identique. La représentation cible doit identifier quelle quantité source appartient à quel point de vente et à quelle variation vendable. Regrouper plusieurs entrepôts source en un seul total n’est approprié que si la cible utilise volontairement un stock commun. Répartir une quantité source unique entre plusieurs points de vente exige une règle d’allocation faisant autorité, et non une estimation.
| Signal de stock | Relation cible |
|---|---|
| Stock au niveau Product sans variantes | La quantité appartient à la variation unique de l’article dans le point de vente Square prévu. |
| Stock au niveau variante | Chaque combinaison vendable source est mise en correspondance avec sa variation Square avant l’attribution du stock. |
| Quantité propre à un entrepôt | L’entrepôt ou l’agence source est réconcilié avec le point de vente Square responsable de cette quantité. |
| Stock réservé, endommagé, retourné ou en transit | Le sens de l’état est conservé uniquement si la cible ou le système de stock connecté reconnaît le même cycle de vie. |
| Système externe faisant autorité sur le stock | L’identifiant de variation et la clé de stock externe deviennent plus durables qu’une quantité importée une seule fois. |
| Ajustement historique de stock | L’enregistrement reste distinct du comptage physique actuel sauf s’il est requis par une intégration de stock ou un système d’audit. |
La limite du système faisant autorité est essentielle. Si Square devient responsable du stock après le lancement, les quantités cibles et relations de variations doivent être cohérentes dans Square. Si un ERP, un système d’entrepôt ou un hub marketplace reste la référence, Square a besoin d’identifiants stables de variation et de point de vente permettant à l’intégration de maintenir le stock. La quantité importée n’est alors qu’un état initial, pas la source de vérité permanente.
Customers, groupes, segments et relations d’identité
Les profils Customers Square peuvent contenir noms, informations d’entreprise, e-mails, numéros de téléphone, adresses, notes, identifiants de référence, appartenances à des groupes, relations de segments, préférences marketing et custom attributes. Les identifiants Customer relient également Customers aux Orders et à d’autres enregistrements Square. Ces possibilités ne rendent pas pour autant un profil Customer Square équivalent à tous les modèles de compte source.
Un compte source peut aussi contenir mots de passe, rôles d’acheteurs, hiérarchies d’entreprise, exemptions fiscales, soldes de fidélité, adhésions, abonnements, moyens de paiement enregistrés, accès portail ou préférences appartenant à une application. Certaines valeurs peuvent appartenir aux données Customer Square ; d’autres à un autre produit Square, une application connectée ou un système externe.
La mise en correspondance des identités doit éviter à la fois les fusions erronées et les doublons inutiles. E-mail, téléphone, identifiant Customer source, identifiant CRM externe, relation aux Orders et contexte d’entreprise peuvent tous contribuer à la décision. Une adresse e-mail familiale partagée ne signifie pas automatiquement que deux acheteurs sont une même personne. Un e-mail modifié ne signifie pas nécessairement que le Customer est nouveau. Les Orders invités doivent conserver le contexte de l’acheteur sans inventer une relation de compte permanent inexistante dans la source.
| Modèle d’identité source | Sens dans Square |
|---|---|
| Customer retail enregistré | Profil Customer relié aux coordonnées, adresses, groupes, segments, attributes et Orders pris en charge. |
| Acheteur invité | Contexte Customer au niveau de l’Order, avec profil permanent uniquement si les règles d’identité cibles le justifient. |
| Contact d’entreprise | Profil Customer avec données d’entreprise/référence ou responsable B2B/CRM connecté ; pas automatiquement une hiérarchie d’entreprise complète. |
| Membre d’un programme de fidélité | Identité Customer reliée à l’enregistrement de fidélité Square ou externe qui possède les soldes et l’activité. |
| Abonné marketing | Préférence Customer ou enregistrement du système marketing dont le sens du consentement reste distinct de l’historique d’achat. |
| Comptes source en double | Fusion uniquement si l’identité, le consentement, la propriété des Orders et les références externes justifient le rapprochement. |
L’objectif durable est une relation Customer que le personnel et les systèmes connectés peuvent comprendre. Une note générique importée ne suffit pas lorsqu’une même valeur devrait être recherchable comme identifiant de référence, structurée comme custom attribute ou possédée par un CRM.
Les Orders préservent les relations de transaction, pas la configuration future
Les Orders Square peuvent contenir lignes, références de variations, modifiers, quantités, taxes, remises, frais de service, pourboires, détails de traitement, point de vente, source de l’Order, liens Customer, totaux et contexte de paiement ou de remboursement. Ces relations rendent les Orders historiques utiles au service client, à la réconciliation et au reporting, mais elles ne configurent pas les transactions futures.
La ligne d’Order doit conserver le Product ou la variation acheté au moment de la transaction, même si le catalogue actuel change ensuite. Les sélections de modifiers et instructions de l’acheteur appartiennent à la ligne achetée. Taxes, remises, frais de service et pourboires expliquent la composition du total historique. Les données de traitement indiquent si l’Order a été retiré, expédié, livré, annulé ou autrement traité. La source et le point de vente indiquent l’origine opérationnelle de la transaction.
| Valeur historique | Sens dans un Order Square |
|---|---|
| Numéro d’Order source | Référence durable pour le support, la finance et le suivi inter-systèmes. |
| Ligne Product ou variation | Identité vendable achetée, quantité, prix et instantané descriptif. |
| Modifier ou personnalisation | Choix au moment de la vente attaché à la bonne ligne. |
| Taxe, remise, frais de service ou pourboire | Composante du total historique, pas une règle tarifaire active. |
| Référence de paiement ou de tender | Élément de la transaction réalisée ou tentée, pas une configuration de paiement réutilisable. |
| Traitement et suivi | Contexte historique de livraison ou retrait, pas la définition des méthodes de traitement actuelles. |
| Remboursement ou ajustement | Historique financier relié à l’Order et à la transaction d’origine. |
| Point de vente et source | Origine opérationnelle de l’Order et relation avec Square ou le canal externe. |
Les lignes historiques ad hoc exigent également de la prudence. Un Order source peut référencer un Product qui n’existe plus ou des frais générés par une application sans équivalent actuel dans le catalogue. L’Order peut conserver la description et le montant historiques, mais ne doit pas créer artificiellement un article catalogue courant sauf si le marchand compte réellement le vendre à nouveau.
Contenu Square Online, URL et responsabilité du site
Square Online ajoute une couche de site autour des données commerciales Square. Les articles du catalogue et Categories peuvent participer aux ventes en ligne, mais pages, navigation, domaines, chemins d’URL, redirections, champs SEO, contenus de politique, Blog Posts, placement des médias et présentation personnalisée ont leur propre sens au niveau du site.
Une URL Product source peut changer lorsque le Product devient une page d’article Square Online. Une page d’atterrissage Category peut nécessiter une destination Square Online plutôt qu’une simple Category du catalogue. Une CMS Page peut devenir une page du site, être fusionnée dans une autre page ou rester hors du site commercial. Blog Posts, collections éditoriales, ressources téléchargeables et pages de campagne doivent conserver leurs relations de contenu et leur destination prévue même si la conception visuelle est reconstruite.
| Élément web source | Responsable cible |
|---|---|
| Titre, description et médias Product | Article du catalogue et relation avec sa présentation en ligne. |
| URL Product ou Category | Route Square Online et relation de redirection source-destination nécessaire. |
| Page de politique ou d’information | Page Square Online ou autre destination de contenu définie. |
| Blog Post ou archive éditoriale | Destination de publication prise en charge ou système de contenu géré séparément. |
| Élément de menu | Relation de navigation du site vers un article, une Category, une page ou une URL externe. |
| Bloc de thème, script personnalisé ou widget d’application | Configuration de présentation ou d’intégration du site, pas contenu catalogue ordinaire. |
| Domaine et redirection | Configuration du site et des routes reliée à la destination de contenu conservée. |
Le modèle de contenu doit donc séparer les données commerciales faisant autorité des composants du site qui les rendent visibles. Un Product reste un article du catalogue même si plusieurs pages Square Online pointent vers lui. Une page reste du contenu même si elle référence des Products. Une redirection reste une relation de routage et ne remplace pas l’enregistrement de destination.
Custom attributes, applications et identifiants externes
Square prend en charge des custom attributes sur plusieurs types d’objets, tandis que de nombreux marchands utilisent aussi des applications de comptabilité, CRM, fidélité, livraison, restauration, retail, planification, reporting, marketplace et stock. La présence d’un champ personnalisé dans les deux systèmes ne prouve pas que ces champs possèdent la même responsabilité ou le même cycle de vie.
Les données personnalisées doivent être classées selon leur objet parent, leur finalité métier, le système faisant autorité et le consommateur qui continue de les utiliser. Une clé d’entrepôt au niveau de la variation appartient à la relation entre variation et entrepôt. Un identifiant CRM Customer appartient au Customer et à sa relation avec le CRM. Un identifiant marketplace Order appartient à l’Order et au canal. Un paramètre de script du site appartient à la configuration du site, pas à un enregistrement Customer ou Product.
| Signal personnalisé ou externe | Définition correcte de la responsabilité |
|---|---|
| Clé Product ERP | Article ou variation reconnu par l’ERP, selon la granularité Product propre à cet ERP. |
| SKU d’entrepôt | Variation portant le stock plus relation avec le point de vente ou l’entrepôt. |
| Identifiant CRM Customer | Profil Customer et CRM externe qui considère cet identifiant comme référence. |
| Identifiant de fiche marketplace | Relation article/variation/canal, pas simple note générique sur le Product. |
| Solde de fidélité ou identifiant d’adhésion | Customer plus système de fidélité responsable du registre et du statut. |
| Attribut Order personnalisé | Order ou ligne plus application qui a créé et consomme la valeur. |
| Données de widget Square Online | Configuration du site ou de l’application avec références vers les enregistrements commerciaux sous-jacents. |
| Table source non prise en charge | Entité parent, clé, cycle de vie et responsable cible explicites avant de conserver une valeur. |
Ce modèle évite deux échecs : forcer chaque valeur source dans le champ Square le plus proche et préserver des données personnalisées sans savoir à quoi elles appartiennent. Une valeur n’est utile que si les équipes savent quel enregistrement la possède, quel système la reconnaît et si elle décrit une entité actuelle, une transaction historique ou un fonctionnement de présentation.
Représenter les modèles source courants comme des relations
Le modèle cible Square final doit s’exprimer sous forme de relations plutôt que comme une liste de champs. Des cas représentatifs rendent ces relations visibles avant de définir une correspondance à grande échelle.
| Modèle source | Relation cible dans Square |
|---|---|
| Product d’habillement configurable | Article → item options → valeurs d’options → variations → images/SKU des variations → stock par point de vente. |
| Article de restaurant avec suppléments | Article/variation → modifier list → modifiers → sélections de lignes Order → contexte de traitement. |
| Catalogue multi-entrepôts | Variation → point de vente Square ou entrepôt externe → état de stock → clé de stock externe. |
| Customer retail avec fidélité | Customer → coordonnées/références → Orders → enregistrement de fidélité possédé par Square ou un système connecté. |
| Order marketplace | Order → référence source/canal → variation de ligne ou instantané ad hoc → historique paiement/traitement → identifiant marketplace externe. |
| Page Category sensible au SEO | Category du catalogue → destination Square Online → lien de navigation → redirection depuis l’URL source → articles référencés. |
| Configurateur Product personnalisé | Article/variation → configuration possédée par une application → résultat sur la ligne Order → identifiants externes de traitement. |
Ces chaînes rendent le périmètre explicite en identifiant le responsable cible, les enregistrements dépendants et le fonctionnement externe qui continue hors du catalogue principal. Elles montrent aussi quand un seul enregistrement source doit devenir plusieurs objets Square reliés. Une chaîne n’est complète que lorsque le personnel et les systèmes connectés peuvent suivre l’article, le Customer, l’Order, le contenu ou l’identifiant externe dans la cible sans devoir utiliser la plateforme source pour l’interpréter.
Conclusion
La représentation du modèle de données dans Square dépend de l’attribution de chaque valeur source à l’objet Square qui possède son sens commercial. Articles, variations, options, modifiers, Categories, points de vente, stock, Customers, Orders, contenu Square Online, custom attributes et identifiants externes sont reliés mais non interchangeables.
Un bon modèle cible conserve les relations parent-enfant et inter-systèmes qui donnent sens aux données. L’identité d’une variation reste reliée au stock et aux points de vente, l’identité Customer aux Orders et références externes, les transactions historiques restent séparées de la configuration future et la présentation Square Online reste distincte des enregistrements catalogue faisant autorité. C’est cette structure qui rend les données migrées compréhensibles et exploitables au lieu de simplement présentes.
Questions fréquentes
Quelle différence existe entre une item variation Square et un modifier ?
Une item variation est une version achetable d’un article et peut porter SKU, prix, image, unité de mesure et information de stock. Un modifier correspond généralement à un ajout, retrait ou préférence sélectionné au moment de la vente. Le bon choix dépend de la question suivante : ce choix crée-t-il une identité vendable distincte dont le stock doit être suivi ?
Toutes les options Product source doivent-elles devenir des item options Square ?
Non. Les item options conviennent lorsque leurs valeurs définissent des choix standardisés de variations. La personnalisation, les suppléments facultatifs, les instructions d’acheteur ou les choix pilotés par une application peuvent plutôt appartenir à des modifiers, des données de ligne Order, des custom attributes ou un autre système responsable.
Pourquoi le point de vente Square est-il important pour la migration du stock ?
Le stock Square a un sens pour une variation précise dans un point de vente précis. Une quantité sans la bonne relation variation-point de vente peut être numériquement correcte tout en attribuant le stock au mauvais contexte opérationnel.
Les profils Customers Square peuvent-ils reproduire toutes les fonctions d’un compte source ?
Non. Les profils peuvent conserver identité, coordonnées, groupes, segments, préférences, custom attributes et relations Orders pris en charge. Les mots de passe, hiérarchies B2B, adhésions, registres de fidélité, abonnements et permissions appartenant à des applications peuvent avoir d’autres responsables cibles.
Les Orders Square migrés configurent-ils les paiements et le traitement des commandes ?
Non. Les Orders conservent les lignes, ajustements, point de vente, source, contexte de paiement, historique de traitement et autres éléments de transaction. Le fonctionnement actuel du paiement, de la fiscalité, du traitement, des notifications et des applications reste une configuration séparée.
Comment représenter les champs personnalisés et identifiants externes dans Square ?
Attachez chaque valeur à l’article, la variation, le Customer, l’Order, la ligne, le site, l’application ou le système externe qui en est réellement responsable. La valeur doit également conserver la clé utilisée par le système consommateur ; placer toutes les données personnalisées dans une note générique détruit le sens de la relation.