bemade-addons/st_laurent_portal_vendor/doc/analyse.md

Analyse du module st_laurent_portal_vendor

Introduction

Le module st_laurent_portal_vendor est une extension des modules vendor_portal_management et vendor_product_management qui ajoute des fonctionnalités e-commerce aux produits fournisseurs. Ce module permet aux vendeurs de gérer leurs produits, leurs images et leurs informations e-commerce via un portail dédié.

Structure de données

Modèles principaux

1. vendor.product (extension)

Le modèle vendor.product est étendu pour inclure des fonctionnalités e-commerce :

• Champs d'image : image_1920, image_1024, image_512, image_256, image_128
• Champs e-commerce :
  • website_published : Indique si le produit est publié sur le site web
  • website_description : Description HTML pour le site web
  • website_url : URL du produit sur le site web
  • public_categ_ids : Catégories du site web
  • product_tag_ids : Tags pour le filtrage et la catégorisation
• Prix et disponibilité :
  • website_price : Prix affiché sur le site web
  • website_ribbon : Texte affiché dans un ruban sur le produit
  • availability : État de disponibilité du produit
  • availability_date : Date de disponibilité
• SEO et métadonnées :
  • website_meta_title : Titre Meta
  • website_meta_description : Description Meta
  • website_meta_keywords : Mots-clés Meta
  • website_meta_og_img : Image Open Graph

2. vendor.request

Nouveau modèle pour gérer les demandes pour devenir vendeur :

• Informations de base :
  • name : Référence de la demande
  • partner_id : Contact associé
  • user_id : Utilisateur associé
• Informations de l'entreprise :
  • company_name : Nom de l'entreprise
  • company_street, company_street2, company_zip, company_city : Adresse
  • company_state_id, company_country_id : État/Province et Pays
  • company_email, company_phone, company_website : Coordonnées
  • company_vat : Numéro de TVA/TPS
• Gestion de la demande :
  • state : État de la demande (brouillon, en attente, approuvée, rejetée)
  • rejection_reason : Motif de rejet
  • approved_date : Date d'approbation
  • attachment_ids : Documents joints

3. res.partner (extension)

Le modèle res.partner est étendu pour gérer le statut vendeur :

• vendor_status : Statut vendeur (oui/non)
• is_vendor : Champ calculé indiquant si le partenaire est un vendeur
• vendor_request_ids : Relation avec les demandes de vendeur
• has_pending_vendor_request : Indique si le partenaire a une demande en attente

4. res.users (extension)

Le modèle res.users est étendu pour accéder facilement aux informations vendeur :

• is_vendor : Champ lié au partenaire
• vendor_status : Champ lié au partenaire
• has_pending_vendor_request : Champ lié au partenaire
• vendor_request_ids : Champ lié au partenaire

Relations entre les modèles

• vendor.product est lié à res.partner via le champ partner_id
• vendor.request est lié à res.partner via le champ partner_id
• vendor.request est lié à res.users via le champ user_id
• vendor.product peut être lié à product.template et product.product via les champs product_tmpl_id et product_id

Analyse comparative : vendor.product vs extension de product.product

Une question architecturale importante concerne le choix entre maintenir un modèle vendor.product séparé ou simplement étendre le modèle product.product existant. Voici une analyse des avantages et inconvénients de chaque approche :

Approche 1 : Modèle vendor.product séparé (approche actuelle)

Avantages :

1. Séparation claire des préoccupations : Les produits vendeurs et les produits standard sont gérés séparément, ce qui simplifie la logique métier.
2. Contrôle du workflow : Permet un processus de validation avant qu'un produit vendeur ne devienne un produit standard.
3. Sécurité et permissions : Facilite la gestion des droits d'accès, les vendeurs n'ayant accès qu'à leurs propres produits sans risque d'altérer les produits standard.
4. Données spécifiques aux vendeurs : Permet de stocker des informations propres aux vendeurs sans surcharger le modèle product.product.
5. Évolutivité : Facilite l'ajout de fonctionnalités spécifiques aux vendeurs sans impacter le catalogue principal.

Inconvénients :

1. Duplication potentielle : Certaines données sont dupliquées entre vendor.product et product.product.
2. Complexité de synchronisation : Nécessite un mécanisme pour maintenir la cohérence lors de la conversion d'un produit vendeur en produit standard.
3. Requêtes plus complexes : Les recherches impliquant à la fois des produits vendeurs et standard nécessitent des jointures ou des unions.

Approche 2 : Extension du modèle product.product

Avantages :

1. Modèle de données unifié : Un seul modèle pour tous les produits, simplifiant les requêtes et les rapports.
2. Pas de duplication : Évite la redondance des données et les problèmes de synchronisation.
3. Intégration native : Fonctionne naturellement avec toutes les fonctionnalités existantes d'Odoo (inventaire, ventes, achats).
4. Maintenance simplifiée : Moins de code à maintenir et à tester.

Inconvénients :

