Introduction
Dans Odoo, les « modèles » définissent la façon dont l'information est structurée et stockée. Toute donnée métier — commande client, facture, fiche produit — repose sur une définition de modèle pour être conservée de manière cohérente dans la base.
S'approprier les modèles Odoo est indispensable aussi bien pour les consultants fonctionnels que pour les développeurs. Ce sont eux qui encadrent les champs, les liens entre enregistrements et la logique métier : une même logique de conception s'applique à tous les modèles Odoo.
Ici, nous nous intéressons au modèle central pour la gestion des produits : product.template. Que vous configuriez un catalogue, développiez un module sur mesure ou synchronisiez des stocks avec un ERP externe, vous rencontrerez systématiquement ce modèle.
Qu'est-ce que le modèle product.template
Le modèle product.template sert à rassembler une famille de produits partageant des caractéristiques communes — par exemple un T-shirt disponible en plusieurs tailles ou couleurs. Plutôt que de créer une fiche distincte pour chaque variante, on crée un « gabarit » qui contient ce qui est partagé, et des variantes pour ce qui change.
product.template est référencé par de nombreux modules : Ventes, Achats, Stocks, Site web et Fabrication. La création d’un article dans le catalogue génère un enregistrement template ; les commandes et mouvements s’appuient ensuite sur les variantes issues de ce template.
Le modèle est déclaré dans le module product et d’autres modules viennent y greffer leurs besoins via l’héritage de modèle. Le module Sale ajoute la tarification et la facturation, Purchase gère les fournisseurs, Inventory suit les stocks — chacun complète la structure sans la dupliquer.
Il est crucial de distinguer product.template de product.product. Le template contient les informations communes à une famille de produits, tandis que product.product représente les variantes et porte les données spécifiques comme le SKU ou le code-barres.
Champs clés du modèle
Voici les champs essentiels du modèle product.template. Les connaître vous permet de manipuler correctement les fiches produits et d’anticiper leurs impacts sur le reste du système.
1. name
Type : Char. Nom commercial du produit. C’est le libellé principal affiché dans les listes, devis et recherches ; il sert d’identifiant lisible pour les utilisateurs.
2. create_date
Type : Datetime. Date et heure de création de l’enregistrement. Gestionnée automatiquement par Odoo, utile pour les rapports et la traçabilité.
3. write_date
Type : Datetime. Date et heure de la dernière modification. Permet de savoir quand une fiche a été mise à jour.
4. active
Type : Boolean. Indicateur d’archivage. Lorsqu’il est faux, l’enregistrement est masqué sans être supprimé physiquement.
5. sequence
Type : Integer. Sert à ordonner l’affichage des produits dans les listes et sélecteurs ; les valeurs faibles remontent en priorité.
6. type
Type : Selection. Catégorie fonctionnelle : consommable, service ou stockable. Détermine si l’article est suivi en stock ou non.
7. categ_id
Type : Many2one (product.category). Catégorie produit : impacte le routage, les règles par défaut et le reporting. Les catégories peuvent être hiérarchiques.
8. list_price
Type : Float. Prix de vente par défaut utilisé sur les devis ; peut être ajusté par les grilles tarifaires ou par variante.
9. standard_price
Type : Float. Prix d’achat ou coût standard ; sert au calcul des marges et à l’évaluation des stocks.
10. currency_id
Type : Many2one (res.currency). Devise associée aux prix (list_price, standard_price), généralement liée à la société.
11. uom_id
Type : Many2one (uom.uom). Unité de vente (ex. unité, kg, litre) — définit l’unité de mesure utilisée côté ventes.
12. uom_po_id
Type : Many2one (uom.uom). Unité d’achat ; peut différer de l’unité de vente et nécessite conversion.
13. default_code
Type : Char. Référence interne ou code article (SKU). Très utile pour synchroniser avec des systèmes externes.
14. barcode
Type : Char. Code-barres pour les scans en entrepôt ou en point de vente. Les variantes portent souvent leur propre barcode.
15. description
Type : Char. Description interne visible seulement des collaborateurs ; pour notes et instructions internes.
16. description_sale
Type : Text. Description destinée aux clients ; apparaît sur devis, facture et fiche produit web, peut contenir du HTML.
17. description_purchase
Type : Text. Description à l’usage des acheteurs, affichée sur les commandes fournisseurs.
18. sale_ok
Type : Boolean. Autorise ou non la vente d’un produit. Si false, il n’apparaît pas dans les formulaires de vente.
19. purchase_ok
Type : Boolean. Autorise l’achat. Si false, il est exclu des formulaires d’achat.
20. weight
Type : Float. Poids de l’article, utile pour le calcul des frais d’expédition selon les paramètres de l’entreprise.
21. volume
Type : Float. Volume du produit, pertinent pour la planification d’espace en entrepôt.
22. product_variant_ids
Type : One2many (product.product). Liste des variantes affiliées au template ; chaque variante reprend les données communes et y ajoute ses spécificités.
23. product_variant_count
Type : Integer. Nombre de variantes calculé depuis product_variant_ids — pratique pour l’affichage et le filtrage.
24. image_1920
Type : Binary. Image principale du produit. Odoo stocke plusieurs résolutions pour l’affichage sur le site et dans les fiches.
25. responsible_id
Type : Many2one (res.users). Utilisateur responsable du produit, pour l’assignation d’activités et la gestion produit.
26. company_id
Type : Many2one (res.company). Société propriétaire du produit en configuration multi-sociétés.
27. tax_ids
Type : Many2many (account.tax). Taxes applicables côté client pour la facturation des ventes.
28. supplier_tax_id
Type : Many2many (account.tax). Taxes fournisseurs à appliquer lors des achats.
29. attribute_line_ids
Type : One2many. Lignes d’attributs (ex. Taille, Couleur) qui génèrent les variantes du template.
30. route_ids
Type : Many2many (stock.route). Routes logistiques : achat, fabrication, make-to-order, etc., qui pilotent les flux de stock.
31. property_stock_production
Type : Many2one (stock.location). Emplacement de production pour les articles fabriqués.
32. property_stock_inventory
Type : Many2one (stock.location). Emplacement utilisé pour les inventaires et ajustements.
33. property_valuation
Type : Selection. Méthode d’évaluation des stocks : automatique ou manuelle ; influence la comptabilité de stock.
34. property_cost_method
Type : Selection. Méthode de coût : Standard ou FIFO ; détermine la valorisation des sorties.
35. property_account_income_id
Type : Many2one (account.account). Compte de produit pour les ventes, utilisé lors de la facturation.
36. property_account_expense_id
Type : Many2one (account.account). Compte de charge pour les achats, utilisé sur les factures fournisseurs.
37. invoice_policy
Type : Selection. Politique de facturation : facturer à la commande ou à la livraison — impacte la reconnaissance du chiffre d’affaires.
38. expense_policy
Type : Selection. Politique de comptabilisation des coûts : à la commande ou à la livraison.
39. service_type
Type : Selection. Pour les services : mode de gestion (manuel, feuille de temps, jalons) et facturation associée.
40. optional_product_ids
Type : Many2many (product.template). Produits optionnels proposés en upsell lors de la création d’un devis.
Comment ce modèle intervient dans les processus métiers
1. Ventes et devis
Lors de la création d’un devis, le commercial choisit un produit depuis le catalogue. Le template apporte les informations communes ; si des attributs existent, il sélectionnera ensuite la variante appropriée (taille, couleur, etc.).
2. Commerce en ligne
Sur le site e‑commerce, le client navigue par fiches produits (templates) et choisit sa variante sur la page produit ; images et descriptions communes sont gérées au niveau du template.
3. Achats et fournisseurs
Les commandes fournisseurs et factures se réfèrent aux produits ; le champ purchase_ok détermine si le produit est disponible pour l’achat, et uom_po_id/supplier_tax_id gouvernent le comportement d’achat.
4. Stocks et fabrication
Les mouvements de stock et les ordres de fabrication pointent vers les variantes. Le template définit les routes, la méthode d’évaluation et le calcul des coûts, mais le suivi des quantités se fait par variante.
5. Facturation
Les lignes de facture reprennent les règles fiscales et les comptes définis sur le produit. La politique d’invoicing choisie influe sur le moment où le chiffre d’affaires est enregistré.
Comment les développeurs étendent ce modèle
Les développeurs disposent de plusieurs mécanismes pour étendre product.template, l’héritage de modèle étant le principal outil.
Héritage de modèle
Utilisez _inherit = 'product.template' pour ajouter des champs ou modifier le comportement. L’héritage permet d’enrichir le modèle dans un module séparé, évitant la modification directe du code core et facilitant les mises à jour.
Ajout de champs
Déclarez de nouveaux champs dans votre modèle hérité en choisissant le type approprié (Char, Many2one, Boolean, Integer, Text, Selection). Pensez aux champs dépendant de la société en environnement multi-company.
Extensions Python
Surchagez create, write ou unlink pour injecter de la logique métier, en appelant super() pour préserver le comportement d’origine. Faites attention aux champs calculés et à leurs dépendances pour éviter des incohérences.
Odoo Studio
Odoo Studio permet d’ajouter facilement des champs sans coder — pratique pour des ajustements rapides. Pour des besoins complexes ou pérennes, préférez un module personnalisé versionnable.
Bonnes pratiques
- Placez correctement les informations : ce qui est commun va sur le template, ce qui varie par référence (code-barres, SKU) doit aller sur product.product.
- Attribuez des catégories (categ_id) pertinentes pour bénéficier des routes par défaut et d’un reporting fiable.
- Utilisez default_code comme référence d’intégration : c’est la meilleure pratique pour le mapping avec d’autres systèmes.
- Pour les intégrations API, passez par XML-RPC ou JSON-RPC : product.template est exposé et il faut veiller à la cohérence des identifiants entre systèmes.
- Pour les champs personnalisés, préfixez-les (x_ ou préfixe module) afin d’éviter des collisions avec de futures versions d’Odoo.
Erreurs fréquentes
- Créer des templates en double au lieu d’utiliser des variantes. Si les différences se limitent à taille/couleur, gérez-les via attribute_line_ids plutôt que de multiplier les templates.
- Confondre product.template et product.product. Les données spécifiques aux variantes (SKU, code-barres) doivent être stockées sur product.product.
- Oublier de positionner sale_ok ou purchase_ok. Un produit non autorisé à la vente ou à l’achat n’apparaîtra pas dans les formulaires concernés.
- Surcharger des méthodes core sans appeler super(). Cela peut casser d’autres modules ou compliquer les upgrades.
- Ajouter des champs requis sans valeur par défaut. Les enregistrements existants risquent d’être invalidés lors d’un déploiement.
Conclusion
Le modèle product.template est au cœur du traitement produit dans Odoo : il centralise les définitions et les attributs partagés. Maîtriser ses champs et la façon dont les modules l’étendent est indispensable pour configurer, personnaliser et intégrer Odoo correctement.
Que vous cartographiez un catalogue en tant que consultant fonctionnel ou développiez des modules sur mesure, une bonne compréhension de product.template évite beaucoup de tâtonnements et d’erreurs.
Commencer avec Dasolo
Dasolo accompagne les entreprises pour implémenter, personnaliser et optimiser Odoo. Nous sommes spécialisés en intégration API et développement Odoo, avec une forte expérience des modèles comme product.template.
Si vous rencontrez des défis sur votre projet Odoo — modules personnalisés, intégrations ou optimisation — notre équipe peut vous accompagner. Planifiez une démonstration pour discuter de votre projet.