Migrer vers ShopWired ne consiste pas seulement à déplacer Products, Customers, Orders, Categories, Reviews, Coupons et enregistrements CMS vers une nouvelle administration. ShopWired possède une structure e-commerce propre autour des Products, Categories, marques, variations, choix, extras, stocks, de l’identité Customer, des fonctions B2B, de la configuration du parcours de commande, des paramètres TVA et taxe sur les ventes, des règles de livraison, des applications, du fonctionnement des API et de la présentation de la boutique pilotée par le thème. Un bon plan de migration doit traduire les données source dans cette structure sans perdre le sens métier porté par les enregistrements.
La question centrale est simple : lorsqu’un enregistrement source arrive dans ShopWired, le marchand comprend-il encore ce qu’il représente et la boutique l’utilise-t-elle correctement ? Une option Product auparavant décrite par un simple libellé peut devoir devenir une variation ShopWired, un choix, un extra, un bundle, un champ de personnalisation ou un fonctionnement pris en charge par une application. Un segment Customer peut devenir un enregistrement Customer, un abonné à la newsletter, un Customer B2B, un groupe tarifaire ou un champ personnalisé. Un Order historique peut rester lisible pour le service Customer sans pour autant configurer automatiquement le parcours de commande, la livraison, le paiement, la TVA, la taxe sur les ventes ou les règles B2B des futures transactions.
Le sens des données ShopWired devient plus clair lorsque le transfert des enregistrements est séparé de la reconstruction opérationnelle. Chaque valeur doit être interprétée selon la fonction commerciale ou opérationnelle qu’elle doit continuer à remplir : permettre la navigation dans le catalogue, contrôler les combinaisons achetables, préserver l’historique Customer, soutenir les comptes B2B, expliquer les Orders historiques, maintenir la visibilité dans les recherches, relier les systèmes externes ou soutenir le merchandising courant.
Priorités de traduction du modèle de données ShopWired
La planification du modèle de données ShopWired doit commencer par les domaines qui peuvent modifier le plus directement le sens métier : configuration Product, identité Customer, fonctionnement B2B, interprétation des Orders, découverte dans la boutique et dépendances aux systèmes externes. Ces domaines déterminent si la boutique migrée est seulement remplie de données ou réellement exploitable.
| Domaine de la boutique source | Interprétation dans ShopWired | Question de planification de la migration |
|---|---|---|
| Variantes et options Product | Variations, choix, extras, bundles, saisies texte/fichier ou fonctionnement d’application | L’option source influence-t-elle le SKU, le prix, le stock, la livraison, la taxe ou seulement la présentation ? |
| Structure des Categories et des marques | Découverte Product, navigation, filtrage, SEO et logique de merchandising | Les Customers peuvent-ils encore trouver les Products prioritaires par les parcours attendus ? |
| Enregistrements Customer | Identité Customer liée à l’e-mail, état du compte, historique des Orders, notes, champs personnalisés et séparation B2B | Les enregistrements dupliqués, invités, B2B et enregistrés conservent-ils le bon sens ? |
| Groupes Customer et comptes B2B | Visibilité B2B, tarification, fonctionnement du compte et règles opérationnelles | Quelles règles sont des données, lesquelles relèvent de la configuration ShopWired et lesquelles nécessitent un examen personnalisé ? |
| Orders historiques | Historique Customer, libellés de paiement et livraison, valeurs fiscales, notes d’Order, contexte de traitement des commandes et références externes | Les Orders historiques restent-ils utiles pour le service Customer et les rapports après migration ? |
| Contenu et éléments SEO | Pages, landing pages, Blog Posts, menus, redirections, métadonnées et affichage contrôlé par le thème | Quels contenus influencent la recherche, la confiance, la conversion ou l’intégration des Customers B2B ? |
| Applications et intégrations | Propriété externe des données, fonctionnement API/webhook, flux de stock, comptabilité, traitement des commandes, e-mail, marketplace ou CRM | Quels systèmes connectés doivent être reconfigurés, mis en correspondance, reconstruits ou exclus ? |
Cette approche évite une erreur fréquente : supposer que des noms de champs similaires suffisent. Une similarité lexicale ne garantit pas une similarité opérationnelle. Dans ShopWired, le sens dépend de la manière dont l’enregistrement intervient dans la sélection Product, la reconnaissance Customer, la vente B2B, le parcours de commande, le traitement des commandes, le calcul fiscal et la présentation de la boutique. Une carte de responsabilité utile relie donc chaque valeur à son Product parent, sa variation, son Customer, son compte B2B, son Quote, son Order, son contenu, son application ou son système externe avant de définir la mise en correspondance au niveau champ.
Products, Categories, marques et données de découverte
Les Products ShopWired sont reliés aux Categories, marques, variations, choix, extras, stocks, prix, images, mots-clés de recherche, filtres, URL et relations de merchandising. Un catalogue source peut stocker ces éléments dans des Products, collections, tags, attributs, fabricants, blocs de page builder ou enregistrements d’application. La destination doit attribuer chaque signification à la structure ShopWired qui en est réellement responsable.
Les Categories fournissent une organisation Product hiérarchique, tandis que les marques représentent l’identité d’un fabricant ou d’une marque. Les filtres Product peuvent exposer des valeurs structurées de comparaison. Les mots-clés de recherche Product influencent la découverte sans devenir des Categories visibles. Un thème peut afficher ces enregistrements, mais la présentation n’en devient pas pour autant le propriétaire du catalogue.
| Concept du catalogue source | Propriétaire dans ShopWired | Conséquence de traduction |
|---|---|---|
| Département ou hiérarchie durable | Category et structure parent-enfant | Préserver l’appartenance des Products et le sens durable de la navigation. |
| Fabricant ou marque | Relation de marque | Garder l’identité de marque distincte d’une Category générique ou d’une spécification. |
| Attribut technique utilisé pour affiner | Filtre Product ou champ structuré | Conserver la valeur de comparaison sans créer de variantes artificielles. |
| Synonyme interne de recherche | Mot-clé de recherche Product | Améliorer la découverte sans afficher le terme comme contenu du catalogue. |
| Collection de campagne | Category, landing page, offre ou relation de présentation éditoriale | Suivre l’objectif commercial plutôt que le libellé source. |
| Image principale et galerie | Relation média Product/variation | Préserver le rôle de l’image et les médias propres à la variation lorsque la combinaison vendable change. |
L’identité Product reste utile commercialement seulement si les équipes peuvent déterminer ce qui est vendu, où cela apparaît, quelle marque ou Category en est responsable, comment cela est trouvé et quel enregistrement de stock et de prix contrôle l’article achetable.
Variations, choix, extras et sens de la configuration Product
ShopWired distingue variations, choix, extras, texte personnalisé, envoi de fichiers, bundles, précommandes, abonnements et autres fonctionnements Product. Les plateformes source appellent souvent l’ensemble de ces éléments « options », alors que leurs relations sont différentes.
Une variation représente une combinaison vendable et peut porter un SKU, un prix, du stock, une image, un poids, un GTIN, un MPN et un traitement lié à la TVA. Un choix ou un extra peut ajouter une sélection ou un coût facultatif sans créer la même identité d’inventaire. Les saisies texte et fichier préservent les informations fournies par le Customer. Un bundle relie une offre à d’autres Products. Les précommandes et abonnements ajoutent des relations temporelles et transactionnelles au-delà du catalogue statique.
| Fonctionnement source | Propriétaire dans ShopWired | Sens à préserver |
|---|---|---|
| Combinaison taille/couleur avec son propre SKU ou stock | Variation | Identité vendable, prix, inventaire, image, poids et identifiants externes au niveau de la combinaison |
| Mise à niveau facultative ou emballage cadeau | Choix ou extra | Sélection facultative et effet sur le prix sans faux inventaire de variante |
| Texte de gravure | Saisie texte personnalisée Product et instantané sur la ligne d’Order | Valeur saisie par le Customer liée à la ligne achetée |
| Illustration ou document fourni par le Customer | Relation d’envoi de fichier et instantané sur la ligne d’Order | Propriété du fichier Customer, sécurité et visibilité pour le traitement des commandes |
| Kit ou multipack | Bundle ou relation Product-à-Product | Identité des composants, quantité, autorité de stock et sens dans l’Order historique |
| Product en précommande ou abonnement | Product plus relation temporelle/Order | Contexte de sortie, facturation, renouvellement ou compte qui ne tient pas dans les seuls champs Product |
| Configurateur conditionnel | Logique appartenant à une application | Les sélections source et les données d’Order résultantes doivent être séparées de l’application qui les a générées |
Cette distinction évite deux erreurs opposées : créer des variantes pour des données descriptives ou facultatives, et aplatir des combinaisons ayant leur propre stock en texte statique. Les identifiants externes doivent rester rattachés au niveau Product ou variation reconnu par les systèmes d’entrepôt, de comptabilité, de flux et de marketplace.
Données Customer, compte et marketing
ShopWired sépare les profils Customer, abonnés newsletter, Customers B2B, points de récompense, relations de parrainage, sources Customer et données Customer créées par des applications. L’e-mail constitue une clé d’identité importante, mais les e-mails dupliqués, Orders invités, comptes historiques et relations B2B peuvent rendre dangereuse une correspondance un-à-un.
Un enregistrement Customer peut posséder coordonnées, adresses, état du compte, historique d’Orders, notes et champs personnalisés. Le statut newsletter représente une relation de communication et non une identité Customer de substitution. Le statut B2B ajoute un sens en matière de tarification et d’accès. Les points de récompense forment un registre lié au Customer. Les tags d’application ou identifiants CRM peuvent rester sous la responsabilité de systèmes externes.
| Modèle d’identité source | Décision de relation ShopWired |
|---|---|
| Acheteur retail enregistré | Profil Customer lié aux adresses et aux Orders historiques |
| Acheteur invité | Identité et adresses au niveau de l’Order sans inventer un compte permanent |
| Contact uniquement abonné à la newsletter | Relation d’abonnement séparée du compte acheteur sauf si les enregistrements représentent réellement la même personne |
| Acheteur B2B approuvé | Customer B2B plus relations de tarification, visibilité, fiscalité et compte qui donnent son sens à l’approbation |
| Comptes source dupliqués | Consolider uniquement lorsque l’identité, le consentement, les adresses et la propriété des Orders étayent la décision |
| Solde de récompense ou de parrainage | Enregistrement de programme lié au Customer plutôt qu’une note Customer générique |
| Identifiant CRM ou marketing | Identifiant externe rattaché à l’enregistrement Customer ou abonné reconnu par le système connecté |
Le modèle cible ne doit pas déduire le consentement, l’approbation B2B ou la propriété du compte à partir d’un simple nom partagé. Il doit préserver la relation qui rendait l’enregistrement source utile dans les opérations.
Données B2B, Quotes et tarification
Les structures B2B ShopWired comprennent Customers B2B, Categories et Products réservés au B2B, tarification B2B, bandes tarifaires, prix individuels, remises globales, Quotes et comportements de compte associés. Il s’agit d’enregistrements reliés et non de simples attributs sur une ligne Customer.
L’identité de l’acheteur appartient au Customer ou Customer B2B. La règle commerciale peut appartenir à une bande tarifaire, un prix B2B propre à un Product, une exception individuelle, une remise globale, une relation de visibilité ou un Quote. Les Quotes et Orders historiques préservent les résultats négociés ; la configuration B2B actuelle définit le fonctionnement des achats futurs.
| Élément B2B source | Propriétaire dans ShopWired | Sens de la relation |
|---|---|---|
| Compte professionnel approuvé | Customer B2B | Identité de l’acheteur et statut B2B approuvé |
| Niveau de gros | Bande tarifaire B2B ou remise globale | Traitement commercial partagé par une catégorie de Customers B2B |
| Prix contractuel | Prix individuel du Customer B2B ou autre relation Product-Customer | Exception propre au compte au bon niveau Product ou variation |
| Assortiment réservé au B2B | Relation de visibilité Product/Category | Détermine quels acheteurs approuvés peuvent découvrir et acheter l’article |
| Quote | Enregistrement Quote lié au Customer, aux Products, prix, notes, statut et éventuellement à l’Order ultérieur | Instantané commercial négocié plutôt qu’un panier ordinaire |
| Conditions de bon de commande | Contexte Customer/Quote/Order plus configuration de paiement cible | Conditions historiques et valeurs de référence séparées du fonctionnement actif du parcours de commande |
| Statut TVA | Customer B2B et relation fiscale | Les éléments justificatifs de l’acheteur et son traitement commercial ne doivent pas être réduits à un libellé |
Un Customer Group source est donc insuffisant à lui seul. Son sens dans le modèle de données correspond au réseau de prix, Products, règles de visibilité, historique de Quotes, conditions et traitement fiscal qui y sont reliés.
Orders, statuts, Quotes et contexte transactionnel
Un Order ShopWired enregistre ce qui s’est produit au cours d’une transaction. Ses relations peuvent inclure l’identité d’un Customer ou acheteur invité, les lignes Product et variation, choix, extras, données de personnalisation, prix, vouchers, livraison, libellés de paiement, TVA ou taxe sur les ventes, statuts, notes, remboursements, retours, abonnements, Quotes et références de systèmes externes.
Les valeurs des Orders historiques sont des instantanés. Elles ne doivent pas être recalculées selon les prix Product ou paramètres fiscaux actuels. Un libellé de paiement ou de livraison explique l’Order passé mais ne configure pas la passerelle ou la zone de livraison cible. Un champ personnalisé d’Order appartient à la transaction, sauf si la même valeur est volontairement promue en donnée Customer ou Product durable.
| Relation d’Order | Sens historique à préserver |
|---|---|
| Affectation Customer ou invité | Qui a passé l’Order et quelles adresses ont été utilisées |
| Ligne Product/variation | Identité achetée, SKU, choix ou extras sélectionnés, quantité et description de ligne |
| Texte/fichier fourni par le Customer | Instruction de traitement des commandes rattachée à la ligne achetée ou à l’Order |
| Prix, remise, voucher, TVA/taxe et total | Instantané financier enregistré au moment de l’achat |
| Libellé de paiement et livraison | Contexte de méthode utile au service et au rapprochement sans impliquer une configuration active |
| Statut, remboursement, retour et chronologie | Éléments du cycle de vie et modifications de la transaction d’origine |
| Référence Quote ou abonnement | Relation avec le processus commercial précédant ou suivant l’Order |
| Identifiant externe | Clé de rapprochement pour ERP, comptabilité, traitement des commandes, marketplace ou CRM |
Les Orders restent utiles lorsque les équipes peuvent interpréter la transaction même si le catalogue, le thème, les applications ou la configuration du parcours de commande ont évolué.
Données de parcours de commande, livraison, paiement, TVA et taxe sur les ventes
ShopWired sépare les données transactionnelles historiques de la configuration qui crée les futurs Orders. Les anciens Orders peuvent contenir noms de modes de livraison, frais, libellés de paiement, valeurs de TVA ou taxe sur les ventes, exonérations et réponses personnalisées du parcours de commande. Le parcours de commande actuel de ShopWired, ses zones et tarifs de livraison, modes de retrait, passerelles de paiement, zones de TVA, taux fiscaux personnalisés, règles B2B et applications du parcours de commande constituent des enregistrements de configuration séparés.
| Valeur source historique | Propriétaire des données | Relation cible séparée |
|---|---|---|
| Libellé du mode de paiement et référence de transaction | Order | Passerelle de paiement et configuration des identifiants pour les futures transactions |
| Mode de livraison et frais | Order | Zone, tarif, restriction, retrait et configuration transporteur |
| Montant TVA ou taxe sur les ventes | Instantané financier de l’Order | Zones TVA, taux fiscaux, exonérations et paramètres de calcul actuels |
| Justificatif d’exonération Customer | Customer/Customer B2B ou enregistrement externe de conformité | Règle cible appliquant ce traitement aux futurs Orders |
| Réponse à une question du parcours de commande | Champ Order ou Customer selon sa finalité | Définition du champ du parcours de commande et règle de visibilité |
| Conditions hors ligne ou référence de bon de commande | Customer B2B, Quote ou Order | Configuration actuelle des conditions de paiement et d’approbation |
| Sortie d’une application du parcours de commande | Donnée d’Order appartenant à l’application | Configuration de l’application cible et relation de données prise en charge |
Cette séparation maintient les données historiques et la configuration future dans leur rôle correct : les enregistrements migrés expliquent les transactions passées, tandis que la configuration décrit comment ShopWired créera les nouvelles. Elles sont reliées, mais aucune ne remplace l’autre. La même distinction s’applique aux exonérations Customer et conditions B2B : l’Order historique préserve ce qui s’est produit, tandis que la relation Customer ou B2B explique pourquoi un traitement similaire peut s’appliquer à l’avenir.
Contenu, SEO, menus et données dépendant du thème
Le contenu ShopWired peut comprendre pages de site, landing pages, Blog Posts, métadonnées Product et Category, redirections 301, menus et listes de liens, informations d’entreprise, images, fichiers, Products mis en avant, questions-réponses Product et autres enregistrements de boutique. Les thèmes affichent ces enregistrements mais n’en deviennent pas le propriétaire de référence.
Un bloc de page builder source peut combiner texte, images, références Product, formulaires et widgets d’application dans un même objet visuel. Le modèle cible doit séparer le contenu durable de la configuration de présentation et des références e-commerce dynamiques.
| Ressource source | Propriétaire dans ShopWired | Conséquence de traduction |
|---|---|---|
| Page de politique, service ou information B2B | Page de site | Préserver le corps, les métadonnées, liens, médias et le sens durable de l’URL. |
| Landing page de campagne ou éditoriale | Landing page plus références Product/contenu | Séparer le contenu réutilisable de la mise en page propre au thème. |
| Article de blog | Blog Post | Conserver titre, corps, médias, date/auteur lorsque pertinent, métadonnées et liens internes. |
| Données SEO Product ou Category | Product/Category plus champs SEO | Garder l’identité canonique de l’entité distincte des redirections et du placement dans les menus. |
| Élément de menu | Relation menu/liste de liens | La navigation publique peut pointer vers un Product, une Category, une page, un Blog Post, une URL externe ou une campagne. |
| Redirection | Relation de redirection 301 | Préserver le sens source-vers-destination de la route sans traiter l’ancienne URL comme du contenu de page. |
| Section de thème ou widget | Présentation thème/application | Recréer la présentation séparément du contenu ou des données Product qu’elle affiche. |
La propriété du contenu compte à la fois pour les expériences retail et B2B. Une page d’intégration B2B, une bibliothèque de spécifications Product, une page de politique ou une landing page de forte valeur peut porter un sens métier même si son design visuel est remplacé.
Applications, API, webhooks et données des systèmes externes
ShopWired expose des applications, identifiants API et webhooks, et son écosystème comprend des connexions à la comptabilité, au traitement des commandes, au stock, aux marketplaces, au marketing, à la fiscalité, à la recherche, aux abonnements et au B2B. Les données d’une application source ne deviennent pas des données ShopWired natives simplement parce qu’une application cible remplit une fonction similaire.
Le modèle cible doit identifier le système faisant autorité pour chaque valeur opérationnelle. Les identifiants Product et variation peuvent être reconnus par un ERP. Les identifiants Customer peuvent appartenir à un CRM. Les références Order et expédition peuvent appartenir au traitement des commandes ou à la comptabilité. Le consentement des abonnés peut appartenir à une plateforme marketing. Un webhook est de la configuration ; l’identifiant externe transporté dans sa charge utile est une donnée.
| Dépendance | Relation faisant autorité |
|---|---|
| Identifiant Product ERP ou comptable | Product ou variation reconnu par le système externe |
| Clé de flux de stock | Product/variation portant le stock plus système responsable du stock disponible |
| Référence de traitement des commandes | Relation Order, expédition ou colis reconnue par le transporteur ou l’entrepôt |
| Identifiant Customer/entreprise CRM | Relation Customer ou Customer B2B au bon niveau de compte |
| Identifiant d’annonce marketplace | Relation Product/variation/canal, et non description Product générique |
| Consentement marketing et tags | Abonné/Customer plus système marketing externe responsable de cet état |
| Champ personnalisé d’application | Valeur appartenant à l’application avec parent Product, Customer, Order ou Quote explicite |
| Identifiant API ou abonnement webhook | Configuration cible sécurisée et non donnée de publication ou Customer |
Pagination API, authentification et gestion des erreurs affectent la manière dont les systèmes échangent les enregistrements, mais pas la propriété des données sous-jacentes. La carte de responsabilité doit donc rester stable même lorsque l’implémentation de l’intégration est reconstruite.
Limites de propriété des données personnalisées et externes
Les données personnalisées et externes dans ShopWired doivent être organisées selon leurs limites de responsabilité plutôt que par des libellés génériques d’escalade. La décision centrale est de savoir si la valeur appartient à une entité native ShopWired, une application ShopWired, une configuration de présentation ou un système externe.
| Signal de données | Propriétaire cible | Définition de relation requise |
|---|---|---|
| Spécification Product utilisée pour filtrer | Structure Product/filtre | Nom d’attribut, valeur, appartenance Product et rôle d’affichage dans la boutique |
| Identifiant d’entrepôt au niveau variation | Variation plus ERP/entrepôt | Combinaison vendable et enregistrement externe qui la reconnaît |
| Référence de contrat Customer B2B | Customer B2B plus CRM/comptabilité | Organisation, contact, compte commercial et clé du système externe |
| Champ personnalisé utilisé uniquement dans un Quote | Quote | Contexte de négociation ou d’approbation sans en faire un attribut Customer permanent |
| Enregistrement d’abonnement ou bundle créé par une application | Application plus Product/Order | Product parent, relations de facturation ou composants et références transactionnelles historiques |
| Paramètre de thème sélectionnant des Products | Présentation du thème | Les références Product restent autoritatives dans le catalogue ; le paramètre contrôle seulement l’affichage |
| Table source personnalisée non prise en charge | Entité parent définie ou système externe | Objectif métier, clé parent, cycle de vie et propriétaire cible doivent être explicites |
Ce modèle évite deux échecs : forcer chaque valeur source dans le champ natif le plus proche et conserver des données personnalisées sans comprendre leur relation parent. Une valeur n’est utilisable que lorsque les équipes savent quel enregistrement en est responsable, quel système la reconnaît et si elle décrit l’historique, le commerce actuel ou la présentation. La propriété doit aussi rester stable dans les exports et intégrations. Lorsqu’une valeur personnalisée est dupliquée dans plusieurs systèmes, une source de référence et une clé de rapprochement durable doivent être définies pour éviter que les mises à jour ultérieures créent des versions contradictoires d’un même fait commercial.
Conclusion
La planification du modèle de données ShopWired doit se concentrer sur le sens et non sur la simple correspondance des champs. Les différences les plus importantes concernent généralement la configuration Product, le fonctionnement B2B, l’identité Customer, l’historique des Orders, le contexte du parcours de commande, les contenus et éléments SEO, les applications, processus API, identifiants externes et champs personnalisés. Chaque domaine doit être interprété selon son usage métier futur, et pas seulement selon la possibilité d’importer un enregistrement.
Un bon modèle cible ShopWired attribue chaque valeur source à un Product, une variation, un Customer, une relation B2B, un Quote, un Order, un contenu, une application, une couche de présentation ou un système externe. Cette carte de responsabilité préserve le sens commercial sans confondre données historiques et configuration future.
Questions fréquentes
Pourquoi les options Product ShopWired nécessitent-elles un examen particulier pendant la migration ?
Parce que les options Product source peuvent représenter des fonctionnements différents dans ShopWired. Certaines deviennent des variations avec un sens pour SKU, prix, stock, image, poids ou TVA. D’autres relèvent de choix, extras, champs de personnalisation, bundles ou structures appartenant à des applications.
Les enregistrements Customer sont-ils mis en correspondance uniquement par nom dans ShopWired ?
Non. L’identité Customer est fortement liée à l’adresse e-mail. Les e-mails dupliqués, Orders invités, comptes enregistrés, comptes B2B et champs personnalisés Customer doivent être examinés attentivement afin que l’historique des Orders et le sens du compte restent exploitables.
Les Orders migrés configurent-ils le parcours de commande dans ShopWired ?
Non. Les Orders migrés peuvent préserver le contexte historique de paiement, livraison, remises, fiscalité et traitement des commandes lorsque cela est pris en charge. Le parcours de commande actif dépend toujours de la configuration ShopWired des paiements, de la livraison, de la TVA ou taxe sur les ventes, des groupes Customer, du B2B et des applications.
La tarification B2B et les règles commerciales peuvent-elles être migrées comme des données Customer ordinaires ?
Pas toujours. Comptes B2B, bandes tarifaires, prix individuels, relations Quote, visibilité Product, conditions de compte et traitement fiscal sont des enregistrements commerciaux reliés, et non de simples champs d’un profil Customer.
Quand les données personnalisées ShopWired nécessitent-elles un propriétaire distinct ?
Un propriétaire distinct est nécessaire lorsqu’une valeur appartient à une application, un système externe, une table source personnalisée, une couche de présentation ou une relation qui ne tient pas naturellement dans un Product, Customer, Quote, Order ou contenu ordinaire.
Comment traduire les règles B2B dans ShopWired ?
Séparez l’identité sous-jacente de l’acheteur et les données Product de la règle qui modifie le prix, la visibilité, le traitement fiscal, le Quote ou le parcours de commande. Préservez les enregistrements portant le sens durable, puis documentez la configuration cible ou le système connecté qui appliquera la règle commerciale.