osCMax se comprend avant tout comme une installation e-commerce dérivée d’osCommerce dont le véritable modèle de données dépend du package installé, des contributions, des templates, des fichiers modifiés et des structures de base de données personnalisées. Deux boutiques osCMax peuvent partager des tables familières pour Products, Categories, Customers et Orders tout en fonctionnant différemment parce que l’une utilise une contribution intégrée, l’autre des années de modifications directes du code et une troisième des exports personnalisés ou des systèmes externes.
La lignée et la propriété des données comptent donc davantage que le simple nom des enregistrements. Un champ Product peut appartenir au cœur dérivé d’osCommerce, à une colonne ajoutée par une contribution, à une valeur utilisée uniquement pour l’affichage du template ou à une clé d’intégration externe. Un total Order peut correspondre à un sous-total ou à une taxe standard, ou être produit par une remise, un supplément, un bon cadeau, un module de livraison ou un module de paiement. Un bloc visible dans le storefront peut contenir du contenu métier tout en étant géré par du code de template ou de module plutôt que par une entité CMS.
Le modèle de migration doit donc séparer les faits e-commerce de base des fonctions détenues par des contributions et des éléments purement liés à la présentation. L’objectif n’est pas de reproduire chaque mécanisme historique, mais de préserver les relations Product, Customer, Order, contenu et identifiants qui conservent une valeur métier.
Le sens des données osCMax dépend d’abord de leur lignée et des contributions installées
osCMax appartient à la famille osCommerce, mais a été distribué avec des fonctions supplémentaires et a souvent été enrichi par des contributions. Les boutiques exploitées pendant de nombreuses années peuvent contenir plusieurs générations de fichiers du cœur, correctifs de base de données, templates, fichiers de langue, modules de paiement, modules de livraison, modules de totalisation des Orders et modifications propres au marchand.
La version source ne constitue donc pas, à elle seule, une description suffisante du schéma. Le code installé et la base de données doivent être cohérents. Une table peut sembler standard tout en comportant des colonnes supplémentaires. Un champ familier peut être lu par du code personnalisé. Une contribution peut créer ses propres tables et les relier aux Products, Customers ou Orders via des identifiants internes. La lignée des données est donc une question de propriété au niveau des données, et pas seulement un inventaire technique.
| Couche source | Éléments généralement observés | Conséquence pour le modèle de données |
|---|---|---|
| Cœur dérivé d’osCommerce | Products, Categories, Customers, adresses, Orders, fabricants, Reviews | Se traduit généralement à travers des relations e-commerce familières. |
| Couche package osCMax | Améliorations intégrées, conventions de templates, champs d’administration | Vérifier si la valeur est une donnée, une configuration ou un élément de présentation. |
| Contribution installée | Tables, champs, statuts, rapports, remises, bons, logique de livraison ou de paiement ajoutés | Identifier la contribution et ses liens avec les données de base. |
| Modification propre au marchand | PHP modifié, changements SQL, fichiers de langue personnalisés, exports spécifiques | Traiter cet élément comme une frontière de propriété personnalisée, et non comme un fonctionnement natif de la plateforme. |
| Système externe | ERP, comptabilité, entrepôt, marketplace, CRM, flux fournisseur | Préserver les identifiants externes stables et la source faisant autorité. |
| Artefact technique obsolète | Tables de modules abandonnés, champs inutilisés, anciens fichiers de templates | Ne pas transformer des résidus techniques inutilisés en données cibles permanentes. |
Cette lecture par couches évite une erreur fréquente : supposer que tous les enregistrements présents dans une table reconnaissable de type osCommerce ont le même sens dans toutes les installations osCMax.
Products, Categories, fabricants et attributs constituent le cœur du catalogue
Le catalogue osCMax de base s’articule généralement autour des Products, Categories, fabricants, descriptions Product, images, stock, prix, promotions, Reviews et attributs Product. Les Products peuvent être affectés à plusieurs Categories, tandis que les installations multilingues peuvent stocker séparément les noms et descriptions par langue. Les attributs relient des noms d’option et des valeurs aux Products et peuvent modifier le prix, le poids, le modèle, le stock ou d’autres fonctions selon les contributions installées.
La relation entre Products, Categories et attributs est plus importante que les lignes prises séparément. Une boutique source peut utiliser un seul Product avec plusieurs attributs, des enregistrements Product distincts pour chaque SKU, ou des tables de stock par attribut créées par une contribution. Le modèle cible ne doit pas déduire l’existence de variantes indépendantes simplement parce que des valeurs d’option existent, et ne doit pas non plus placer tout le stock sur le Product parent lorsque les combinaisons sont vendues indépendamment.
| Structure source | Interprétation dans osCMax | Relation à préserver |
|---|---|---|
| Product standard | Enregistrement Product de base | Identité, description, prix, taxe, stock, images et liens avec les Categories. |
| Product affecté à plusieurs Categories | Relation Product vers Category | Une même identité commerciale accessible par plusieurs chemins de découverte. |
| Fabricant ou marque | Enregistrement fabricant et lien avec le Product | L’identité de marque reste distincte du classement par Category. |
| Attribut de taille ou de couleur | Relation d’attribut Product | Nom de l’option, valeur, Product, effet sur le prix ou le poids et libellé enregistré sur la ligne Order. |
| Stock propre à une combinaison | Donnée de stock par attribut détenue par une contribution | Product, combinaison d’options, quantité, SKU et clé externe. |
| Prix promotionnel | Relation entre Product et promotion | Prix actif et contexte temporel distincts du prix de base. |
| Review | Review liée au Product et, lorsque disponible, au Customer | Note, texte, date, statut et identité Product. |
Une description Product peut afficher presque n’importe quelle information, mais elle ne remplace pas les relations structurées entre Category, fabricant, attribut, stock ou Review.
Les combinaisons d’attributs, stocks, images et prix dépendent souvent d’extensions
Les boutiques osCMax historiques utilisent fréquemment des contributions pour étendre le modèle d’attributs Product du cœur. Ces extensions peuvent introduire du stock au niveau des attributs, des SKU distincts par combinaison, des images supplémentaires, des champs Product additionnels, des remises par quantité, des prix par groupe Customer, des bons cadeaux ou des configurateurs Product. Le storefront peut donner l’impression que ces fonctions sont natives alors que leurs données se trouvent en dehors des tables principales.
Chaque choix doit être classé selon son rôle commercial. Une option purement descriptive n’a pas besoin d’un stock indépendant. Une combinaison vendable disposant de son propre SKU et de son propre stock, oui. Une saisie texte doit rester associée à la ligne Order. Un tarif par quantité appartient à une relation entre Product et seuil. Une image supplémentaire peut être liée au Product, à une valeur d’option ou à une contribution de galerie utilisée par le template.
| Fonction observée | Propriétaire probable | Limite de représentation |
|---|---|---|
| L’option modifie uniquement le prix ou le poids | Relation d’attribut Product du cœur | Conserver le nom de l’option, la valeur, le lien Product et l’ajustement. |
| La combinaison dispose de son propre stock ou SKU | Contribution de stock/variante par attribut | Préserver l’identité de la combinaison et sa quantité séparément du parent. |
| Le client saisit une gravure ou un message | Contribution de saisie texte | Conserver la valeur saisie sur la ligne Order achetée. |
| Le Product possède plusieurs images de galerie | Contribution d’images ou convention de template | Préserver l’identité du média et sa relation au Product ou à l’option. |
| Prix par quantité ou par groupe Customer | Contribution de tarification | Conserver Product, seuil ou groupe, devise et montant dans la même relation. |
| Bon cadeau ou voucher | Contribution de voucher et enregistrements Order associés | Préserver code, solde, destinataire, utilisation et historique Order lorsque ces données sont encore actives. |
Les relations réelles entre les tables et le code de la boutique source déterminent l’interprétation. Un export générique d’attributs ne suffit pas lorsqu’une extension conserve l’identité réellement vendable ailleurs.
Customers, carnets d’adresses, groupes et extensions de compte doivent rester distincts
Le modèle Customer dérivé d’osCommerce comprend généralement un compte Customer, un carnet d’adresses, des références vers l’adresse par défaut, des informations de connexion et des préférences de communication. Des contributions osCMax peuvent ajouter des groupes de clients, statuts de vente en gros, identifiants fiscaux, champs de profil supplémentaires, données de parrainage, points de fidélité, avoirs ou processus d’approbation.
Ces données doivent être séparées selon leur fonction. Une adresse enregistrée appartient aux données Customer réutilisables. Les adresses de facturation et de livraison enregistrées sur un Order sont des instantanés de la transaction. Un groupe de vente en gros peut piloter les prix ou les droits d’accès. Une source marketing ou un code de parrainage peut être une donnée de reporting. Un identifiant CRM externe peut être la clé qui permet de reconnecter le Customer après la migration.
| Élément du compte source | Propriétaire | Sens à conserver |
|---|---|---|
| Compte Customer | Enregistrement Customer du cœur | Identité et lien vers les adresses et Orders. |
| Entrée du carnet d’adresses | Enregistrement d’adresse Customer | Relation d’adresse réutilisable. |
| Adresse de facturation/livraison d’un Order | Instantané Order | Preuve historique indépendante des données Customer actuelles. |
| Groupe grossiste ou revendeur | Classification Customer détenue par une contribution | Appartenance au groupe et règles associées de prix ou d’accès. |
| Champ de profil supplémentaire | Champ de contribution ou table personnalisée | Finalité du champ, confidentialité et clé Customer. |
| Points de fidélité ou avoir | Contribution de fidélité/crédit | Solde, historique des opérations et processus associé. |
| Clé ERP ou CRM | Identifiant externe | Identité durable entre systèmes. |
Un export Customer aplati peut conserver les coordonnées tout en perdant la relation commerciale qui faisait du Customer un revendeur, un acheteur exonéré de taxe ou un compte bénéficiant d’un crédit.
Orders, lignes de total, statuts, paiements et livraison constituent des preuves historiques
Les Orders osCMax peuvent contenir l’identité Customer ou invité, des instantanés d’adresses de facturation et livraison, des lignes Product, des libellés d’attributs, quantités, prix, taxes, remises, frais de livraison, libellés de paiement, statuts Order, commentaires et données détenues par des contributions. La couche de totalisation est particulièrement importante, car de nombreux modules historiques créent des lignes distinctes pour le sous-total, les taxes, la livraison, Coupons, vouchers, suppléments, frais de petite commande, remises ou avoirs.
Ces lignes ne sont pas interchangeables avec la configuration actuelle du processus de commande. Les Orders historiques doivent conserver ce qui a été facturé et pourquoi, même si la boutique cible utilise des règles différentes pour les taxes, la livraison, le paiement ou les promotions. Un identifiant de transaction provenant d’un module de paiement peut constituer une preuve historique importante, mais les identifiants d’accès ou le code de l’ancien module ne font pas partie des données Order à transférer.
| Élément Order | Propriétaire historique | Sens à préserver |
|---|---|---|
| Ligne Product | Instantané Product dans l’Order | Nom, modèle/SKU, quantité, prix et attributs sélectionnés au moment de l’achat. |
| Adresse | Instantané de facturation/livraison de l’Order | Adresse historique indépendante des données Customer actuelles. |
| Ligne de total Order | Module de totalisation ou enregistrement du cœur | Libellé, montant, ordre d’affichage et effet sur le total final. |
| Référence de paiement | Donnée de transaction du module de paiement | Clé de rapprochement historique sans la confondre avec une configuration active. |
| Méthode de livraison et suivi | Module de livraison et contexte d’expédition | Libellé du transporteur ou service, frais, suivi et preuve de traitement. |
| Statut Order et commentaires | Historique Order | Séquence, date, visibilité et contexte équipe/client. |
| Retour, voucher ou avoir | Donnée après-vente détenue par une contribution | Lien avec l’Order, montant concerné et solde restant lorsque pertinent. |
Le modèle Order reste exploitable lorsque l’équipe peut comprendre la transaction historique sans devoir reconstruire le module retiré qui l’avait produite.
Contenus, blocs, templates, fichiers de langue et images ont des propriétaires différents
Les storefronts osCMax utilisent souvent des templates, blocs, fichiers de langue, bannières, pages d’information, descriptions Product, descriptions Category, images, boutons et contenus générés par des contributions. Tous influencent ce que voit l’acheteur, mais ils ne constituent pas une seule entité de contenu.
Les descriptions Product et Category appartiennent aux données du catalogue. Les pages d’information peuvent être stockées dans une contribution de contenu ou dans des fichiers statiques. Les titres de blocs et textes d’interface peuvent se trouver dans les fichiers de langue. Le positionnement des blocs appartient au template. Les boutons et icônes sont des ressources de thème. Un bloc promotionnel peut être généré par de la configuration plutôt qu’enregistré comme une page.
| Élément du storefront | Propriétaire des données ou de la présentation | Interprétation pour la migration |
|---|---|---|
| Description Product/Category | Donnée de catalogue | Préserver le contenu avec la donnée et la langue correspondantes. |
| Page d’information ou de politique | Contribution de contenu ou contenu statique | Préserver l’identité de la page, son URL et sa relation de navigation lorsqu’elle reste utile. |
| Titre de bloc ou libellé d’interface | Fichier de langue | Le traiter comme texte d’interface, pas comme contenu CMS. |
| Position d’un bloc | Configuration de template | Reconstruire l’emplacement cible séparément du contenu. |
| Image de galerie Product | Product ou contribution d’images | Préserver la relation média et son niveau Product/option/variante. |
| Bouton, icône ou arrière-plan | Ressource de thème | Ne le conserver que s’il possède encore une valeur de design. |
| Ancienne URL | Product, Category, contenu ou route personnalisée | Maintenir la relation de redirection entre la source et la cible. |
Cette séparation permet de transférer les contenus et médias utiles sans emporter avec eux la mécanique obsolète des anciens templates.
Les contributions et tables personnalisées peuvent détenir des données essentielles
Le principal défi d’osCMax vient de la propriété des contributions. Une contribution peut ajouter un champ à une table du cœur, créer une donnée autonome, modifier un calcul Order, introduire un nouveau statut ou maintenir une relation via une clé personnalisée. La décision côté cible dépend de la fonction métier, pas de la facilité avec laquelle la ligne peut être exportée.
| Structure de contribution | Exemple de sens | Décision de propriété nécessaire |
|---|---|---|
| Colonnes Product ajoutées | Code fournisseur, badge, garantie, restriction, statut de flux | Les représenter dans un champ natif, un attribut structuré, une clé externe ou une archive. |
| Table Product personnalisée | Compatibilité produit, composant de bundle, abonnement, tarification par niveau | Préserver la donnée et ses relations Product lorsqu’elle reste active. |
| Extension Customer | Approbation, fidélité, parrainage, fiscalité, statut revendeur | Conserver la classification et les règles ou l’historique qui lui donnent son sens. |
| Extension Order | Indicateur de fraude, statut d’export, référence de paiement, lot de traitement | Conserver comme métadonnée historique ou reconnecter au processus cible. |
| Table de reporting/export | État d’un export comptable ou opérationnel | La conserver uniquement si elle reste la donnée métier faisant autorité. |
| Logique du cœur modifiée | Règle de taxe, livraison, prix ou permission modifiée | Représenter la règle métier dans le modèle cible plutôt que l’ancien mécanisme PHP. |
Lorsqu’aucun processus actuel ne consomme plus une donnée de contribution, l’archiver peut être plus exact que la forcer dans un champ personnalisé générique. Les données encore actives nécessitent au contraire un propriétaire explicite et des liens stables vers les Products, Customers ou Orders concernés.
Décisions de représentation osCMax guidées par le sens métier
| Structure source | Bonne question à poser | Conséquence d’une mauvaise hypothèse |
|---|---|---|
| Table du cœur familière avec colonnes supplémentaires | Quels champs appartiennent au cœur, au package, à une contribution ou à une personnalisation ? | Des données d’extension sont prises à tort pour un champ natif de la cible. |
| Attributs Product avec table de stock séparée | Quelle combinaison détient réellement le SKU et la quantité ? | Le stock du parent remplace à tort celui de la combinaison vendable. |
| Groupe Customer ou indicateur revendeur | Quels prix, droits d’accès, taxes ou conditions de paiement en dépendent ? | Le nom du groupe est conservé, mais sa signification commerciale disparaît. |
| Plusieurs lignes de total Order | Quel module a produit chaque montant et comment celui-ci intervient-il dans le total final ? | Les totaux historiques deviennent incomplets ou trompeurs. |
| Bloc du storefront | S’agit-il de contenu, de configuration, de texte de langue ou d’un emplacement du template ? | Le texte visible arrive sans son URL ni son emplacement, ou du code obsolète est conservé comme donnée. |
| Identifiant d’export personnalisé | Quel système externe possède cette clé ? | Products, Customers ou Orders ne peuvent plus être rapprochés après la migration. |
| Table d’une contribution abandonnée | Un processus actuel en dépend-il encore ? | Un résidu technique est conservé inutilement comme donnée cible permanente. |
Les données osCMax conservent leur utilité lorsque les faits e-commerce fondamentaux sont séparés des mécanismes de contribution ou de template qui les présentaient ou les traitaient auparavant.
Conclusion
La représentation du modèle de données osCMax commence par la lignée. Products, Categories, Customers, adresses, Orders, fabricants, Reviews et attributs peuvent suivre le cœur dérivé d’osCommerce, tandis que des extensions peuvent ajouter du stock séparé, de la tarification, des vouchers, des classifications Customer, des lignes de total Order, des structures de contenu, des exports et des tables personnalisées. Les templates et fichiers de langue influencent eux aussi le storefront sans devenir pour autant des données e-commerce ordinaires.
Une boutique cible bien conçue préserve les faits métier et les relations encore actives : identité Product, choix vendables, contexte Customer, totaux Order historiques, contenus utiles et identifiants externes. Elle ne suppose pas que chaque contribution, fichier modifié ou artefact d’ancien template mérite un équivalent direct dans la cible.
Questions fréquentes
Pourquoi deux boutiques osCMax peuvent-elles avoir des modèles de données différents ?
Parce que leurs versions de package, contributions, templates, correctifs de base de données et modifications propres au marchand peuvent différer. Les mêmes tables du cœur peuvent donc comporter d’autres champs ou être interprétées par un code différent.
Les attributs Product d’osCMax sont-ils équivalents à des variantes indépendantes ?
Pas toujours. Les attributs du cœur peuvent modifier un Product, tandis qu’une contribution peut ajouter un SKU, un stock, un prix ou des images propres à chaque combinaison. L’existence d’une identité vendable indépendante doit être déduite de la relation complète, et non du simple nom des options.
Comment interpréter les groupes Customer ou les champs revendeur ?
Il faut identifier ce qu’ils contrôlent réellement, par exemple les prix, l’accès, le traitement fiscal, les conditions de paiement ou l’approbation. Le libellé de classification ne suffit pas sans les règles commerciales associées.
Pourquoi les lignes de total Order d’osCMax sont-elles importantes ?
Elles peuvent expliquer le sous-total, les taxes, la livraison, les Coupons, bons cadeaux, remises, frais ou avoirs. Conserver uniquement le total final fait disparaître la structure qui explique historiquement comment ce montant a été calculé.
Les templates, blocs, boutons et fichiers de langue doivent-ils être migrés comme du contenu ?
Uniquement lorsqu’ils contiennent du contenu métier encore utile. L’emplacement, les libellés d’interface et les ressources visuelles appartiennent à la présentation. Leur fonction doit être séparée des données Product, Category et du contenu éditorial.
Que faire des données détenues par des contributions ou des tables personnalisées ?
Il faut identifier la contribution, les données de base qu’elle étend et le processus qui consomme encore ces données. Les relations actives ont besoin d’un propriétaire explicite côté cible ; les données obsolètes peuvent être archivées ou exclues plutôt que forcées dans des champs génériques.