Référentiels partagés entre sociétés : contacts, produits, étapes, vues

Dans Odoo, un enregistrement appartient à une société ou à aucune. Il n'y a pas d'intermédiaire : un contact partagé entre deux filiales sur trois, une étape de pipeline propre à une entité, une vue personnalisée pour une seule société — rien de cela n'est possible.

Dix-huit modules communautaires ajoutent cet intermédiaire, et terminent le dépôt multi-company.

Résumé

Cinq modules traitent les tiers et les produits : la visibilité d'un contact choisie société par société, la gestion multi-société des catégories de contact et des secteurs d'activité, la visibilité d'un modèle de produit société par société, et un garde-fou empêchant de retirer une société d'un produit s'il y reste du stock ou des mouvements.

Quatre modules traitent la vente et la caisse : les catégories de point de vente en contexte multi-société, les taxes par défaut du produit par société, et deux modules de suivi marketing — support et source — rendus multi-société.

Quatre modules traitent le CRM : les motifs de perte, les étapes et les étiquettes rendus multi-société.

Cinq modules enfin traitent les objets techniques : les événements et les types d'événement de calendrier, les filtres définis par les utilisateurs, les vues personnalisées par société, et deux modules de messagerie — la passerelle et les modèles de courriel — rendus multi-société.

L'essentiel

• La visibilité d'un contact choisie société par société.
• La visibilité d'un produit choisie société par société.
• Un garde-fou empêchant de retirer une société si du stock subsiste.
• Les étapes et motifs de perte du CRM par société.
• Les filtres utilisateurs par société.
• Des vues personnalisées pour une société précise.
• Les modèles de courriel par société.
• Les taxes par défaut du produit par société.

Ce que ces modules ajoutent à l'instance

Aucun de ces modules n'ajoute de menu : ils ajoutent un champ de sociétés autorisées aux modèles concernés.

Le problème que ces modules résolvent

Le modèle multi-société d'Odoo est binaire : un enregistrement porte une société — il n'est visible que d'elle — ou n'en porte aucune — il est visible de toutes. Dans un groupe de cinq entités, le cas réel est presque toujours « visible de trois d'entre elles ».

Le contournement habituel consiste à laisser l'enregistrement sans société, donc visible de tout le monde, et à compter sur la discipline. Cela fonctionne jusqu'au jour où deux entités du groupe ont des clients concurrents, ou des gammes qu'elles ne doivent pas se voir.

base_multi_company — le socle traité avec les flux inter-sociétés — fournit le mécanisme ; les modules de cette fiche l'appliquent à un modèle précis. Le résultat est le même partout : un champ listant les sociétés qui voient l'enregistrement.

Les tiers et les produits

partner_multi_company applique ce mécanisme aux contacts : un client partagé entre la société de négoce et la société d'installation, mais invisible de la filiale de transport.

product_multi_company l'applique aux modèles de produit : une gamme vendue par deux entités sur quatre.

product_multi_company_stock est le garde-fou associé : il empêche de retirer une société de la liste si cette société détient du stock ou des mouvements sur le produit.

Le garde-fou est le module le plus utile des deux : retirer une société d'un produit qui a du stock chez elle rend ce stock invisible — il ne disparaît pas, il devient inaccessible, et il réapparaît à l'inventaire comme un écart inexplicable.

Deux modules complètent les référentiels de contact : partner_category_multi_company pour les catégories de contact — les étiquettes — et res_partner_industry_multi_company pour les secteurs d'activité.

La vente, la caisse et le CRM

• pos_category_multicompany rend les catégories de point de vente multi-société : deux magasins de deux entités différentes n'ont pas les mêmes rayons.
• product_tax_multicompany_default gère les taxes par défaut du produit par société. Son README est réduit à sa catégorie. Le besoin est clair en multi-pays : le même article n'a pas le même taux selon l'entité qui le vend.
• utm_medium_multi_company et utm_source_multi_company rendent multi-société les référentiels de support et de source du suivi marketing.

Trois modules traitent le CRM : crm_lost_reason_multi_company pour les motifs de perte, crm_stage_multi_company pour les étapes du pipeline, crm_tag_multi_company pour les étiquettes.

Un pipeline commun à deux entités dont les cycles de vente diffèrent — un négoce à trois étapes, un bureau d'études à sept — est le signe le plus sûr qu'aucune des deux ne se sert du CRM.

À ne pas confondre avec crm_stage_multi_team, qui partage une étape entre plusieurs équipes d'une même société, traité dans le pipeline CRM.

Les objets techniques

