Calcul des besoins nets : ce qu'Odoo calcule vraiment

Le calcul des besoins nets, souvent abrégé CBN, répond à une question simple et concrète : combien faut-il encore acheter ou fabriquer une fois le stock et les en-cours retirés. Dans Odoo, ce calcul n'a pas d'écran qui porte ce nom.

Un intégrateur Odoo pour une PME industrielle sert à dire quel écran fait foi, le rapport de réapprovisionnement ou le plan directeur, pas les deux. Les nomenclatures, les postes et le MTO sont déjà dans le guide fabrication et MRP. Ici, on ne refait pas l'atelier : on refait l'arithmétique.

Les chemins sont ceux de la documentation Master Production Schedule 19.0, en anglais. La base française traduit les menus. Le public visé est le dirigeant ou le responsable d'ordonnancement qui a un tableur de besoins, et qui veut savoir ce qu'Odoo en garde.

Que signifie CBN, et que calcule-t-on vraiment ?

CBN veut dire calcul des besoins nets. Le besoin brut est ce que les commandes, ou une prévision, demandent. Le besoin net est ce qui manque encore après le stock disponible et ce qui est déjà lancé : ordre de fabrication ouvert, commande fournisseur non réceptionnée. La méthode MRP enchaîne ce calcul niveau par niveau, du produit fini vers les composants, en suivant la nomenclature et les délais.

Odoo rapproche cette logique de trois endroits, qui ne donnent pas le même chiffre le même jour. Le rapport de prévision de l'article porte la demande à long terme. Le rapport de réapprovisionnement, Inventory, Operations, Replenishment, ne retient, pour une règle, que la demande qui tombe dans la fenêtre de délai.

Le plan directeur travaille par période, avec une demande saisie ou suggérée, et une quantité de réapprovisionnement proposée. JAIKIN écrit, pour chaque famille, lequel de ces trois écrans est la source, avant d'appuyer sur Order sur la copie de recette.

Confondre les trois fait commander deux fois. Une règle de minimum qui tourne pendant qu'un plan directeur propose déjà un ordre crée deux documents. La documentation du plan directeur le dit : ne pas appliquer de reordering rules aux articles qui sont dans le plan. Le guide fabrication pose le même interdit. Ce guide montre pourquoi les quantités divergent, sur un exemple chiffré qui n'est pas un cas client.

Comment calcule-t-on un besoin net, sur un exemple fictif ?

Les quantités qui suivent sont inventées pour rendre la soustraction visible. Le produit, le « banc atelier », n'existe pas dans nos références. Aucun stock, aucune commande et aucun en-cours ci-dessous n'est un chiffre JAIKIN ni un chiffre client. Le jour où un plan directeur réel affiche autre chose, c'est l'écran qui a raison, pas ce tableau.

On part du produit fini. Besoin brut : 12 bancs, issus de commandes confirmées. Stock disponible : 3. En-cours de fabrication déjà lancés : 4. Besoin net de bancs : 12 − 3 − 4 = 5. Ces 5 bancs sont la seule quantité à lancer en plus. Les 4 déjà ouverts ne se relancent pas. C'est l'oubli le plus fréquent du tableur recollé sans colonne d'en-cours : il recommande 9, et l'atelier double.

La nomenclature fictive dit : 1 banc = 2 montants + 1 plateau. Pour 5 bancs, le besoin brut de montants est 10, celui de plateaux est 5. Montants : stock 4, commande fournisseur ouverte 2, besoin net 10 − 4 − 2 = 4.

Plateaux : stock 0, rien en commande, besoin net 5. Le calcul s'arrête là dans l'exemple. Une nomenclature à trois niveaux continuerait sous le plateau, avec la même soustraction. Odoo ne présente pas cette cascade dans un seul rapport titré CBN.

Si l'on appliquait telle quelle la formule de suggestion du plan directeur, avec un stock de départ de 3, une demande prévue de 12 et un stock de sécurité à zéro, la suggestion vaudrait 0 − 3 + 12 = 9.

Les 4 ordres déjà ouverts n'apparaissent pas dans cette soustraction publiée. Neuf contre cinq : l'écart n'est pas une erreur de saisie, c'est deux définitions. JAIKIN réconcilie les deux sur une copie avant de croire le bouton Order. Un chiffre de ce tableau n'est pas un engagement de stock.

Comment Odoo propose-t-il ces quantités ?

