EShop est une extension e-commerce pour Joomla qui possède ses propres enregistrements de catalogue, Customers, Orders, prix, remises, taxes, expédition, paiement et commande. Joomla fournit le contexte environnant pour l’identité, les routes, les modules, les langues, les templates et le site. Une migration de données cohérente doit préserver la frontière entre ces deux couches, tout en distinguant les enregistrements commerciaux historiques de la configuration utilisée pour les opérations futures.
Lorsque EShop est la plateforme cible, des champs source portant des noms similaires peuvent nécessiter des représentations différentes. Un « attribut » source peut correspondre à une option de Product sélectionnée par l’acheteur, à un attribut informatif, à un champ personnalisé de Product, à un onglet de Product, à un champ de commande ou à un identifiant externe. Un groupe de Customers source peut piloter les prix plutôt que les droits d’accès. Le chemin d’une page source peut dépendre des Menu Items de Joomla au lieu d’appartenir directement au Product. Les décisions relatives au modèle de données doivent donc partir du sens et de la propriété des données, et non de leur seul libellé.
EShop combine les enregistrements commerciaux avec la structure du site Joomla
EShop possède les principaux enregistrements de la boutique. Joomla possède l’identité générale du site, la navigation, les modules, les templates, les langues, les accès et l’infrastructure des extensions. Les extensions de paiement, d’expédition, d’import, de reporting et d’intégration peuvent introduire des données ou des références supplémentaires.
| Couche propriétaire | Enregistrements courants | Conséquence pour la migration |
|---|---|---|
| Catalogue EShop | Products, Categories, fabricants, options, attributs, champs personnalisés, pièces jointes, prix, stock | Préserver les relations entre Products et distinguer les choix vendables des informations descriptives. |
| Historique commercial EShop | Customers, groupes, adresses, Orders, lignes de commande, coupons, bons, taxes, expédition, paiement, statuts | Conserver les instantanés historiques et les relations qui expliquent chaque transaction. |
| Noyau Joomla | Users, Menu Items, modules, langues, alias, templates, accès | Maintenir le contexte de route, d’identité et de présentation sans le traiter comme des données de catalogue EShop. |
| Extensions EShop et Joomla | Paiement, expédition, imports, modules, champs spécialisés, intégrations | Identifier l’extension propriétaire et déterminer si l’enregistrement est historique, opérationnel ou externe. |
| Systèmes externes | ERP, CRM, POS, traitement logistique, comptabilité, information produit | Préserver sur l’entité EShop les identifiants stables reconnus par le système externe. |
Cette répartition permet de garder un enregistrement Product distinct de la page Joomla qui l’expose, et de séparer la référence de paiement d’un Order de la configuration de l’extension de paiement utilisée pour les transactions futures.
Products, Categories, fabricants et relations de catalogue
Un Product EShop peut participer à de nombreuses relations de catalogue : affectation à des Categories, fabricant, médias, prix, stock, classe fiscale, dimensions, options, attributs, champs personnalisés, onglets, pièces jointes, Products associés, métadonnées, alias et valeurs propres à chaque langue. Une plateforme source peut regrouper ou séparer ces concepts différemment.
Les Categories peuvent former une hiérarchie et recevoir des affectations de Products. Les fabricants constituent une entité distincte, comparable à une marque. Les Products associés, les données de comparaison, les listes de souhaits, les filtres, les modules et la recherche peuvent tous dépendre de l’identité du Product sans pour autant devenir des champs du Product.
| Concept source | Représentation EShop possible | Relation à préserver |
|---|---|---|
| Famille de Products avec SKU enfants distincts | Product parent avec options, ou Products séparés reliés par des relations de merchandising | Identité vendable, stock, prix, médias et identifiants externes au bon niveau |
| Marque ou vendeur | Fabricant | Relation Product-fabricant sans fusionner le fabricant avec la taxonomie des Categories |
| Arborescence de rayons | Hiérarchie de Categories EShop | Structure parent-enfant, affectation des Products, alias, métadonnées et contexte linguistique |
| Article associé ou complémentaire | Relation entre Products associés | Direction et finalité de l’association Product-à-Product |
| Téléchargement, manuel ou fiche technique | Pièce jointe ou onglet de Product | Propriété du fichier, relation au Product, titre, langue et visibilité |
| Caractéristiques techniques du Product | Attribut, champ personnalisé ou onglet de Product | Sens descriptif sans créer de choix inutiles pour l’acheteur |
La représentation cible doit préserver la logique de gestion du catalogue source. Deux Products ayant des SKU et des identités d’entrepôt différents ne doivent pas être fusionnés uniquement parce qu’ils portent le même titre. À l’inverse, un système source qui crée un enregistrement par taille peut être mieux représenté par des options de Product EShop lorsque ces combinaisons appartiennent à un même Product de merchandising.
Les options, attributs, champs personnalisés et onglets de Product ne sont pas interchangeables
EShop distingue les choix effectués par l’acheteur des informations descriptives du Product. Les options correspondent aux sélections réalisées avant l’ajout au panier, comme la taille ou la couleur. Les attributs décrivent des informations utilisées pour la fiche Product ou la comparaison. Les champs personnalisés peuvent conserver des informations structurées supplémentaires propres au Product. Les onglets et pièces jointes peuvent présenter du contenu étendu, des vidéos, de la documentation ou des fichiers.
| Structure EShop | Sens principal | Exemples source |
|---|---|---|
| Option de Product | Choix de l’acheteur pouvant modifier la ligne achetée | Taille, couleur, conditionnement, finition, niveau de service |
| Valeur d’option | Sélection autorisée dans une option | Petit, moyen, bleu, coffret cadeau |
| Attribut de Product | Caractéristique informative utilisée pour la description ou la comparaison | Matière, processeur, capacité, compatibilité |
| Champ personnalisé de Product | Valeur structurée supplémentaire non couverte par les champs Product ordinaires | Code réglementaire, classification interne, référence externe |
| Onglet de Product | Section de contenu étendu sur la page Product | Spécifications, garantie, vidéo, conseils d’entretien |
| Pièce jointe | Fichier relié à un Product | Manuel, certificat, fiche technique, document téléchargeable |
Une option source ne doit devenir une option EShop que si le choix du Customer fait partie de la ligne de Product achetée. Une spécification technique qui ne modifie pas le choix vendable doit rester un attribut, un champ personnalisé ou une section de contenu. Aplatir ces structures peut créer des combinaisons d’options impossibles, des pages Product en double ou des lignes d’Order qui n’indiquent plus ce que l’acheteur avait réellement choisi.
Le sens commercial au niveau des options doit également être préservé. Lorsque les choix source influencent le prix, le SKU, le poids, l’image, le stock ou la disponibilité, la représentation cible doit maintenir ces relations ensemble. Un libellé sans le fonctionnement commercial qui l’accompagne ne constitue pas un modèle de données équivalent.
Customers, Users Joomla, groupes de Customers et adresses ont des rôles différents
Les Customers EShop peuvent être reliés à des identités User Joomla, mais les données Customer comprennent des relations commerciales propres à la boutique, notamment les adresses, Orders, listes de souhaits, récompenses et affectations de groupe. Une commande invitée peut créer des données historiques d’acheteur et d’adresse sans qu’un compte permanent soit créé.
Les groupes de Customers sont particulièrement importants, car EShop peut les utiliser pour appliquer des prix différenciés aux Products. À l’inverse, un groupe User Joomla représente normalement des permissions ou des droits d’accès. Un « groupe » source doit donc être qualifié selon sa fonction avant d’être migré.
| Enregistrement source | Sens cible dans EShop ou Joomla |
|---|---|
| Identifiant de connexion enregistré | Identité User Joomla reliée au Customer EShop approprié lorsque cette relation est prise en charge |
| Customer commercial | Profil d’acheteur EShop, adresses, relations avec les Orders et contexte de groupe commercial |
| Acheteur invité | Identité et adresse historiques conservées avec les Orders sans inventer de compte permanent |
| Segment grossiste ou niveau tarifaire | Groupe de Customers EShop lorsqu’il régit les prix ou l’éligibilité commerciale |
| Administrateur ou rôle éditorial | Groupe User Joomla et structure de permissions, et non groupe de Customers EShop |
| Organisation et contacts | Modèle organisation/contact distinct lorsqu’un simple enregistrement Customer ne suffit pas à préserver la relation |
La migration des adresses doit également distinguer les adresses réutilisables d’un Customer des instantanés enregistrés dans les Orders. Un Customer peut modifier son adresse après un achat, mais l’Order historique doit conserver les informations de facturation et d’expédition enregistrées au moment de la transaction.
Les Orders conservent les choix de Product, les données de commande et l’historique commercial
Un Order EShop peut conserver l’identité du Customer ou de l’invité, les adresses de facturation et d’expédition, les lignes de Products, les valeurs d’options sélectionnées, les quantités, prix, remises, coupons, bons, taxes, expédition, références de paiement, devise, statuts, champs personnalisés de commande, notes et horodatages. Ces enregistrements expliquent ce qui s’est produit ; ils ne définissent pas la manière dont la boutique cible doit calculer les transactions futures.
| Élément d’Order | Sens historique |
|---|---|
| Ligne de Product | Identité et description du Product acheté au moment de la vente |
| Valeurs d’options sélectionnées | Configuration réellement choisie par l’acheteur |
| Champ personnalisé de commande | Numéro de TVA, instruction de livraison, détail de retrait, référence d’entreprise ou autre valeur collectée |
| Prix, remise, coupon, bon et taxe | Instantané monétaire qui ne doit pas être recalculé selon de nouvelles règles |
| Méthode et montant d’expédition | Choix de traitement logistique et frais enregistrés pour l’Order |
| Méthode de paiement et référence de transaction | Contexte historique du paiement, et non configuration active de la passerelle |
| Devise | Devise utilisée pour la transaction et totaux enregistrés |
| Historique des statuts | Trace du cycle opérationnel utilisée pour le service et le reporting |
Les champs personnalisés de commande nécessitent leur propre logique de correspondance. Certaines valeurs décrivent le Customer, d’autres une adresse, certaines ne s’appliquent qu’à un seul Order, et d’autres encore identifient une entreprise externe ou un processus de livraison. Placer toutes les valeurs de commande sur le profil Customer peut créer des données obsolètes ou incorrectes ; conserver toutes les valeurs uniquement sous forme de texte dans l’Order peut rendre des identifiants métier réutilisables inaccessibles.
Prix, remises, taxes, expédition et paiement ont un côté historique et un côté configuration
EShop prend en charge les prix de Products, la tarification par groupe de Customers, les remises quantitatives, coupons, bons, taux de taxe, zones géographiques, devises ainsi que les extensions d’expédition et de paiement. Ces concepts remplissent deux rôles distincts dans le modèle de données.
Premièrement, les Orders historiques conservent le résultat commercial : prix facturés, remises appliquées, taxe enregistrée, expédition sélectionnée, références de paiement et totaux en devise. Deuxièmement, la boutique cible contient les règles actives et la configuration des extensions qui déterminent le fonctionnement futur.
| Domaine commercial | Enregistrement historique | Structure opérationnelle active |
|---|---|---|
| Prix par groupe de Customers | Prix ou remise reflété sur les anciennes lignes d’Order | Relation actuelle entre Product et groupe pour la tarification |
| Coupon ou bon | Code et effet de remise enregistrés dans un Order | Définition du coupon ou du bon, critères d’éligibilité, dates et usages restants |
| Taxe | Montant et libellé de taxe dans l’Order historique | Classe fiscale, taux, zone géographique et règles actuelles de calcul |
| Expédition | Libellé de méthode, frais, adresse et contexte de suivi | Extension d’expédition activée et conditions tarifaires actuelles |
| Paiement | Libellé de méthode, référence de transaction et statut | Extension de paiement activée, identifiants et configuration de traitement actuelle |
| Devise | Devise et totaux enregistrés dans l’Order | Devises publiées et fonctionnement actuel des taux de change |
Cette séparation évite que les données historiques soient réécrites par les règles actuelles et qu’un ancien Order soit considéré à tort comme une configuration opérationnelle complète.
Les données commerciales multilingues et les routes Joomla forment un modèle combiné
EShop prend en charge des données de boutique multilingues, tandis que Joomla fournit les relations plus générales de langue, de Menu, de module et de route. Les Products, Categories, fabricants, options, attributs, champs personnalisés, libellés et textes de vitrine peuvent comporter des valeurs propres à chaque langue. Les Menu Items et modules Joomla peuvent exposer des routes ou des contenus d’accompagnement différents selon la langue.
Une plateforme source qui stocke toutes les traductions dans un même Product peut nécessiter des valeurs EShop spécifiques à chaque langue. Une source qui utilise des enregistrements Product séparés peut nécessiter une logique d’association ou d’identifiants afin de préserver leur équivalence. Les traductions d’interface et les substitutions linguistiques doivent rester distinctes du contenu métier traduit.
| Enregistrement de langue ou de route | Sens dans la destination |
|---|---|
| Champ Product ou Category traduit | Contenu commercial destiné aux acheteurs dans une langue précise |
| Langue de contenu Joomla | Affectation linguistique utilisée par les enregistrements du site et des composants |
| Menu Item propre à une langue | Point d’entrée public, alias et contexte de navigation pour une langue |
| Module propre à une langue | Bloc de vitrine affiché dans les contextes linguistiques sélectionnés |
| Chaîne de langue d’interface | Texte d’extension ou de template, et non contenu Product ou Category |
| Alias et métadonnées de Product | Valeurs liées au SEO et aux routes, rattachées à l’enregistrement commercial concerné |
L’enregistrement Product et la route qui l’expose doivent rester distincts. Un Menu Item Joomla peut pointer vers une vue EShop et influencer le chemin public, tandis que l’alias du Product et le routeur EShop apportent leur propre contribution à la route. Traduire uniquement le titre du Product ne préserve pas cette structure combinée.
Modules, templates, thèmes et surcharges de mise en page sont des relations de présentation
EShop peut afficher des Products via les pages du composant, des modules Joomla, des Articles Joomla, la recherche, les filtres et des mises en page personnalisées. Les templates et surcharges peuvent modifier le rendu des Products, Categories, du panier, de la commande et du compte sans changer les enregistrements commerciaux sous-jacents.
| Objet de présentation | Interprétation dans le modèle de données |
|---|---|
| Module Product ou Category | Affichage réutilisable qui interroge les enregistrements EShop |
| Article Joomla intégrant une sortie Product | Enregistrement de contenu qui contient ou invoque une relation EShop |
| Surcharge de template | Logique de rendu, et non champ Product portable |
| Réglage de thème ou de mise en page | Configuration de présentation distincte de la propriété du catalogue |
| Module de filtre ou de recherche | Interface de découverte utilisant les attributs, Categories, fabricants ou autres données indexées des Products |
| Landing page personnalisée | Contenu Joomla ou de page builder faisant référence aux Products et Categories EShop |
Cette séparation permet au catalogue de rester la source de référence même si la destination utilise un autre page builder, template ou agencement de vitrine.
Extensions, imports, tables personnalisées et systèmes externes prolongent le modèle de base
EShop prend en charge les extensions de paiement et d’expédition, les imports et exports, les modules, les intégrations, les champs personnalisés et les mises en page personnalisées. Les boutiques anciennes peuvent aussi contenir des tables modifiées, des intégrations SQL directes, des synchronisations planifiées, des rapports personnalisés ou des identifiants provenant d’un ERP, CRM, POS, système comptable ou système de traitement logistique.
| Signal appartenant à une extension | Interprétation nécessaire |
|---|---|
| Référence de transaction de paiement | Relation historique Order/paiement pouvant être nécessaire au support ou au rapprochement |
| Identifiant de transporteur ou de traitement logistique | Relation avec l’expédition ou l’Order utilisée par un système externe |
| Clé d’import de Product | Identifiant stable de Product ou d’option utilisé pour les synchronisations répétées |
| Table personnalisée de commande | Valeurs au niveau de l’Order, du Customer, de l’adresse ou de l’organisation dont la propriété doit être explicite |
| ID externe de Product ou de Customer | Identifiant qui doit rester attaché à l’entité cible reconnue par le système connecté |
| Statut ou métadonnée créé par une extension | Sens défini par l’extension et non par un champ EShop ordinaire |
La destination n’a pas besoin de copier chaque table source. Elle doit en revanche attribuer un propriétaire explicite à chaque valeur essentielle au métier et décider délibérément si cette valeur devient un champ EShop natif, un enregistrement appartenant à une extension, une relation Joomla ou une référence vers un système externe.
Conclusion
La migration vers EShop est une traduction entre les couches catalogue, transaction, Joomla, présentation, extensions et systèmes externes. Products, options, attributs, champs personnalisés, Customers, groupes, adresses, Orders, champs de commande, prix, taxes, expédition, paiement, langues, routes de Menu et modules portent chacun des significations différentes en matière de propriété et de relations.
Un modèle cible cohérent préserve ces distinctions avant la transformation des enregistrements. Les choix de l’acheteur restent ainsi attachés aux lignes de Product, les totaux historiques aux Orders, les groupes commerciaux séparés des permissions Joomla, les traductions reliées aux bons enregistrements commerciaux et les identifiants externes rattachés aux entités utilisées par les systèmes connectés.
Questions fréquentes
Les options et attributs de Product EShop sont-ils identiques ?
Non. Les options représentent les choix effectués par l’acheteur et peuvent apparaître sur la ligne achetée. Les attributs décrivent les informations du Product utilisées pour la fiche ou la comparaison. Les champs personnalisés, onglets et pièces jointes remplissent d’autres fonctions descriptives.
Chaque variation de Product source doit-elle devenir une option EShop ?
Seulement lorsque les enregistrements source sont des choix au sein d’un même Product de merchandising. Des SKU distincts disposant de leurs propres URL, cycle de vie, stock, médias ou identifiants externes peuvent devoir rester des Products séparés ou nécessiter un modèle parent-enfant plus explicite.
Les groupes User Joomla sont-ils équivalents aux groupes de Customers EShop ?
Non. Les groupes User Joomla contrôlent normalement les permissions et les accès. Les groupes de Customers EShop peuvent représenter une segmentation commerciale, par exemple une tarification différenciée. Un groupe source doit être associé selon ce qu’il régit réellement.
Où faut-il stocker les champs personnalisés de commande ?
Cela dépend de leur sens. Les valeurs d’identité réutilisables peuvent appartenir à un Customer ou à une organisation, les valeurs d’adresse à une adresse, et les instructions ou références propres à une transaction à l’Order.
Les Orders historiques définissent-ils le fonctionnement futur des taxes, de l’expédition et du paiement ?
Non. Les Orders conservent les montants, libellés, références et choix enregistrés au moment de l’achat. Les calculs et traitements futurs dépendent des règles actuelles de la destination et des extensions activées.
Comment gérer les Menu Items Joomla autour des Products et Categories EShop ?
Les Menu Items doivent rester des enregistrements de route et de navigation qui pointent vers des vues EShop. Ils peuvent influencer les alias, la hiérarchie, la langue, les accès et le contexte du template, mais ils ne remplacent pas les Products ou Categories EShop sous-jacents.