• calendar_event_multi_company et calendar_event_type_multi_company rendent multi-société les événements et les types d'événement de calendrier.
• ir_filters_multi_company rend multi-société les filtres définis par les utilisateurs : les filtres favoris d'une entité ne polluent plus les listes d'une autre.
• ir_ui_view_multi_company permet de définir des vues personnalisées pour une société précise.
• mail_multicompany et mail_template_multi_company rendent multi-société la passerelle de messagerie et les modèles de courriel. Les deux ont un README réduit à leur catégorie.

Les vues par société sont le module le plus structurant de ce groupe : il permet d'adapter un écran aux besoins d'une entité sans l'imposer aux autres. Dans le standard, une surcharge de vue s'applique à tout le monde.

Les modèles de courriel par société répondent à une question de marque : deux entités d'un même groupe n'écrivent pas à leurs clients avec le même logo, la même signature et les mêmes mentions légales. Sans ce module, il faut dupliquer les flux ou accepter une communication générique.

Les modèles de courriel et leurs règles de substitution sont traités dans écrire depuis Odoo.

Limites connues

• Trois modules ont un README réduit à leur catégorie : product_tax_multicompany_default, mail_multicompany et mail_template_multi_company.
• Ces modules élargissent la visibilité, ils ne la cloisonnent pas davantage : le modèle reste permissif par défaut pour un enregistrement sans société.
• La visibilité multi-société est une règle d'enregistrement, donc contournable par un utilisateur ayant accès à plusieurs sociétés simultanément.
• Ajouter la gestion multi-société à un modèle change ses règles d'accès : à éprouver sur une base de recette, modèle par modèle.
• product_multi_company_stock bloque un retrait de société : c'est son objet, mais cela demande de solder le stock avant de réorganiser un catalogue.
• Les vues par société multiplient les variantes à maintenir : chaque montée de version demande de les vérifier toutes.
• Tous ces modules dépendent du socle base_multi_company pour la plupart, ou directement de base : vérifier la cohérence des versions installées.

Identité technique

Les dix-huit modules viennent du dépôt OCA multi-company, branche 18.0 — dont les 29 modules sont désormais tous documentés ici —, tous en licence AGPL-3. Les dépendances : base_multi_company pour les contacts et les produits, base pour les référentiels techniques, crm, utm, calendar, mail, point_of_sale, account et stock selon le modèle visé.

L'autre fiche du dépôt : flux inter-sociétés.

Questions fréquentes

Un contact peut-il être visible de certaines sociétés seulement ?

Pas en standard : le modèle d'Odoo est binaire — une société, ou aucune. partner_multi_company permet de choisir individuellement la visibilité société par société. Dans un groupe de cinq entités, le cas réel est presque toujours « visible de trois d'entre elles ».

Que se passe-t-il si on retire une société d'un produit qui a du stock ?

Sans garde-fou, ce stock devient inaccessible — il ne disparaît pas, il réapparaît à l'inventaire comme un écart inexplicable. product_multi_company_stock empêche ce retrait tant que la société détient du stock ou des mouvements sur le produit.

Peut-on avoir un pipeline CRM différent par société ?

Oui, avec crm_stage_multi_company pour les étapes, complété par crm_lost_reason_multi_company et crm_tag_multi_company. Un pipeline commun à deux entités dont les cycles diffèrent — un négoce à trois étapes, un bureau d'études à sept — est le signe qu'aucune ne s'en sert.

Peut-on personnaliser un écran pour une seule société ?

Oui : ir_ui_view_multi_company permet de définir des vues pour une société précise. Dans le standard, une surcharge de vue s'applique à tout le monde. Attention : chaque variante est à vérifier à chaque montée de version.

Peut-on avoir des modèles de courriel différents par société ?

Oui, avec mail_template_multi_company. C'est une question de marque : deux entités d'un même groupe n'écrivent pas avec le même logo, la même signature et les mêmes mentions légales. Sans ce module, il faut dupliquer les flux ou accepter une communication générique.

Se faire accompagner

Le cloisonnement multi-société est le sujet où la facilité coûte le plus cher : laisser les référentiels sans société, donc visibles de toutes, fonctionne jusqu'au jour où deux entités du groupe ont des clients concurrents. Reprendre le cloisonnement ensuite suppose de réattribuer des milliers d'enregistrements.

Nous posons donc la carte de visibilité au démarrage — quel référentiel est commun, lequel est propre, lequel est partagé par certaines entités — et nous n'installons que les modules correspondants. Voir les prestations d'Atalios Consulting ou demander un rappel.

Pour aller plus loin

• Flux inter-sociétés : facture, commande et transfert miroirs
• Le pipeline CRM reprise en main

En résumé

Dans Odoo, un enregistrement appartient à une société ou à aucune — il n'y a pas d'intermédiaire. Dix-huit modules l'ajoutent : contacts, produits, étapes CRM, filtres, vues et modèles de courriel visibles des seules sociétés choisies. Parlons de votre cloisonnement.