Le plan directeur s'active dans Manufacturing, Configuration, Settings, case Master Production Schedule. On choisit le pas, année, mois, semaine ou jour, et le nombre de périodes. L'écran est dans Manufacturing, Planning, Master Production Schedule. Chaque produit est un groupe de lignes : stock de départ, demande prévue, demande indirecte s'il s'agit d'un composant, réapprovisionnement, stock prévu. La relation publiée est : stock prévu = stock de départ − demande prévue − demande indirecte + réapprovisionnement.

La suggestion de réapprovisionnement publiée est : stock de sécurité − stock de départ + demande prévue + demande indirecte. Un minimum à réapprovisionner force au moins cette quantité, sauf si le calcul est négatif ou nul : dans ce cas la suggestion reste à zéro.

Le déclencheur Manual exige le bouton Order. Automatic programme l'ordre. Never n'approvisionne pas depuis ce plan. Ajouter le produit avec une nomenclature ajoute aussi ses composants. Si ces composants ne doivent pas être pilotés ici, on laisse la nomenclature vide à l'ajout.

Une route Buy exige un fournisseur sur la fiche, et crée une demande de prix dans Purchase, Orders, Requests for Quotation. Une route Manufacture exige une nomenclature, et crée un ordre dans Manufacturing, Operations, Manufacturing Orders. Le bouton Order du haut lance la période courante pour tous les produits prêts.

Une cellule verte est à lancer, une grise est déjà lancée au bon niveau, une jaune est en dessous, une rouge est au-dessus. JAIKIN ne traite le rouge qu'après avoir compris quel ordre en trop est déjà parti, pas en relançant.

Ce que le rapport de réapprovisionnement retient, et ce qu'il ignore

Le rapport est aussi dans Inventory, Operations, Replenishment. Pour une règle de minimum, la quantité à commander vise le maximum. La logique juste-à-temps ne retient la demande que si elle tombe avant la date prévisionnelle de réception, somme des délais.

Une commande client au-delà de cette date est absente du forecast de la règle, mais elle reste dans le rapport de prévision de l'article, via l'icône de graphique. Les jours d'horizon élargissent la fenêtre. Sans eux, un délai fournisseur court masque une livraison de la semaine suivante.

C'est la deuxième raison pour laquelle un tableur de CBN, qui liste toutes les commandes ouvertes, ne colle pas au rapport. Le tableur voit les 12 bancs. La règle, si 7 d'entre eux sont promis après le délai, n'en voit qu'une partie.

Le plan directeur, lui, montre la demande sur toute la période affichée, à condition qu'elle soit saisie ou suggérée. Suggérer la demande se fait depuis l'icône de la ligne Forecasted Demand : demande réelle d'il y a un an, trente derniers jours, trois mois, douze mois, avec un coefficient. Une suggestion à 110 % n'est pas une prévision validée. Nous ne cliquons Apply qu'après lecture par l'ordonnancement.

Quelles limites faut-il accepter avant de lancer les ordres ?

Première limite : pas de calcul multi-niveaux dans un seul clic hors plan directeur. Sélectionner la nomenclature à l'ajout du produit fait apparaître les composants, et leur demande indirecte vient des ordres de fabrication existants. Une règle de minimum sur le fini ne crée pas, à elle seule, les besoins nets des composants. Chaque composant a sa règle, ou il est dans le plan. Le croire automatique, c'est découvrir le manque de plateaux le jour du prélèvement.

Deuxième limite, à écrire au cadrage : le cumul avec les minimums. La documentation l'interdit parce que les prévisions deviennent fausses et les ordres inutiles. Nous retirons la règle, ou nous retirons l'article du plan. Pas de compromis « on verra ».

Troisième limite : le MTO, route Replenish on Order, crée un document à chaque confirmation de commande, même s'il reste du stock. Le poser en plus d'un CBN de stock de sécurité relance ce que le stock couvrait déjà. Le choix de route est dans le guide fabrication.

Quatrième limite : la valorisation. Le besoin net dit une quantité, pas un coût. FIFO de prélèvement et FIFO de valorisation ne sont pas le même réglage. Les trancher dans les achats ou dans le plan directeur ne sert à rien.

Le détail est dans le guide stock FIFO et FEFO. Cinquième limite : Odoo 20 suggère des seuils à partir de l'historique. Ce n'est pas une raison de calculer les besoins d'une usine neuve sur une version majeure le mois de sa sortie. Le guide Odoo 20 dit de démarrer en 19 et de viser la 20 en 2027.

Ce que nous voyons en intégration

Le premier écart est le tableur collé dans la demande prévue, sans colonne d'en-cours. Le plan suggère alors le brut. Nous rejouons une famille sur une copie, avec les ordres déjà ouverts, et nous comparons la suggestion au besoin net calculé à la main.

