Le catalogue est le référentiel le plus partagé d'un ERP : les ventes, les achats, la production et la comptabilité y puisent. C'est aussi celui où les règles sont les plus implicites — une codification « qu'on connaît », un coût que « tout le monde peut voir ».
Dix-neuf modules communautaires rendent ces règles explicites : codification contrôlée, cycle de vie, droits sur le coût, approbation d'une nouvelle fiche.
Résumé
Quatre modules traitent la codification : référence interne rendue obligatoire, rendue unique dans toute la base, attribuée automatiquement par une séquence, et code-barres obligatoire avec pré-remplissage depuis la référence. S'y ajoutent les prix multiples nommés — prix standard, promo, grossiste — sur lesquels des règles de tarif peuvent s'appuyer.
Cinq traitent le cycle de vie : un champ d'état du produit (en développement, vendable, fin de vie, obsolète) avec ses modèles, la possibilité d'activer ou désactiver le produit selon son état, l'accès à cet état depuis Ventes et depuis Inventaire, et un statut calculé automatiquement à partir de trois dates saisies sur la fiche.
Le reste encadre : un profil produit qui applique un jeu de valeurs en un clic, la société préremplie à la création, une permission d'édition des produits sans laquelle un utilisateur ne peut rien modifier, la protection du coût par deux groupes — avec deux modules de colle pour le stock et la caisse —, l'approbation par paliers d'une nouvelle fiche, et l'application Produits qui manque à la version Community.
L'essentiel
- La référence interne obligatoire et unique — Odoo ne fait qu'avertir, il ne bloque pas.
- Une séquence automatique pour attribuer la référence, plutôt que de la laisser à l'inspiration.
- Un état de cycle de vie du produit, visible depuis Ventes et depuis Inventaire.
- Un statut calculé par dates : nouveau, discontinué, en fin de vie.
- Le coût protégé par deux groupes d'accès dédiés, caisse comprise.
- Une permission d'édition des produits distincte des autres droits.
- L'approbation d'une nouvelle fiche par un ou plusieurs valideurs.
- L'application Produits ajoutée — elle n'existe pas en Community.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Codification | product_code_mandatory, product_code_unique, product_sequence, product_barcode_required, product_multi_price | 5 |
| Cycle de vie | product_state, product_state_active, product_state_sale, product_state_stock_base, product_status | 5 |
| Droits et contrôle | product_readonly_security, product_cost_security, product_cost_security_stock_account, pos_product_cost_security, product_tier_validation | 5 |
| Confort et création | product_usability, product_profile, product_company_default, product_restricted_type | 4 |
Les menus ajoutés : l'application Produits avec sa configuration, les profils de produit et les états de l'article côté Ventes comme côté Inventaire.
La codification : rendre explicite ce qui était implicite
Odoo avertit quand une référence interne est en double, il ne bloque pas. Sur une base alimentée par plusieurs personnes pendant deux ans, les doublons s'accumulent — et c'est au moment d'un inventaire ou d'un import que leur coût apparaît.
| Module | Ce qu'il impose |
|---|---|
product_code_mandatory | La référence interne devient obligatoire |
product_code_unique | Elle devient unique dans toute la base — contrainte bloquante |
product_sequence | Elle est attribuée automatiquement par une séquence |
product_barcode_required | Le code-barres devient obligatoire, avec pré-remplissage depuis la référence |
Les trois premiers se combinent naturellement : une séquence qui attribue, une contrainte qui vérifie, une obligation qui empêche d'enregistrer sans. Le résultat est un catalogue dont chaque article est identifiable — ce qui conditionne tous les échanges de données, de l'EDI à l'import de tarifs.
product_multi_price ajoute une autre dimension : plusieurs prix nommés par produit — « prix standard », « prix promo », « prix grossiste » — sur lesquels des règles de liste de prix peuvent ensuite s'appuyer. C'est une alternative aux listes de prix multiples quand la différence est structurelle plutôt que contractuelle.
Les règles de tarif elles-mêmes sont traitées dans remises, prix et tarifs.
Le cycle de vie d'un article
Un catalogue vivant contient des produits en cours de référencement, des produits vendables, des produits en fin de vie qu'on écoule, et des obsolètes qu'on garde pour l'historique. Odoo ne connaît que « actif » et « archivé ».
product_stateintroduit un état sur la fiche produit — en développement, normal, fin de vie, obsolète — avec un modèle d'états configurable.product_state_activepermet de définir, sur l'état lui-même, s'il active ou désactive le produit. Passer un article en « obsolète » l'archive automatiquement.product_state_saleetproduct_state_stock_baserendent cet état accessible depuis Ventes et depuis Inventaire — deux petits modules sans logique propre, mais sans lesquels l'état reste invisible là où il sert.product_statuscalcule un statut à partir de trois dates saisies sur la fiche : nouveau jusqu'à, discontinué à partir de, fin de vie.
La différence entre l'état et le statut mérite d'être posée : l'état est une décision (« nous arrêtons ce produit »), le statut est un calcul (« nous sommes après la date d'arrêt »). Les deux coexistent, et le second évite d'avoir à passer manuellement cinq cents articles en fin de vie.
product_tier_validation ferme le dispositif par l'amont : une approbation par paliers sur les fiches produit, pour qu'un nouvel article soit validé avant d'être vendable. Dans une entreprise où le référencement engage la logistique et la comptabilité analytique, c'est un contrôle légitime.
Qui peut voir le coût, qui peut modifier une fiche
Le coût
product_cost_security protège le champ Coût par deux groupes d'accès distincts, réunis dans une catégorie de droits dédiée. Deux modules de colle étendent cette protection :
product_cost_security_stock_accountpour la valorisation comptable du stock, où le coût réapparaîtrait sinon ;pos_product_cost_securitypour le point de vente, qui charge les données produit côté caisse.
Ces deux colles disent l'essentiel : protéger un champ ne suffit pas, il faut couvrir tous les endroits où il transite. Un coût masqué sur la fiche produit mais visible dans l'écran de caisse n'est pas protégé.
Le besoin est courant : les commerciaux voient les prix de vente, pas les coûts ; les vendeurs en magasin encore moins. Sans ce module, le coût d'achat est visible de tout utilisateur ayant accès au produit.
L'édition
product_readonly_security crée une permission Édition des produits sans laquelle un utilisateur ne peut ni créer, ni modifier, ni supprimer un produit — quels que soient ses autres droits.
C'est le pendant catalogue de ce que nous avons vu côté ventes : beaucoup d'utilisateurs doivent consulter le catalogue sans pouvoir le modifier, et Odoo lie trop souvent lecture et écriture.
La gestion fine des droits est traitée dans sécuriser les accès Odoo.
Créer un produit plus vite, et le retrouver
| Module | Ce qu'il apporte |
|---|---|
product_usability | L'application Produits avec ses menus : produits, catégories, unités de mesure, étiquettes — absente de la version Community |
product_profile | Un profil produit : un jeu de valeurs préconfigurées appliqué en un clic à la fiche |
product_company_default | La société préremplie à la création, au lieu d'un champ vide qui rend le produit partagé |
product_restricted_type | Une restriction des types de produit sélectionnables (module peu documenté dans le relevé) |
Le premier appartient à la famille des modules qui restaurent ce que l'éditeur n'a pas mis en Community : sans lui, gérer les catégories ou les unités de mesure suppose de passer par les menus d'une autre application.
Le deuxième change la façon de créer un catalogue : au lieu de régler quinze champs sur chaque nouvelle fiche — type, politique de facturation, route, catégorie, unité —, on applique un profil et tout est posé. Sur un catalogue de plusieurs milliers d'articles, c'est la différence entre une base homogène et une base où chaque article a été paramétré à sa façon.
Le troisième corrige un piège discret : en multi-société, une fiche produit dont la société est vide est partagée par toutes les sociétés. C'est parfois voulu — et le plus souvent, c'est un oubli dont on découvre l'effet lors d'une consolidation.
Limites connues
- Rendre la référence unique sur une base existante échoue tant que les doublons n'ont pas été résolus : c'est un chantier de nettoyage préalable.
- La séquence automatique et une codification parlante s'opposent : il faut choisir entre une référence signifiante et une référence générée.
- La protection du coût exige ses modules de colle : sans eux, le coût réapparaît dans la valorisation ou dans la caisse.
- Les états de produit n'ont de valeur qu'avec une règle : qui décide du passage en fin de vie, et quand.
product_restricted_typeest peu documenté dans le relevé : comportement à vérifier sur le dépôt.- L'approbation d'une fiche produit ralentit le référencement : à calibrer selon le rythme réel de création d'articles.
Identité technique
Les dix-neuf modules viennent du dépôt OCA product-attribute, branche 18.0 — 105 modules au total —, en licence AGPL-3 sauf product_barcode_required (LGPL-3). Deux dépendent d'applications tierces (point de vente, valorisation de stock) et l'approbation s'appuie sur le socle générique du dépôt server-ux.
Les familles voisines du même dépôt seront traitées dans les fiches suivantes : conditionnements et unités, attributs et variantes, listes de prix, classification ABC.
Questions fréquentes
Odoo empêche-t-il les références produit en double ?
Non : il avertit sans bloquer. product_code_unique ajoute une contrainte bloquante sur toute la base, product_code_mandatory rend la référence obligatoire, et product_sequence l'attribue automatiquement. Sur une base existante, la contrainte d'unicité échoue tant que les doublons ne sont pas résolus : prévoyez le nettoyage.
Comment gérer la fin de vie d'un produit ?
product_state ajoute un état — en développement, normal, fin de vie, obsolète — et product_state_active permet de décider, sur l'état lui-même, s'il archive le produit. En complément, product_status calcule un statut à partir de trois dates, ce qui évite de passer manuellement des centaines d'articles en fin de vie.
Peut-on masquer le coût d'achat aux commerciaux ?
Oui, avec product_cost_security, qui protège le champ Coût par deux groupes d'accès dédiés. Installez aussi les deux modules de colle — valorisation de stock et point de vente — sans lesquels le coût réapparaît dans ces écrans. Protéger un champ suppose de couvrir tous les endroits où il transite.
Pourquoi la version Community n'a-t-elle pas de menu Produits ?
Parce que le module de base ne fournit pas d'application dédiée : on accède aux produits depuis Ventes, Achats ou Inventaire. product_usability ajoute une application Produits avec ses menus — produits, catégories, unités de mesure, étiquettes. C'est la même famille de modules que account_usability côté comptabilité.
Comment créer des fiches produit homogènes ?
Avec product_profile : un profil porte un jeu de valeurs préconfigurées — type, politique de facturation, route, catégorie, unité — appliqué en un clic à la fiche. Sur un catalogue de plusieurs milliers d'articles, c'est la différence entre une base homogène et une base paramétrée article par article.
Se faire accompagner
Le catalogue est le référentiel que toutes les équipes utilisent et que personne ne possède. Les règles y sont implicites jusqu'au jour où un import échoue sur des doublons, où un commercial cite un coût d'achat à un client, ou où un article archivé réapparaît dans une commande.
Nous commençons donc par trois décisions : qui crée un produit, selon quelle codification, et qui voit le coût. Le paramétrage en découle, et la reprise des doublons se chiffre avant d'activer la contrainte d'unicité. Voir les prestations d'Atalios Consulting, notre méthode ou demander un rappel.
Pour aller plus loin
- Remises, prix et tarifs
- Sécuriser les accès Odoo
- account_usability : les menus manquants de la Community
En résumé
La référence enfin obligatoire et unique, un cycle de vie explicite plutôt qu'un archivage binaire, le coût protégé partout où il transite — caisse comprise —, et l'application Produits que la version Community n'a pas. Dix-neuf modules pour rendre explicites les règles du référentiel le plus partagé. Parlons de votre catalogue.
