Introduction
Peu souvent évoqué dans la documentation, le « champ dépendant de société » est un petit réglage du modèle de données d’Odoo qui change la donne dès qu’on gère plusieurs entités juridiques dans la même base.
Dans une configuration standard, une colonne d’enregistrement contient une seule valeur visible par tous les utilisateurs. Mais quand plusieurs sociétés partagent un catalogue—et que chacune a besoin d’un code interne, d’un compte comptable par défaut ou d’un fournisseur préféré différent—un champ unique et global ne suffit pas.
C’est précisément ce que permet l’attribut company_dependent. Que vous développiez des modules Odoo, fassiez des personnalisations ou configuriez une instance multi-sociétés, maîtriser ce mécanisme évite beaucoup de bricolages et de duplications de données.
Qu’est-ce qu’un champ dépendant de société dans Odoo
Un champ dépendant de société conserve une valeur distincte par société pour un même enregistrement. Ainsi, un utilisateur rattaché à la Société A verra la valeur A, tandis qu’un utilisateur de la Société B verra la valeur B pour ce même champ.
Pour l’utilisateur final, rien ne change dans l’interface : le champ se présente comme un champ standard. Toute la logique est prise en charge discrètement par l’ORM d’Odoo.
Apparence dans l’interface
Dans l’interface Odoo, rien n’indique visuellement qu’un champ est dépendant d’une société — c’est volontaire. L’objectif est que le comportement soit transparent : l’utilisateur interagit normalement sans s’occuper de la logique multi-sociétés sous-jacente.
Du côté développeur, l’attribut peut s’appliquer à de nombreux types de champs (Char, Boolean, Integer, Float, Many2one, etc.). C’est l’ajout de company_dependent=True dans la définition qui active cette fonctionnalité au niveau de l’ORM.
Dans Odoo Studio, certains champs dépendants de société standards (par exemple des champs liés aux comptes sur les produits) sont déjà disponibles. On peut créer des champs personnalisés dépendants de société, mais l’interface Studio ne gère pas toujours cet attribut de façon exhaustive selon les versions.
Comment fonctionne ce champ
Sous le capot, le stockage et le comportement diffèrent nettement d’un champ classique. Comprendre ce mécanisme évite des surprises lors du développement, des exports ou du debug.
Stockage dans ir.property
Jusqu’à Odoo 16 inclus, les valeurs des champs dépendants de société ne sont pas écrites dans la table du modèle lui‑même : elles sont conservées dans une table système dédiée, ir.property.
Chaque enregistrement de ir.property fait le lien entre :
- un enregistrement précis (par exemple un produit d’ID 42),
- un champ précis (par exemple property_account_income_id),
- une société ciblée,
- et la valeur effective pour cette combinaison.
C’est pour ça que la valeur paraît transparente : l’ORM se charge de lire et d’écrire automatiquement dans ir.property selon la société active dans le contexte.
Évolutions à partir d’Odoo 17
À partir d’Odoo 17, le modèle de stockage a été revu : les valeurs dépendantes de société peuvent désormais être rangées directement dans la table du modèle, via une colonne jsonb contenant un dictionnaire par société. Résultat : des performances en lecture/écriture bien meilleures et des requêtes simplifiées.
L’API et l’expérience développeur restent identiques, mais les traitements deviennent plus rapides et plus adaptés aux volumes importants.
Valeurs par défaut
Les champs dépendants de société acceptent des valeurs par défaut spécifiques à chaque société. Lorsqu’aucune valeur n’est définie pour une société, le champ revient à la valeur par défaut déclarée — soit via ir.property sur Odoo ≤16, soit directement dans la définition/modèle sur Odoo ≥17.
Interaction avec l’ORM
Dans l’ORM Odoo, l’accès à un champ dépendant respecte toujours la société active dans l’environnement (self.env.company). Concrètement :
- la lecture renvoie la valeur pour la société en cours,
- l’écriture met à jour uniquement la valeur de la société active,
- et l’on peut cibler une société spécifique avec record.with_company(company) pour lire/écrire ses valeurs.
Cas d’usage métier
Le champ dépendant de société n’est pas un gadget technique : il répond à des besoins concrets sur des environnements multi-entités. Voici plusieurs situations fréquentes où il est indispensable.
1. Comptabilité : comptes produit par société
C’est l’exemple le plus répandu en standard. Les champs property_account_income_id et property_account_expense_id sur les produits sont dépendants de la société.
Concrètement : deux sociétés vendent le même article mais possèdent des plans comptables différents. Plutôt que de dupliquer le produit, chaque société définit ses propres comptes sur le même enregistrement produit.
2. Ventes et CRM : listes de prix par société
Dans un groupe où plusieurs entités commerciales coexistent, chaque société peut appliquer une stratégie tarifaire différente. Un champ dépendant pour la liste de prix permet qu’un même client partagé ait des prix par défaut différents selon la société qui gère la vente.
Cela centralise les données CRM tout en laissant chaque entité appliquer ses règles commerciales.
3. Stock : méthode d’évaluation par société
Pour des groupes opérant dans plusieurs pays, un produit peut être évalué en FIFO pour une entité et en coût moyen pour une autre. Déclarer la méthode d’évaluation comme dépendante de la société évite de multiplier les fiches produits.
4. Fabrication : fournisseur par défaut par société
Lorsque le fournisseur habituel varie selon l’entité qui achète, un champ Many2one dépendant de la société pointant vers res.partner conserve le fournisseur préféré pour chaque société sans conflit.
5. Champs règlementaires spécifiques par société
Des groupes actifs dans plusieurs juridictions doivent parfois stocker des références réglementaires distinctes (codes douaniers, classifications fiscales, etc.). Un simple Char dépendant de société est une solution propre et légère pour gérer ces différences.
Créer ou personnaliser le champ
Créer un champ dépendant de société peut se faire via Odoo Studio ou directement en Python dans un module personnalisé :
Utiliser Odoo Studio
Studio permet d’ajouter des champs sans coder, mais il n’expose pas toujours l’option company_dependent dans toutes les versions. Sur Odoo 16/17, l’option peut apparaître pour certains types de champs sur les modèles standards.
Pour un contrôle total, le développement technique reste la méthode la plus fiable : Studio convient pour des cas simples mais atteint vite ses limites pour des personnalisations avancées.
Approche technique : champs Python
Dans un module personnalisé, déclarer un champ dépendant de société est simple et suit la pratique courante en développement Odoo.
Exemple typique en module :
Il suffit d’ajouter company_dependent=True lors de la déclaration du champ ; l’ORM s’occupe du reste automatiquement.
Définir des valeurs par défaut par société
Sur Odoo 16 et versions antérieures, on peut fixer une valeur par défaut au niveau société via ir.property — utile pour donner un comportement prédictible sans remplir chaque fiche individuellement :
Un appel à self.env['ir.property']._set_default(...) permet de définir la valeur par défaut pour une société donnée.
Sur Odoo 17 et plus, les valeurs par défaut sont stockées différemment et accessibles directement via la définition du champ ou le modèle.
Champs Studio et limites
Pour les champs créés en Studio, rappelez-vous que le préfixe x_ est requis pour les champs personnalisés. Le paramètre company_dependent peut ne pas être visible dans l’interface Studio, mais il reste accessible depuis le menu technique lorsque le mode développeur est activé.
Bonnes pratiques
Voici quelques habitudes à prendre pour travailler sereinement avec ces champs.
1. N’utilisez le champ dépendant que si la valeur doit vraiment varier par société
Ce type de champ ajoute de la complexité. Si une valeur est identique pour toutes les sociétés, préférez un champ standard. Réservez company_dependent=True aux cas où la variation par entité est réellement nécessaire.
2. Testez systématiquement en environnement multi-sociétés
Lors du développement ou des tests, travaillez avec au moins deux sociétés actives. Des problèmes passent souvent inaperçus en mono-société et n’apparaissent qu’en production multi-entités.
3. Utilisez with_company() pour les opérations inter-sociétés
Si vous devez lire ou écrire la valeur d’une autre société, utilisez record.with_company(target_company). Évitez de modifier manuellement self.env.company sans remettre l’environnement initial ensuite.
4. Soyez vigilant lors des exports/imports
Lors d’un export, les valeurs refléteront la société de l’utilisateur qui exporte. Réimporter sous une autre société écrira pour cette société : ce comportement est souvent souhaité, mais il doit être explicité dans vos workflows de migration ou d’import.
5. Documentez quels champs sont dépendants de société
Les utilisateurs ignorent souvent que certains champs varient selon la société. Une note dans la documentation interne ou les supports d’onboarding évite beaucoup d’interrogations quand un utilisateur change de société et voit des valeurs différentes.
6. Préférez Many2one aux champs texte pour les données structurées
Quand la valeur par société doit référencer un autre enregistrement (compte, liste de prix, partenaire), utilisez un Many2one dépendant plutôt qu’un Char. Cela conserve l’intégrité des données et simplifie les rapports.
Pièges courants
Même des développeurs Odoo chevronnés se heurtent aux écueils des champs dépendants de société. Voici les pièges les plus fréquents à anticiper.
Piège 1 : oublier le contexte société dans les actions automatiques
Les actions planifiées ou serveurs s’exécutent parfois avec la première société en base comme contexte par défaut. Si elles manipulent des champs dépendants, vérifiez explicitement la société utilisée et employez with_company() pour éviter des écritures sur la mauvaise entité.
Piège 2 : confondre avec un champ calculé
Un champ dépendant n’est pas un champ computed. La variation par société provient du mode de stockage, pas d’une fonction compute. Chercher à combiner compute= avec company_dependent=True mène à des incohérences et erreurs.
Piège 3 : rechercher à travers toutes les sociétés sans attention
Les recherches ORM sur un champ dépendant ne renvoient que les résultats correspondant à la société active.Pour des recherches cross-company il faut interroger ir.property (≤Odoo 16) ou manipuler la colonne jsonb avec précaution (≥Odoo 17). C’est une source fréquente d’erreurs dans les exports et les rapports.
Piège 4 : ne pas définir de valeurs par défaut pour toutes les sociétés
Sur un système en production, l’ajout d’un nouveau champ dépendant laisse les enregistrements existants sans valeur pour les sociétés qui n’ont rien défini (retour False/None). Si votre logique métier attend une valeur, pensez à migrer les données et définir des defaults pour chaque société concernée.
Piège 5 : confondre visibilité et valeur
Un champ dépendant règle la valeur affichée, pas l’accès au champ. Si vous devez masquer un champ pour certaines sociétés ou utilisateurs, cela relève des règles d’accès ou des record rules, pas de company_dependent.
Conclusion
Le champ dépendant de société est de ces fonctionnalités discrètes d’Odoo qui passent inaperçues jusqu’au moment où elles deviennent indispensables. C’est l’outil adapté quand un même enregistrement doit porter des valeurs différentes selon l’entité : configurations comptables, tarifs, références réglementaires, fournisseurs préférés, etc.
Savoir où et comment Odoo stocke ces valeurs, quelle version change le modèle de stockage, et quels pièges éviter vous fera gagner beaucoup de temps sur les projets multi-sociétés. Maîtriser ce champ est un vrai signe d’expertise Odoo opérationnelle.
Si votre projet sur le framework Odoo exige une gestion propre des données par société, company_dependent=True est la solution à privilégier.
Besoin d’aide pour votre implémentation Odoo ?
Chez Dasolo, nous accompagnons les entreprises dans la mise en œuvre, la personnalisation et l’optimisation d’Odoo, y compris pour des architectures multi-sociétés complexes. Besoin d’un modèle de données sur mesure, d’une stratégie de champs ou d’un déploiement complet ? Notre équipe allie expertise fonctionnelle et technique pour livrer la solution adaptée.
Si vous avez des questions sur les champs dépendants de société ou sur tout autre point de votre implémentation Odoo, nous sommes à votre disposition. Contactez‑nous et discutons de votre projet.