Tant que les deux chiffres ne s'expliquent pas, personne ne clique sur Order. Le deuxième écart est l'horizon à zéro sur des composants à délai long : le rapport a l'air vide, l'atelier s'arrête. Nous posons l'horizon au moins égal au plus long délai de la famille pilote.

Le troisième écart est d'étendre le plan à tout le catalogue parce que l'écran le permet. Ajouter une nomenclature ajoute les composants. Cent produits deviennent quatre cents lignes, et plus personne ne lit le vert, le jaune et le rouge.

Nous tenons une famille, comme pour le reste du socle. Un périmètre court se situe entre 2 000 et 8 000 € hors licence. Le socle, fabrication comprise, se situe entre 8 000 et 25 000 €. Le détail des licences est sur la page prix d'Odoo.

La bascule suit la méthode d'une migration Odoo : copie, recette d'un cycle de commande jusqu'à l'ordre, week-end, rollback testé en 2 h. EBMC est client Odoo de JAIKIN. Cette phrase ne décrit pas son ordonnancement, et l'exemple du banc n'est pas le sien.

Une base avec des modules spécifiques ne peut pas être migrée tant qu'une version de ces modules n'existe pas pour la version cible. Le calcul des besoins reste dans le plan directeur standard tant qu'un écran maison n'a pas de raison écrite. JAIKIN est Odoo Learning Partner, près de Strasbourg : la formation de l'ordonnancement fait partie du plan, et une demande de cadrage reçoit une réponse sous 24 h.

Questions fréquentes

Que signifie CBN, et est-ce un menu Odoo ?

CBN signifie calcul des besoins nets : besoin brut, moins le stock disponible, moins les en-cours, égal au reste à lancer. Odoo 19 n'a pas de menu qui porte cet acronyme. Le calcul est réparti entre le rapport de prévision de l'article, le rapport de réapprovisionnement et le plan directeur de production. JAIKIN fait désigner un seul de ces écrans comme source, par famille d'articles, avant de créer le moindre ordre depuis une suggestion.

Comment calcule-t-on un besoin net ?

On part des commandes ou d'une prévision, c'est le besoin brut. On retire le stock disponible et ce qui est déjà lancé, ordre de fabrication ou commande fournisseur. Le solde positif est le besoin net. Sur un exemple fictif de 12 bancs, avec 3 en stock et 4 en-cours, le net est 5, pas 9. Les composants se calculent ensuite avec la nomenclature, sur ce net seulement. Les quantités de l'exemple ne décrivent aucune entreprise réelle.

Qu'est-ce que la méthode MRP dans Odoo ?

La méthode MRP enchaîne le besoin net du produit fini vers les composants, selon la nomenclature et les délais. Dans Odoo 19, le plan directeur s'en approche si l'on ajoute le produit avec sa nomenclature : les composants apparaissent, et leur demande indirecte vient des ordres existants. Une simple règle de minimum sur le produit fini n'explose pas la nomenclature. Le guide fabrication décrit les nomenclatures et les postes ; il ne refait pas cette arithmétique.

Le plan directeur crée-t-il les commandes tout seul ?

Pas par défaut. La documentation 19.0 indique que le plan suggère une quantité et que l'utilisateur doit créer l'ordre, bouton Order. Le déclencheur Automatic programme l'ordre, Manual le laisse à la main, Never n'approvisionne pas depuis le plan. JAIKIN laisse Manual tant qu'une famille n'a pas été recettée sur une copie. Cumuler ce plan avec des règles de minimum sur le même article fausse les prévisions, la documentation l'interdit.

Pourquoi le rapport de réapprovisionnement ne montre-t-il pas toutes les commandes ?

La logique juste-à-temps ne retient, pour la règle, que la demande qui tombe avant la date de réception possible, somme des délais. Une commande promise plus tard reste dans le rapport de prévision de l'article, pas dans le forecast de la règle. Les jours d'horizon élargissent cette fenêtre. Un tableur qui liste toutes les commandes ouvertes affiche donc un besoin plus haut. L'écart se explique avant de commander, il ne se « corrige » pas en forçant la quantité.

Combien coûte la mise en place de ce calcul ?

Le coût est celui du paramétrage : nomenclatures justes, délais, choix entre plan directeur et minimums. JAIKIN situe un périmètre court entre 2 000 et 8 000 € hors licence, et un socle entre 8 000 et 25 000 €. La licence Standard éditeur est de 19,90 € puis 24,90 € par utilisateur et par mois en annuel. Le chiffrage suit le cadrage, pas une promesse de durée avant d'avoir vu les nomenclatures.