Une entreprise à trois agences, deux divisions ou plusieurs établissements veut cloisonner : chaque entité voit ses commandes, ses stocks et ses résultats, sans voir ceux des autres. Odoo n'offre que deux niveaux — la société, trop lourde, et l'analytique, qui n'isole rien.
Seize modules communautaires fournissent le niveau intermédiaire. Ils terminent le dépôt operating-unit.
Résumé
Trois modules forment le socle : l'unité opérationnelle comme entité interne d'une société, son rattachement à l'analytique, et un module ouvrant l'accès à toutes les unités à certains utilisateurs.
Deux modules traitent la comptabilité : la marque de l'unité sur les factures et les écritures, avec un compte de liaison pour les opérations entre unités, et l'héritage de vues nécessaire.
Quatre modules traitent le commerce : l'unité sur les équipes commerciales, sur le CRM, sur les ventes, et sur les ventes avec stock.
Trois modules traitent les achats et la production : l'unité sur les commandes d'achat, sa copie du transfert d'achat vers le transfert de stock, et son application à la production.
Quatre modules enfin traitent les référentiels et les documents : l'unité sur les produits, sur les contacts, sur le stock avec son module d'accès global, et dans les rapports imprimés.
L'essentiel
- Une entité interne à la société, entre la société et l'analytique.
- Un compte de liaison pour les opérations entre unités.
- L'unité sur les équipes commerciales et le CRM.
- L'unité copiée du transfert d'achat vers le transfert de stock.
- L'unité sur les produits et les contacts.
- L'unité dans les rapports imprimés.
- Deux modules d'accès global, pour les utilisateurs transverses.
- Quatorze modules sur seize en LGPL-3.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Socle | operating_unit, analytic_operating_unit, operating_unit_access_all | 3 |
| Comptabilité | account_operating_unit | 1 |
| Commerce | sales_team_operating_unit, crm_operating_unit, sale_operating_unit, sale_stock_operating_unit | 4 |
| Achats et production | purchase_operating_unit, purchase_stock_operating_unit, mrp_operating_unit | 3 |
| Référentiels et documents | product_operating_unit, res_partner_operating_unit, stock_operating_unit, stock_operating_unit_access_all, report_qweb_operating_unit | 5 |
Le menu ajouté : Paramètres ▸ Utilisateurs & Sociétés ▸ Operating Units.
Le niveau qui manque entre société et analytique
Odoo offre deux niveaux pour organiser une entreprise, et aucun ne convient à une agence : la société cloisonne mais impose un plan comptable, des journaux et des déclarations ; l'analytique n'impose rien mais ne cloisonne pas — un commercial de l'agence de Lyon voit les commandes de Bordeaux.
operating_unit (LGPL-3) introduit l'unité opérationnelle, que son README définit comme une entité organisationnelle faisant partie d'une société. Référentiel sous Paramètres ▸ Utilisateurs & Sociétés ▸ Operating Units.
La différence avec l'analytique est le cloisonnement : une unité opérationnelle restreint ce que ses utilisateurs voient, là où un axe analytique ne fait que classer.
analytic_operating_unit rattache l'unité à l'analytique — les deux ne s'excluent pas, l'unité cloisonne et l'analytique analyse.
operating_unit_access_all ouvre l'accès à toutes les unités à certains utilisateurs : la direction, la comptabilité, l'administration. Son pendant pour le stock, stock_operating_unit_access_all, existe également.
Les deux modules d'accès global sont indispensables et souvent installés en retard : sans eux, le responsable financier ne voit aucune des trois agences, et le cloisonnement se désactive dans la semaine.
La comptabilité et le compte de liaison
account_operating_unit (LGPL-3, version 18.0.1.0.2) porte l'unité sur les factures et les écritures comptables, avec un compte de liaison.
Le compte de liaison est la pièce maîtresse : quand l'agence de Lyon livre une marchandise prise au stock de Bordeaux, l'écriture doit équilibrer les deux unités sans sortir de la société. Sans compte de liaison, chaque unité a un résultat faux et seul le total est juste.
C'est ce qui distingue l'approche d'un simple axe analytique : les unités ont des comptes qui s'équilibrent entre elles, donc un résultat par unité qui tient.
Le module dépend de l'héritage de vues technique et de l'analytique par unité.
L'analytique et ses répartitions sont traitées dans la comptabilité analytique reprise.
Les flux : vente, achat, stock, production
| Module | Où l'unité apparaît |
|---|---|
sales_team_operating_unit | L'équipe commerciale — la racine du cloisonnement commercial |
crm_operating_unit | Le CRM : pistes et opportunités |
sale_operating_unit | Les commandes de vente |
sale_stock_operating_unit | Les ventes avec stock |
purchase_operating_unit | Les commandes d'achat |
purchase_stock_operating_unit | La copie de l'unité du transfert d'achat vers le transfert de stock |
mrp_operating_unit | La production |
stock_operating_unit | Le stock |
product_operating_unit | Les produits |
res_partner_operating_unit | Les contacts |
report_qweb_operating_unit | Les rapports imprimés |
Le cloisonnement part de l'équipe commerciale : c'est elle qui porte l'unité, et les commandes en héritent. Six de ces modules ont un README réduit à leur catégorie ; leur objet se lit dans leur nom et leur dépendance.
purchase_stock_operating_unit mérite une mention : il copie l'unité du transfert d'achat vers le transfert de stock, sans quoi la marchandise entre dans un stock sans unité et échappe au cloisonnement dès la réception.
report_qweb_operating_unit fait apparaître l'unité dans les documents imprimés — ce qui compte pour une entreprise dont les agences ont une adresse et un interlocuteur différents.
Limites connues
- Six modules ont un README réduit à leur catégorie :
analytic_operating_unit,crm_operating_unit,mrp_operating_unit,operating_unit_access_all,report_qweb_operating_unitetres_partner_operating_unit. - L'unité opérationnelle n'est pas une société : pas de plan comptable propre, pas de numéro de TVA, pas d'exercice. Si les entités déclarent séparément, il faut des sociétés.
- Les deux modules d'accès global sont indispensables : sans eux, la direction et la comptabilité ne voient rien, et le cloisonnement est désactivé dans la semaine.
- Le compte de liaison est à paramétrer avec l'expert-comptable : il détermine si le résultat par unité tient.
- Installer le cloisonnement sur une base en service suppose d'affecter l'existant : commandes, stocks, contacts et produits sans unité restent invisibles ou visibles de tous.
purchase_stock_operating_unitest le module qu'on oublie : sans lui, la marchandise entre dans un stock sans unité dès la réception.- Quatorze modules sur seize sont en LGPL-3 : les deux exceptions,
operating_unit_access_alletpurchase_stock_operating_unit, sont en AGPL-3.
Identité technique
Les seize modules viennent du dépôt OCA operating-unit, branche 18.0 — dont tous les modules sont désormais documentés ici. Quatorze sont en LGPL-3, deux en AGPL-3. Les dépendances : base pour le socle, account, analytic, sale, sales_team, crm, purchase, stock, mrp et product selon l'application, base_view_inheritance_extension pour l'héritage de vues de la comptabilité.
Voir aussi les référentiels partagés entre sociétés et la comptabilité analytique reprise.
Questions fréquentes
Quelle différence entre une unité opérationnelle et un axe analytique ?
Le cloisonnement. Une unité opérationnelle restreint ce que ses utilisateurs voient ; un axe analytique ne fait que classer. Avec l'analytique seule, un commercial de l'agence de Lyon voit les commandes de Bordeaux. Les deux ne s'excluent pas : l'unité cloisonne, l'analytique analyse.
Peut-on avoir un résultat par agence sans créer une société par agence ?
Oui, grâce au compte de liaison de account_operating_unit : quand l'agence de Lyon livre une marchandise prise au stock de Bordeaux, l'écriture équilibre les deux unités sans sortir de la société. Sans ce compte, chaque unité a un résultat faux et seul le total est juste. À paramétrer avec l'expert-comptable.
Comment la direction voit-elle toutes les agences ?
Avec operating_unit_access_all et son pendant pour le stock, stock_operating_unit_access_all, qui ouvrent l'accès à toutes les unités à certains utilisateurs. Ces modules sont indispensables et souvent installés en retard : sans eux, le responsable financier ne voit rien et le cloisonnement est désactivé dans la semaine.
D'où part le cloisonnement commercial ?
De l'équipe commerciale : sales_team_operating_unit porte l'unité sur l'équipe, et les commandes en héritent. Puis crm_operating_unit, sale_operating_unit et sale_stock_operating_unit étendent la dimension aux pistes, aux commandes et aux ventes avec stock.
Quel module oublie-t-on le plus souvent ?
purchase_stock_operating_unit, qui copie l'unité du transfert d'achat vers le transfert de stock. Sans lui, la marchandise entre dans un stock sans unité dès la réception, et échappe au cloisonnement — alors que tout le reste est correctement paramétré.
Se faire accompagner
Les unités opérationnelles répondent à une question qu'on pose mal : « faut-il une société par agence ». Le vrai critère est déclaratif — si les entités ne déclarent pas séparément, l'unité opérationnelle cloisonne pour une fraction du coût d'une société.
Nous posons donc le compte de liaison avec votre expert-comptable avant tout, puis les deux modules d'accès global en même temps que le cloisonnement — jamais après, sinon la direction demande à désactiver l'ensemble. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
Une entreprise à trois agences veut cloisonner sans créer trois sociétés. Odoo n'offre que deux niveaux : la société, trop lourde, et l'analytique, qui n'isole rien. Seize modules fournissent le niveau intermédiaire, avec son compte de liaison. Parlons de votre organisation.