1. Confusion potentielle : Mélange des produits vendeurs et standard dans la même table, ce qui peut compliquer la gestion.
2. Risques de sécurité : Plus difficile de restreindre l'accès des vendeurs uniquement à leurs produits.
3. Surcharge du modèle : Ajout de nombreux champs qui ne sont pertinents que pour les produits vendeurs.
4. Workflow moins flexible : Plus difficile d'implémenter un processus de validation avant qu'un produit ne soit disponible dans le catalogue principal.
5. Impact sur les performances : L'ajout de nombreux produits vendeurs peut ralentir les opérations sur la table product.product.

Comment l'approche actuelle résout ces problèmes :

1. Séparation claire : Avec vendor.product, il n'y a pas de confusion possible entre les produits vendeurs et les produits standard, chacun étant dans sa propre table.
2. Sécurité renforcée : Les règles d'accès peuvent être définies précisément sur le modèle vendor.product sans affecter l'accès aux produits standard.
3. Modèles spécialisés : Chaque modèle ne contient que les champs pertinents pour son usage, évitant la surcharge et améliorant la lisibilité.
4. Workflow de validation : Un produit vendeur peut suivre son propre cycle de vie et de validation avant d'être converti en produit standard.

Conclusion

L'approche actuelle avec un modèle vendor.product séparé est justifiée par :

1. La nécessité d'un workflow de validation : Les produits vendeurs doivent être vérifiés avant d'être intégrés au catalogue principal.
2. Les exigences de sécurité : Les vendeurs ne doivent avoir accès qu'à leurs propres produits.
3. La spécificité des données vendeur : De nombreux champs sont spécifiques aux produits vendeurs et n'ont pas leur place dans le modèle standard.
4. L'évolutivité future : La séparation facilite l'ajout de fonctionnalités spécifiques aux vendeurs dans des modules complémentaires.

Cependant, pour des cas d'utilisation plus simples où ces considérations sont moins importantes, l'extension du modèle product.product pourrait être une solution plus légère et plus facile à maintenir.

Recommandations spécifiques pour la gestion des prix et commissions

Considérant que les listes de prix des vendeurs sont des prix de vente et que la plateforme prélève un pourcentage en commission, voici des recommandations supplémentaires :

1. Modèle vendor.product séparé (recommandé)

   • Gestion des prix : Permet de stocker à la fois le prix vendeur original et le prix final (incluant la commission) sans confusion.
   • Calcul des commissions : Facilite l'implémentation de règles de commission variables par vendeur, par catégorie ou par produit.
   • Transparence pour les vendeurs : Les vendeurs peuvent voir clairement leur prix de vente et la commission prélevée.
   • Rapports financiers : Simplifie la génération de rapports sur les ventes et les commissions par vendeur.
   • Flexibilité des promotions : Permet aux vendeurs de créer des promotions sans affecter la structure de commission.

