Introduction
Dans Odoo, chaque type d'information métier est organisé dans un modèle. Ces modèles décrivent la structure des données et la manière dont elles sont stockent en base : commandes, stocks, partenaires ou produits — tout repose sur ces objets.
Comprendre les modèles Odoo est indispensable, que vous soyez consultant fonctionnel ou développeur. Ils forment l’armature des données, définissent les champs, les relations entre objets et la logique métier qui s’exécute lorsque l’on crée, modifie ou supprime des enregistrements.
Ici, l’attention se porte sur un modèle clé pour la gestion catalogue et les transactions commerciales : product.product. Que vous configuriez une boutique en ligne, synchronisiez un stock externe ou développiez un module sur mesure, vous croiserez ce modèle très souvent.
Qu'est-ce que le modèle product.product
Le modèle product.product correspond aux variantes concrètes qu’on vend ou achète. Ce sont les unités physiques ou logiques qui transitent dans les lignes de commande, les bons de livraison et les mouvements de stock.
Il faut distinguer product.product de product.template : le template contient les caractéristiques partagées d’une gamme, tandis que le product.product représente chaque déclinaison précise. Pour un article sans variantes, on a un variant unique. Pour un article configurable (par exemple un pull disponible en tailles et couleurs), chaque combinaison est un product.product séparé.
Le modèle est fourni par le module product et sert de référence pour la vente, l’achat, la logistique et l’e‑commerce. À chaque ajout de ligne dans un devis ou de réception en stock, vous manipulez des enregistrements product.product.
Odoo utilise l’héritage par délégation entre template et variant : beaucoup de champs sont définis sur le template et accessibles depuis les variantes. Cela permet de centraliser les données communes tout en laissant la possibilité d’overrides spécifiques par variante.
Champs essentiels du modèle
Voici les champs les plus utiles du modèle product.product. Les connaître facilite la gestion des variantes et l’intégration avec d’autres processus métiers.
name
Type : Char. Nom de la variante tel qu’il apparaît dans les listes et documents. Pour un produit simple, il reprend le nom du template ; pour une variante, il peut inclure les attributs (ex. « T‑shirt — Bleu / M »).
product_tmpl_id
Type : Many2one (product.template). Lien vers le template parent. Relation fondamentale : chaque variant appartient à un seul template. Servez‑vous de ce champ pour remonter aux données partagées ou étendre la logique commune.
default_code
Type : Char. Référence interne ou SKU. Pratique pour les recherches, les codes‑barres et les synchronisations avec des systèmes externes. Chaque variante peut avoir son propre code.
barcode
Type : Char. Code‑barres (EAN, UPC…). Utilisé pour le scan en point de vente et en entrepôt. Lorsqu’il est renseigné, il doit rester unique pour éviter les collisions lors des lectures.
create_date
Type : Datetime. Date et heure de création de l’enregistrement, gérée automatiquement par Odoo. Utile pour les audits et les rapports temporels.
write_date
Type : Datetime. Date et heure de la dernière modification. Également maintenue automatiquement, elle aide à suivre les mises à jour.
active
Type : Boolean. Indicateur d’archivage. Quand false, le produit est masqué des vues par défaut sans être supprimé — on conserve l’historique des transactions.
type
Type : Selection. Nature du produit : consommable, service ou stockable. Ce choix détermine si le produit est suivi en stock, s’il déclenche des règles MRP, ou s’il n’a pas d’impact d’inventaire.
categ_id
Type : Many2one (product.category). Catégorie commerciale du produit, utilisée pour les rapports, les règles tarifaires et la navigation du catalogue. Les catégories peuvent être hiérarchiques.
list_price
Type : Float. Prix de vente public affiché par défaut sur les devis et la boutique. Peut être remplacé par des tarifs spécifiques ou des règles de prix.
standard_price
Type : Float. Prix d’achat ou coût standard de l’article. Sert pour la valorisation des stocks et le calcul des marges. Mis à jour via les achats ou la saisie manuelle.
uom_id
Type : Many2one (uom.uom). Unité de mesure principale pour la vente et le stock (ex. unité, kg, litre). Définit comment on exprime les quantités.
uom_po_id
Type : Many2one (uom.uom). Unité d’achat. Elle peut différer de l’unité de vente (ex. achat par carton, vente à l’unité) : Odoo gère la conversion automatiquement.
description_sale
Type : Html. Description commerciale visible sur les devis, commandes et factures. Permet un contenu enrichi pour le client.
description_purchase
Type : Html. Description destinée aux achats et aux fournisseurs, utile pour préciser exigences ou conditions spécifiques.
sale_ok
Type : Boolean. Indique si le produit peut être vendu. Quand false, il est exclu des ventes et de la boutique en ligne (pratique pour les éléments internes ou réservés aux achats).
purchase_ok
Type : Boolean. Indique si le produit peut être acheté. Quand false, il n’apparaît pas dans les processus d’achat (utile pour produits fabriqués en interne).
image_1920
Type : Binary. Image haute résolution du produit. Odoo stocke plusieurs tailles (image_512, image_256…) pour l’affichage dans l’interface et la fiche produit du site.
weight
Type : Float. Poids du produit, pris en compte pour les calculs d’expédition et la logistique. L’unité dépend de la configuration de l’entreprise.
volume
Type : Float. Volume du produit, utile pour calculer la capacité d’entreposage ou les frais de transport volumétriques.
company_id
Type : Many2one (res.company). Dans un environnement multi‑sociétés, indique la société propriétaire du produit et influence la visibilité et les règles de stock.
currency_id
Type : Many2one (res.currency). Devise utilisée pour list_price et standard_price. Généralement la devise de la société, les tarifs peuvent être convertis pour d’autres devises via les pricelists.
qty_available
Type : Float. Quantité en stock disponible. Champ calculé à partir des quants, en lecture seule. Sert aux vérifications de disponibilité pour les produits stockables.
virtual_available
Type : Float. Prévision de disponibilité (stock actuel + arrivages − sorties prévues). Champ calculé utile pour la planification et la réapprovisionnement.
product_template_attribute_value_ids
Type : Many2many. Relations vers les valeurs d’attribut qui décrivent la variante (ex. Couleur=Bleu, Taille=M). Sert au configurateur de produits et aux filtres.
sequence
Type : Integer. Ordre d’affichage. Utilisé pour trier les variantes dans les listes et interfaces produits (les valeurs basses s’affichent en premier).
display_name
Type : Char. Nom calculé affiché dans les sélecteurs, qui concatène le nom et les attributs de la variante. Champ en lecture seule mais largement utilisé dans les recherches.
responsible_id
Type : Many2one (res.users). Personne responsable du produit (pour les réappros, les règles commerciales ou le suivi interne). Champ facultatif.
Utilisation du modèle dans les processus métier
1. Ventes et devis
Lors de la création d’un devis, le commercial choisit une variante (product.product). Le prix par défaut, la description commerciale et l’unité se reportent automatiquement sur la ligne. Les listes de prix peuvent modifier le tarif, et seuls les produits avec sale_ok activé sont proposés.
2. Achats et fournisseurs
Sur les commandes fournisseurs, on référence une variante. Le coût d’achat peut mettre à jour le prix standard. Les variantes réservées aux achats (purchase_ok) sont celles disponibles pour les bons de commande, et l’unité d’achat détermine la façon dont on commande (ex. par carton).
3. Inventaire et logistique
Les mouvements, pickings et quants sont attachés à des variants. Les champs qty_available et virtual_available pilotent la disponibilité. Seuls les produits stockables sont suivis en quantité. Le scan par code‑barres accélère la localisation et la validation des opérations.
4. E‑commerce et site web
La boutique en ligne expose les variants comme options sélectionnables (taille, couleur). Images, descriptions et prix proviennent du modèle. La visibilité dépend du drapeau sale_ok.
5. Fabrication et MRP
Les nomenclatures (BOM) utilisent les variants pour composants et produits finis. Le type de produit indique s’il doit être géré en stock ou consommé directement, et les niveaux de stock alimentent la planification de production.
Comment les développeurs étendent ce modèle
Les développeurs disposent de plusieurs leviers pour étendre product.product, l’héritage des modèles restant la méthode courante.
Héritage de modèle
Déclarez _inherit = 'product.product' dans votre module pour ajouter des champs, redéfinir des méthodes ou ajouter des contraintes. Cette approche garde vos changements isolés dans un module distinct, facilitant les montées de version. Si une donnée concerne toute la gamme, préférez product.template ; si elle est propre à la variante, étendez product.product.
Ajout de champs
Ajoutez des champs adaptés au type de donnée (Char, Many2one, Boolean, Integer, Text, Selection). Réfléchissez si le champ doit être partagé (template) ou spécifique (variant). Les informations variant‑spécifiques comme un SKU alternatif ou un code interne d’entrepôt doivent résider sur product.product.
Extensions Python
Surchagez create, write ou unlink pour injecter de la logique métier, en faisant appel à super() pour conserver le comportement natif. Soyez vigilant avec les champs calculés et leurs dépendances : le modèle produit interagit avec de nombreux calculs provenant des modules stock et vente.
Odoo Studio
Odoo Studio permet d’ajouter des champs sans écrire de code, idéal pour des ajustements rapides. Pour des règles complexes ou un suivi à long terme, préférez un module personnalisé. L’API d’Odoo expose product.product via XML‑RPC/JSON‑RPC pour les intégrations externes.
Bonnes pratiques
- Utilisez default_code ou barcode comme points d’ancrage pour faire le mapping avec des systèmes externes. Maintenez leur unicité et cohérence pour éviter les erreurs d’appairage.
- Attribuez correctement le champ type à chaque produit : consommable, stockable ou service. Ce choix conditionne les workflows applicables et le traitement par les différents modules.
- Pour les échanges via API, référencez product.product pour les lignes d’ordre et les transactions. Employez product.template pour les opérations qui concernent le catalogue dans son ensemble.
- Pour les champs personnalisés, préfixez‑les par x_ ou par le nom du module pour réduire le risque de conflit avec de futures versions d’Odoo.
- Quand un champ s’applique à toutes les variantes (marque, famille, garantie), placez‑le sur product.template. Pour des données propres à une déclinaison (code barre propre à la variante), utilisez product.product.
Erreurs fréquentes
- N’utilisez pas product.template pour logiques qui doivent s’appliquer à un seul variant. Préférez product.product lorsque le comportement doit être géré au niveau de la variante.
- Évitez de créer manuellement des variants isolés sans passer par le configurateur lorsque le produit est multi‑attributs : cela peut créer des incohérences. Pour des produits à variantes, créez‑les via la configuration produit afin que les relations attribut/valeur soient correctement établies.
- Ne négligez pas les flags sale_ok et purchase_ok : si oubliés, vos produits ne seront pas visibles dans les flux de vente ou d’achat selon la configuration par défaut.
- Ne surchargez pas les méthodes coeur sans appeler super() : vous risquez d’interrompre le comportement attendu par d’autres modules ou de compliquer les montées de version.
- Attention aux domaines et filtres : employer product.product alors que le critère porte sur une propriété du template (ex. catégorie) peut conduire à des recherches inefficaces ou erronées.
Conclusion
Le modèle product.product est au cœur de l’architecture produit d’Odoo. Il matérialise ce qui est vendu et acheté. Bien connaître ses champs et sa relation avec product.template vous aidera à configurer, personnaliser et intégrer Odoo correctement.
Que vous cartographiez un catalogue en tant que consultant ou développiez des modules sur mesure, maîtriser product.product vous fera gagner du temps et évitera des erreurs coûteuses.
Besoin d’aide pour votre implémentation Odoo ?
Dasolo accompagne les entreprises dans la mise en œuvre, la personnalisation et l’optimisation d’Odoo. Nous sommes spécialisés en intégrations API et développement Odoo, avec une forte expertise sur l’architecture des données et des modèles comme product.product.
Si vous avez besoin d’aide pour votre implémentation Odoo, vos modules personnalisés ou vos intégrations, nous pouvons vous accompagner. Demandez une démo pour discuter de votre projet.