Storeden est désormais présenté par TeamSystem sous le nom TeamSystem Commerce, tandis que les comptes existants et la documentation métier interne peuvent encore utiliser le nom Storeden. Si Storeden est retenu comme plateforme cible, la préparation doit consigner les deux appellations là où elles apparaissent afin que l’équipe ne traite pas le compte actuel, les exports historiques, les références marketplace ou la documentation d’intégration comme des systèmes sans rapport.
La documentation opérationnelle détaillée actuelle n’est pas systématiquement disponible dans un centre d’aide public. Le dossier de préparation doit donc s’appuyer sur des éléments provenant du compte source réel : exports, captures d’écran, enregistrements administrateur, notes d’intégration et responsables nommés. Évitez de déduire un fonctionnement précis des champs, des limites ou une couverture d’export à partir d’anciens articles ou de descriptions marketing.
Confirmer le compte, la dénomination actuelle et le périmètre de vente
Commencez par identifier le compte Storeden ou TeamSystem Commerce exact, les domaines principaux, langues et devises actives, le plan actuel ou les modules activés lorsque pertinent, la responsabilité du thème, les canaux de vente et les connexions à TeamSystem ou à des systèmes externes. Consignez quel nom apparaît dans l’administration, les factures, API ou enregistrements d’intégration et procédures internes.
| Action | Responsable | Élément | Condition de préparation |
|---|---|---|---|
| Confirmer le compte source | Administrateur Store | Identifiant du compte, capture administrateur, domaine principal | La boutique source exacte est sans ambiguïté. |
| Consigner les noms Storeden et TeamSystem Commerce | Responsable projet | Tableau de correspondance des noms pour compte, exports, intégrations et documentation | Les références historiques et actuelles peuvent être rapprochées. |
| Lister les canaux de vente actifs | Responsable e-commerce | Inventaire website, marketplace, social, B2B ou autres canaux | Les enregistrements propres aux canaux ont des responsables nommés. |
| Identifier les connexions à l’écosystème TeamSystem | Responsable systèmes | Notes ERP, comptabilité, paiements, POS, logistique ou autres intégrations | Les dépendances natives de l’écosystème sont visibles. |
| Confirmer l’accès aux éléments source | Responsable données/technique | Exports disponibles, rapports, identifiants, contact support | Les enregistrements nécessaires peuvent être collectés depuis le compte réel. |
| Démarrer un journal de changements | Responsable projet | Modifications datées du catalogue, stock, Customers, Orders, applications et URLs | Le dossier restera à jour. |
Préparer Products, variantes, champs de catalogue et médias
TeamSystem Commerce est décrit dans la source comme proposant une gestion centralisée du catalogue et du stock, des images et descriptions Product, des prix et une distribution multicanale. Le compte source doit être inspecté pour déterminer les champs Product et relations de variantes effectivement utilisés. Préparez les Products par schéma métier plutôt qu’en supposant un modèle unique.
Consignez identifiant Product, SKU ou code interne, titre, statut, prix, contexte fiscal, stock, structure de variante ou d’option, Categories, marque ou fabricant, images, descriptions, contenu linguistique, données de livraison, champs marketplace, identifiants externes et champs personnalisés visibles dans le compte ou les exports.
| Schéma Product | Action de préparation | Élément | Condition de préparation |
|---|---|---|---|
| Product simple | Capturer identifiants, prix, stock, statut, Category, médias et contenu | Export Product et exemple de page | Le sens Product de base est documenté. |
| Product à variantes | Consigner noms d’option, valeurs, identifiants de combinaison, prix, stock, image et statut | Export de variantes ou captures administrateur | Les combinaisons vendables sont distinguables du Product parent. |
| Product propre à un canal | Consigner IDs marketplace/canal, titres, Categories, prix et règles de disponibilité | Exemple de listing de canal | Données website et canal ne sont pas confondues. |
| Product multilingue | Consigner responsabilité des langues, champs traduits, différences de route et fallback | Ensemble d’exemples linguistiques | Le périmètre de contenu est explicite par langue. |
| Product personnalisé ou enrichi par application | Identifier les champs créés par plugins, applications ou intégrations | Dictionnaire de champs et responsable source | Les données Product non principales ont un traitement défini. |
| Product riche en médias | Consigner images originales, documents, vidéos et emplacements de fichiers | Manifeste média | Les actifs d’origine peuvent être rapprochés de leurs enregistrements. |
Ne déduisez pas le fonctionnement des variantes ou marketplaces à partir des noms Product. Utilisez les éléments du compte réel pour montrer quelles valeurs modifient stock, prix, images ou disponibilité par canal.
Préparer Categories, navigation, langues et découverte
Préparez la hiérarchie Category, les affectations Product, menus de navigation, parcours de marque ou collection, versions linguistiques, filtres ou attributs utilisés pour la découverte, landing pages et URLs prioritaires. La classification multicanale du catalogue doit être documentée séparément de la navigation website, car une Category marketplace ou un libellé de flux peut ne pas représenter la structure Category de la boutique cible.
| Domaine de découverte | Responsable | Élément | Condition de préparation |
|---|---|---|---|
| Hiérarchie Category | Responsable catalogue | Liste parent-enfant, statut, affectations Product | Chaque Category conservée possède une finalité connue. |
| Menus et parcours boutique en ligne | Responsable boutique en ligne | Carte de navigation et captures | Les parcours de présentation sont séparés des enregistrements Category. |
| Périmètre linguistique | Responsable contenu | Langues actives et exemples Product, Category et pages traduits | Le contenu localisé nécessaire est identifié. |
| Filtres et attributs | Responsable merchandising | Noms des champs, valeurs, couverture Product | Les données de découverte sont assez cohérentes pour être mises en correspondance. |
| Classification par canal | Responsable marketplace | Exemples de Category, flux et listings par canal | La classification externe reste distincte de la taxonomie website. |
| Routes prioritaires | Responsable SEO | URLs Product, Category, page, marque et campagne | Les parcours importants ont une décision documentée. |
Clarifier l’autorité du stock et la synchronisation par canal
Les valeurs de stock peuvent être maintenues directement dans le compte e-commerce ou synchronisées depuis une application TeamSystem, un ERP, un entrepôt, un POS, un flux fournisseur ou un processus marketplace. La préparation doit identifier la source autoritaire et la fréquence des mises à jour. Une quantité dans un export n’est qu’un instantané tant que le propriétaire du stock n’est pas connu.
| Question sur le stock | Élément | Condition de préparation |
|---|---|---|
| Où le stock autoritaire est-il maintenu ? | Liste des systèmes, responsable, captures, note d’intégration | Une source de vérité est nommée pour chaque groupe Product. |
| Le stock est-il suivi par Product ou variante ? | Enregistrements Product/variante représentatifs | La granularité est documentée. |
| Plusieurs emplacements ou entrepôts sont-ils impliqués ? | Liste des emplacements et exemples d’allocation | Le sens des emplacements est explicite. |
| Les marketplaces réservent-elles ou synchronisent-elles le stock ? | Règles de canal et exemples de listings | La disponibilité de canal n’est pas supposée identique au stock website. |
| Des bundles ou composants Product sont-ils utilisés ? | Éléments sur composants et décrémentation du stock | Les relations de stock partagé sont documentées. |
| Des états négatifs, précommande ou backorder sont-ils utilisés ? | Liste des Products d’exception | Les exceptions de disponibilité ont un responsable. |
Consignez l’heure de chaque export de stock et évitez les nettoyages massifs tant que l’autorité source reste ambiguë.
Préparer Customers, adresses, segmentation et contexte B2B
Préparez identité Customer, e-mail, état du compte, adresses, langue, consentement ou statut de communication, champs de groupe/segmentation, contexte B2B ou société, traitement fiscal, données de fidélité ou crédit lorsqu’elles existent et identifiants externes. Utilisez le compte actuel et ses intégrations pour déterminer quels champs sont natifs, détenus par une application ou synchronisés.
| Schéma Customer | Action de préparation | Élément | Condition de préparation |
|---|---|---|---|
| Customer enregistré | Consigner identité, état du compte, adresses et relation Order | Exemples Customer et Order | La responsabilité du compte est claire. |
| Acheteur invité | Consigner e-mail et Orders historiques sans supposer l’existence d’un compte | Ensemble d’Orders invités | L’historique invité reste distinct. |
| Acheteur B2B ou société | Consigner société, Contacts, contexte de prix/fiscalité et responsable du compte | Registre d’exemples B2B | Les relations métier sont documentées. |
| Customer segmenté | Consigner groupe, tag, fidélité ou sens marketing et responsable | Dictionnaire de segmentation | Les libellés ont des définitions opérationnelles. |
| Customer lié à un système externe | Consigner IDs ERP, CRM, comptabilité, POS ou support | Dictionnaire de champs | Les clés de recherche aval sont connues. |
| Identité en double | Consigner e-mails dupliqués ou partagés et décision de traitement | Liste d’exceptions d’identité | Les enregistrements ambigus ont un responsable. |
Préparer Orders, paiements, livraison, logistique et références de canal
Préparez des Orders représentant les véritables schémas opérationnels de la boutique : ventes website et marketplace, différents libellés de paiement/livraison, Products à variantes, remises, remboursements, annulations, retours, factures, suivi, ajustements manuels, détails multilingues, cas B2B et références externes.
| Domaine Order | Action | Élément | Condition de préparation |
|---|---|---|---|
| Propriété du canal | Consigner source website/marketplace et identifiant de canal | Exemples d’Orders multicanaux | Chaque Order peut être relié à son origine. |
| Détail Product | Inclure choix de variante/option, SKU, quantité, prix et texte Product | Lignes Order représentatives | La configuration achetée reste compréhensible. |
| Statut et logistique | Consigner libellés de statut, état d’expédition, suivi, retours et notes opérationnelles | Dictionnaire de statuts et Orders | Le processus historique peut être interprété. |
| Totaux | Identifier taxes, livraison, remise, frais, remboursement et montants de paiement | Exemples de composantes de total | Le contexte financier est complet. |
| Documents | Consigner facture, reçu ou références fiscales lorsqu’utilisées | Exemples de documents et responsable | Les références historiques nécessaires sont traçables. |
| IDs externes | Consigner ERP, comptabilité, paiement, logistique, marketplace ou POS | Orders sensibles aux intégrations | Les besoins de recherche inter-systèmes sont documentés. |
Les libellés historiques de paiement et livraison sont des éléments relatifs aux Orders passés. Paiement actif, processus de commande, fiscalité, livraison et réglages logistiques doivent être configurés séparément dans la boutique cible.
Inventorier applications, plugins, connexions TeamSystem et systèmes externes
Créez un registre des dépendances couvrant applications, plugins, marketplaces, services de paiement, prestataires logistiques, comptabilité, ERP, POS, CRM, analyse, marketing, Reviews, flux et intégrations personnalisées. L’intégration de Storeden dans l’écosystème TeamSystem rend particulièrement important d’identifier les connexions que les équipes peuvent considérer comme faisant « partie de Storeden » alors qu’elles sont administrées dans un autre produit TeamSystem.
| Champ de dépendance | Détail requis | Condition de préparation |
|---|---|---|
| Nom du produit ou service | Nom actuel et historique lorsqu’ils diffèrent | La dépendance est identifiable par toutes les équipes. |
| Responsable et finalité | Responsable métier, responsable technique, processus soutenu | La responsabilité est explicite. |
| Objets de données | Products, stock, Customers, Orders, factures, contenu ou canaux utilisés | Les éléments source concernés sont connus. |
| Direction et fréquence | Lecture, écriture, bidirectionnel, planifié, événementiel ou manuel | L’autorité source est documentée. |
| Identifiants | SKU, Product ID, e-mail Customer, numéro Order, clé externe | Les dépendances de recherche sont préservées. |
| Décision de transition | Reconnecter, reconstruire, retirer, remplacer ou examiner | La continuité n’est pas supposée. |
Préparer contenu, thèmes, routes SEO et éléments de redirection
TeamSystem Commerce est décrit dans la source comme proposant des thèmes personnalisables, un e-commerce multilingue et des fonctions SEO. Le modèle de contenu exact et les exports disponibles doivent être confirmés dans le compte réel. Préparez pages, contenu Product/Category, blog ou contenu éditorial lorsqu’utilisé, images, menus, sections de thème, métadonnées, réglages canoniques, hreflang ou relations linguistiques, liens internes et règles de réécriture/redirection.
| Domaine de contenu | Responsable | Élément | Condition de préparation |
|---|---|---|---|
| Pages et politiques | Responsable contenu | Liste des pages, statut, route, langue, liens internes | Décisions conserver/reconstruire/fusionner/exclure documentées. |
| Contenu du thème | Responsable thème | Sauvegarde du thème ou captures, sections personnalisées, actifs intégrés | Le contenu stocké dans les couches de présentation est visible. |
| Métadonnées SEO | Responsable SEO | Titres, descriptions, réglages canoniques, relations linguistiques | Le contexte de recherche accompagne les éléments de route. |
| Redirections ou URLs réécrites | Responsable SEO/technique | Liste existante des redirections et anciennes routes prioritaires | Les règles historiques de continuité sont disponibles. |
| Médias | Responsable contenu | Images, documents, vidéos d’origine et liens Product | Les fichiers source peuvent être rapprochés des enregistrements. |
Préparer exports, captures, sauvegardes et limites source
Comme la documentation opérationnelle publique est limitée, l’archive d’éléments doit être particulièrement explicite. Enregistrez chaque export disponible avec sa date, son contexte de compte, les champs sélectionnés, les critères de filtre et son checksum. Capturez les relations absentes des exports et consignez tout champ ou objet impossible à exporter sans intervention administrateur ou support.
| Ensemble d’éléments | Contenu requis | Condition de préparation |
|---|---|---|
| Exports principaux | Fichiers Product, Customer, Order, Category, stock, contenu et canaux lorsque disponibles | Les fichiers sont datés et attribuables. |
| Captures et rapports | Variantes, applications, intégrations, réglages, langues, redirections et exceptions | Les relations non exportées sont visibles. |
| Archive médias et thème | Actifs d’origine et sauvegarde de thème/code disponible | Les fichiers source sont récupérables. |
| Dossier support | Contact de compte nommé et questions d’export non résolues | Les lacunes ont un responsable. |
| Journal des changements | Nouveaux Products, stock, Customers, Orders, canaux et URLs modifiés | Les changements ultérieurs peuvent être rapprochés. |
Ne comblez pas une lacune par une hypothèse non étayée. Consignez la limite et la personne chargée de confirmer le fonctionnement du compte actuel.
Sélectionner des enregistrements représentatifs pour les tests de migration
| Groupe d’échantillons | Inclure | Objectif de préparation |
|---|---|---|
| Products | Product simple, à variantes, multilingue, listé sur canal, exception de stock faible, Product enrichi par application | Exposer des schémas distincts de catalogue et responsabilité. |
| Customers | Enregistré, invité, B2B, segmenté, identité en double, Customer avec ID externe | Représenter différences de compte et d’intégration. |
| Orders | Website, marketplace, remboursement, retour, différents états logistiques, référence facture, Order système externe | Préserver le contexte opérationnel. |
| Découverte et contenu | Category prioritaire, route linguistique, landing page, URL Product, redirection | Préparer les relations d’itinéraire et de contenu. |
| Dépendances | Product, Customer ou Order touché par une intégration TeamSystem ou externe | Inclure les identifiants inter-systèmes dans les éléments. |
Chaque échantillon doit inclure une attente source expliquant pourquoi il est représentatif, quelles relations comptent et quels éléments doivent l’accompagner.
Terminer la porte de préparation Storeden
| Porte finale | Condition de préparation |
|---|---|
| Identité du compte | Dénominations Storeden/TeamSystem Commerce, compte, domaines, canaux et responsables sont rapprochés. |
| Catalogue | Products, variantes, Categories, langues, médias et champs personnalisés sont documentés. |
| Stock | Autorité, granularité, emplacements, canaux et exceptions sont connus. |
| Customers | Cas enregistrés, invités, B2B, segmentés, en double et avec IDs externes sont compris. |
| Orders | Canal, sélections Product, statuts, logistique, totaux, documents et IDs externes sont interprétables. |
| Dépendances | Applications, plugins, connexions TeamSystem, marketplaces et systèmes externes ont une décision. |
| Contenu | Thèmes, pages, médias, champs SEO, routes linguistiques et redirections sont préparés. |
| Entrées | Exports, captures, médias, contacts support, limites et journal de changements sont disponibles. |
| Échantillons | Les enregistrements représentatifs couvrent les schémas source ordinaires et complexes. |
Conclusion
La préparation d’une migration vers Storeden doit rapprocher le nom historique de la plateforme de son contexte TeamSystem Commerce actuel tout en s’appuyant sur les éléments du compte réel. Catalogue, stock, canaux, Customers, Orders, contenu, applications et connexions TeamSystem doivent être documentés par des responsables qui comprennent leur usage opérationnel.
Une archive complète rend visibles les limites de la source au lieu de les remplacer par des hypothèses. Elle fournit à la configuration de migration une base fiable même lorsque la documentation publique au niveau des champs est limitée.
Questions fréquentes
Pourquoi la checklist mentionne-t-elle TeamSystem Commerce alors que la plateforme s’appelle Storeden ?
TeamSystem présente désormais Storeden comme TeamSystem Commerce. Comptes existants, exports, intégrations et procédures internes peuvent utiliser l’un ou l’autre nom ; la préparation doit donc consigner explicitement leur relation.
Que faire lorsqu’un champ Storeden n’est pas couvert par la documentation publique actuelle ?
Utilisez les éléments du compte réel, exports, captures, responsables d’intégration et contacts support. Consignez tout fonctionnement non résolu comme limite de la source plutôt que de le deviner.
Quels Products Storeden faut-il échantillonner ?
Incluez Products simples et à variantes, Products multilingues, listés sur marketplace, exceptions de stock, Products riches en médias et enregistrements enrichis par applications ou systèmes externes.
Comment préparer un stock multicanal ?
Identifiez le système autoritaire, la granularité Product/variante, les emplacements, règles de réservation ou synchronisation et identifiants propres aux canaux.
Quels Orders sont les plus utiles pour la préparation ?
Utilisez Orders website et marketplace, remboursements, retours, différents états logistiques, références de facture/fiscales et Orders connectés à TeamSystem ou d’autres systèmes.
Comment contrôler les changements source après l’export ?
Maintenez un journal daté couvrant Products, stock, Customers, Orders, canaux, applications et URLs afin que les éléments de migration puissent être rapprochés de l’état actuel de la boutique source.