2. Extension de product.product (non recommandée pour ce cas d'usage)

   • Complexité accrue : Nécessiterait des champs supplémentaires pour gérer les prix vendeurs, les commissions et les prix finaux.
   • Risque de confusion : Les prix standards et les prix vendeurs pourraient être confondus dans les processus de vente.
   • Difficultés comptables : La séparation des revenus (part vendeur vs commission) serait plus complexe à gérer.

Recommandation finale : Dans un modèle d'affaires basé sur des commissions prélevées sur les ventes des vendeurs, l'approche avec un modèle vendor.product séparé est fortement recommandée. Elle offre une séparation claire des flux financiers, une meilleure traçabilité des transactions, et une plus grande flexibilité pour adapter les règles de commission selon différents critères.

Stratégies de synchronisation entre vendor.product et product.product

L'utilisation de deux modèles séparés nécessite une stratégie de synchronisation efficace, notamment pour les changements de prix et autres mises à jour importantes :

1. Synchronisation des prix

   • Changements de prix vendeur : Lorsqu'un vendeur modifie son prix, un mécanisme de recalcul automatique du prix final (incluant la commission) doit être déclenché.
   • Règles de propagation : Définir clairement quand et comment les changements de prix sont propagés au produit standard correspondant.
   • Historique des prix : Conserver un historique des changements de prix pour l'audit et l'analyse.

2. Synchronisation des attributs produit

   • Attributs à synchroniser : Identifier clairement quels attributs doivent être synchronisés (ex: nom, description, catégories) et lesquels restent spécifiques à chaque modèle.
   • Direction de la synchronisation : Déterminer si la synchronisation est unidirectionnelle (vendor.product → product.product) ou bidirectionnelle selon les attributs.
   • Règles de priorité : Établir des règles de priorité en cas de conflit (ex: qui du vendeur ou de l'administrateur a le dernier mot sur certains attributs).

3. Mécanismes techniques de synchronisation

   • Triggers automatiques : Utiliser des déclencheurs sur les méthodes write et create pour propager automatiquement les changements.
   • Jobs planifiés : Pour les synchronisations non critiques, utiliser des tâches planifiées pour réduire la charge sur le système.
   • Verrouillage optimiste : Implémenter un mécanisme de verrouillage optimiste pour éviter les problèmes de concurrence lors des mises à jour.

4. Interface utilisateur et expérience vendeur

   • Transparence : Informer clairement les vendeurs des règles de synchronisation et des délais potentiels.
   • Validation : Mettre en place des processus de validation pour certaines modifications critiques avant leur propagation.
   • Notifications : Alerter les vendeurs lorsque leurs modifications ont été appliquées ou si des problèmes sont survenus.

Cette stratégie de synchronisation bien définie permet de maintenir la cohérence des données tout en préservant les avantages d'avoir deux modèles séparés.

Fonctionnalités

1. Portail vendeur

• Page d'accueil vendeur : Interface personnalisée pour les vendeurs
• Gestion des produits : Ajout, modification et suppression de produits
• Gestion des images : Upload et gestion des images pour les produits
• Publication sur le site web : Contrôle de la visibilité des produits sur le site web

2. Processus de demande vendeur

• Formulaire de demande : Interface pour soumettre une demande pour devenir vendeur
• Workflow d'approbation : Processus de validation des demandes par les administrateurs
• Notifications : Alertes par email lors des changements d'état des demandes

3. Intégration e-commerce

• SEO : Gestion des métadonnées pour le référencement
• Catégorisation : Association des produits vendeur aux catégories du site web
• Prix et disponibilité : Gestion des informations de prix et de stock pour le site web

4. Conversion de produits vendeur en produits standard

• Fonctionnalité pour créer des produits standard (product.template) à partir des produits vendeur
• Association automatique du fournisseur au produit créé

Intégration avec les modules existants

vendor_product_management

Le module vendor_product_management fournit les fonctionnalités de base pour la gestion des produits vendeur :

• Modèle vendor.product de base
• Gestion des prix et des stocks
• Import de données vendeur

Le module st_laurent_portal_vendor étend ces fonctionnalités en ajoutant des capacités e-commerce et une meilleure intégration avec le site web.

vendor_portal_management

Le module vendor_portal_management fournit le portail de base pour les vendeurs :

• Interface de portail pour les vendeurs
• Gestion des produits via le portail
• Import de données via le portail

Le module st_laurent_portal_vendor étend ces fonctionnalités en ajoutant un processus de demande pour devenir vendeur et des fonctionnalités e-commerce avancées.

Tâches restantes

Répartition des tâches par module

Les tâches restantes ont été analysées pour déterminer lesquelles devraient être intégrées au module st_laurent_portal_vendor actuel et lesquelles devraient être développées dans des modules distincts.

Tâches à intégrer dans le module st_laurent_portal_vendor actuel

1. Améliorations du portail vendeur ✅

   • ✅ Ajouter une interface pour gérer les catégories et les tags des produits
   • ✅ Améliorer l'interface d'upload d'images avec prévisualisation et recadrage

2. Optimisations techniques

   • Améliorer les performances du portail pour gérer un grand nombre de produits
   • Optimiser le stockage et le traitement des images
   • Renforcer la sécurité des accès et des permissions

Tâches à développer dans des modules distincts

1. Module "st_laurent_vendor_analytics"

   • Ajouter des statistiques de vente et de visite pour les produits vendeur
   • Créer des rapports de vente spécifiques aux vendeurs
   • Ajouter des tableaux de bord avec des indicateurs de performance
   • Implémenter des analyses de tendances pour aider les vendeurs à optimiser leurs offres

2. Module "st_laurent_vendor_reviews"

   • Implémenter un système de notation et d'avis pour les produits vendeur
   • Intégrer un système de questions/réponses pour les produits vendeur

3. Module "st_laurent_vendor_promotions"

   • Ajouter la possibilité de créer des promotions spécifiques aux produits vendeur

4. Module "st_laurent_vendor_orders"

   • Ajouter une interface pour que les vendeurs puissent voir les commandes de leurs produits
   • Implémenter un système de notification pour les nouvelles commandes
   • Permettre aux vendeurs de gérer les expéditions de leurs produits

Justification de la modularisation

1. Cohésion fonctionnelle : Chaque module a une responsabilité claire et cohérente. Le module st_laurent_portal_vendor actuel se concentre sur la gestion des produits vendeur et leur intégration e-commerce de base.

2. Complexité : Les fonctionnalités comme les analyses, les avis, les promotions et la gestion des commandes sont suffisamment complexes pour justifier leurs propres modules.

3. Dépendances : Les modules distincts peuvent avoir leurs propres dépendances sans alourdir le module principal.

4. Maintenance : Des modules plus petits et plus ciblés sont plus faciles à maintenir et à faire évoluer.

5. Déploiement progressif : La modularisation permet un déploiement progressif des fonctionnalités, en fonction des priorités du projet.

Conclusion

Le module st_laurent_portal_vendor étend les fonctionnalités des modules vendor_portal_management et vendor_product_management en ajoutant des capacités e-commerce avancées et un processus de demande pour devenir vendeur. Il offre une solution complète pour permettre aux vendeurs de gérer leurs produits et leur présence sur le site web e-commerce.

Les tâches restantes se concentrent sur l'amélioration de l'expérience utilisateur, l'ajout de fonctionnalités e-commerce avancées, la gestion des commandes et l'optimisation des performances et de la sécurité.