Maîtriser les Achats & Approvisionnements dans Odoo 19 — Partie 4/4 : Planification d'approvisionnement (orderpoints, MTO, scheduler)

Saison 8 · Article 4/4 — Achats & Approvisionnements

26 avril 2026 par

B.Mustapha

Saison 8 · Article 4/4 — Achats & Approvisionnements

Planification d'approvisionnement dans Odoo 19 — Orderpoints, MTO, scheduler

Tes stocks ont une valeur. Mais quand faut-il en recommander ? Et combien ? Et surtout — qui déclenche tout ça ? Dans cette Partie 4/4 on relie les points entre orderpoints classiques (MTS), route Make-to-Order (MTO) et scheduler Odoo, avec 2 scénarios chiffrés : un PO automatique de 474 810 DZD pour réapprovisionner les SSD d'InfoSphere, et un PO MTO de 428 400 DZD déclenché à la seconde où un client commande un portable Dell.

Ce que tu vas apprendre

Orderpoints

min / max / qty_to_order — la logique de réapprovisionnement automatique par seuil.

MTS vs MTO

Stock tampon contre commande à la demande — quand choisir quoi, avec chiffres à l'appui.

Scheduler v19

Le cron qui fait tourner la boutique — déplacé sur stock.rule en v19, plus de procurement.group.

Lead time fournisseur

Vendor pricelist, délai, multi-fournisseurs — comment Odoo prend sa décision de date de commande.

1. Où on en est : 12 serveurs en stock, mais pour combien de temps ?

Dans la Partie 3/4, Inès a compris comment Odoo valorise ses stocks : AVCO à 187 200 DZD pour les serveurs InfoRack R3 2U, 12 u encore au magasin, 2 246 400 DZD au bilan. Karim est content de la rigueur comptable. Mais il réalise vite qu'il n'a aucune vue sur quand les stocks vont tomber à zéro.

Ses SSD Samsung 870 EVO sont à 8 u ce matin. Combien de ventes avant rupture ? Et quand faut-il passer commande pour ne pas perdre un client ? Et cette commande, c'est Karim qui s'en occupe manuellement chaque semaine, ou Odoo peut faire le travail à sa place ?

La réponse tient en trois concepts — orderpoint, route, scheduler — qui travaillent ensemble pour transformer la gestion de stock d'InfoSphere d'une surveillance manuelle hebdo à une machine autonome qui ne demande qu'à être validée.

ℹ️ Trois grandes stratégies d'approvisionnement — dans Odoo tu rencontreras trois logiques : MTS (Make-to-Stock) stock tampon entretenu par seuils, MTO (Make-to-Order) on ne commande qu'après avoir reçu une vente, et la production à la commande (MRP, hors scope de cet article). Les deux premières couvrent 95 % des cas pour un distributeur comme InfoSphere.

2. Orderpoint 101 : min, max, qty_to_order

Un orderpoint (ou point de commande, ou règle de réapprovisionnement) est une règle qu'on attache à un couple produit × emplacement. Elle répond à une question simple : dès que le stock tombe sous un seuil min, commande de quoi remonter à max.

Champ v19	Technique	Rôle
Quantité minimale	`product_min_qty`	Le seuil en dessous duquel l'orderpoint se déclenche
Quantité maximale	`product_max_qty`	La cible à recharger — Odoo commandera de quoi atteindre ce niveau
Quantité à commander	`qty_to_order` (computed)	Calculée en temps réel = max − qty_on_hand (ajustable manuellement)
Déclencheur	`trigger` (auto / manual)	Auto = le scheduler le traite ; manual = clic humain requis
Délai avant commande	`days_to_order`	Jours d'anticipation au-delà du lead time fournisseur

Menu Inventaire → Opérations → Réapprovisionnement. Karim crée un orderpoint pour le Samsung 870 EVO 1TB : minimum 10 u, maximum 50 u, déclencheur Auto. L'orderpoint OP/00003 est créé, le champ Quantité à commander affiche 42 (= 50 − 8 en stock).

Orderpoint OP/00003 Samsung SSD 1TB Odoo 19 — min 10, max 50, qty_to_order 42, trigger auto — Orderpoint `OP/00003` — stock 8 u sous le seuil minimum de 10, Odoo veut commander 42 u pour atteindre le max de 50.

⚠️ Fin du qty_multiple en v19 — en v17 et v18 un champ Multiple de quantité (qty_multiple) permettait d'arrondir la commande à un multiple (ex. cartons de 12). Ce champ a disparu en v19. Il est remplacé par qty_to_order_manual (valeur saisie à la main qui écrase le calcul) et qty_to_order_computed (valeur calculée par Odoo). Pour les contraintes de conditionnement, passe désormais par l'unité de mesure secondaire ou par le min_qty de la product.supplierinfo.

3. Fil rouge MTS : 8 SSD en stock, le scheduler commande 42 u à TechDistrib

Orderpoint créé. Stock à 8 u (sous le min). Maintenant la vraie magie : Karim ne clique nulle part, il lance simplement le scheduler quotidien (qu'Odoo exécute de toute façon une fois par jour via cron automatique).

Menu Inventaire → Opérations → Exécuter le scheduler (ou simplement attendre le cron de minuit). Le scheduler balaye tous les orderpoints avec trigger = auto, et pour chacun qui a un qty_to_order > 0, il crée automatiquement un bon de commande fournisseur en brouillon.

État	Avant scheduler	Après scheduler
Stock SSD disponible	8 u	8 u (inchangé)
Quantité en commande	0 u	42 u (sur PO P00015 draft)
Valeur PO	—	474 810,00 DZD (42 × 9 500 + TVA 19 %)
Date prévue	—	2026-04-24 (=aujourd'hui + 7 jours de lead time fournisseur)
Fournisseur	—	TechDistrib Algérie (pris depuis la vendor pricelist)

Purchase Order P00015 Odoo 19 — 42 Samsung SSD 1TB à 9 500 DZD auprès de TechDistrib Algérie — PO `P00015` généré automatiquement par le scheduler — origin = OP/00003, en brouillon en attente de validation.

Le PO reste en brouillon. Karim le valide dès qu'il confirme le budget, ou le rejette s'il a déjà un backorder en cours. Odoo ne prend jamais la décision finale à sa place — il prépare juste la paperasse.

Pour un distributeur avec 200 références comme InfoSphere, cet automatisme fait gagner plusieurs heures par semaine : plus besoin de scanner un export Excel chaque lundi pour décider quoi recommander, le scheduler l'a fait cette nuit.

4. MTS ou MTO — deux philosophies opposées

L'orderpoint ci-dessus est du MTS : on maintient un stock tampon. Mais pour certains produits, maintenir un tampon est une mauvaise idée : coûteux en trésorerie, risqué en obsolescence, inutile si les ventes sont rares. C'est là qu'entre en scène la route MTO (Replenish on Order) — Odoo attend une vente concrète avant de commander.

Critère	MTS (Make-to-Stock)	MTO (Make-to-Order)
Déclencheur PO	Scheduler + orderpoint franchit le min	Confirmation d'une vente (SO)
Stock physique	Tampon permanent (entre min et max)	Proche de zéro
Délai client	Rapide (quelques jours, on a du stock)	Lent (lead time fournisseur + livraison)
Risque obsolescence	Moyen / élevé (selon rotation)	Faible — on ne commande que ce qui est vendu
Immobilisation trésorerie	Élevée (valeur stock permanent)	Faible (stock réduit)
Cas type	SSD, câbles, consommables à fort turnover	Portables configurables, serveurs sur mesure

Pour InfoSphere : SSD en MTS (orderpoint min/max), portables Dell en MTO. Inès configure la route MTO sur la fiche Dell Latitude 5450, en plus de la route Buy (les deux ensemble : Odoo sait qu'il doit acheter auprès du fournisseur dès qu'une vente est confirmée).

5. Fil rouge MTO : une vente Dell, un PO instantané

Route MTO activée. Routes [MTO + Buy] assignées à la fiche Dell Latitude 5450. Stock actuel : 8 u (InfoSphere en a en démo, mais on va voir qu'il va rester intouché — le MTO commande au fournisseur, pas au stock).

Karim prend un appel : Réseau Plus (Oran) veut 3 portables Dell pour son nouveau bureau. Devis rapide à 155 000 DZD HT l'unité. Karim crée S00009, le client confirme, Karim clique Confirmer.

À la seconde où le SO passe à sale :

Odoo remonte la chaîne d'approvisionnement Dell : route MTO → route Buy → fournisseur primaire de la product.supplierinfo
Création automatique de P00016 en brouillon chez TechDistrib Algérie
3 u × 120 000 = 360 000 HT, soit 428 400 DZD TTC — avec comme origin le nom du SO client S00009
Date prévue : aujourd'hui même (lead time Dell = 0 chez TechDistrib)

Purchase Order P00016 Odoo 19 créé par MTO — 3 Dell Latitude à 120 000 DZD, origin S00009 — PO `P00016` généré par la route MTO à la confirmation du SO — traçabilité via *origin*.

La différence avec le MTS : pas de scheduler, pas d'orderpoint, pas de seuil. Le déclencheur est la commande client elle-même. C'est idéal pour les produits à forte valeur unitaire, peu rotatifs, ou configurables (où maintenir un stock de chaque variante serait ruineux).

ℹ️ La route MTO est inactive par défaut — dans la plupart des bases Odoo 19 fraîchement installées, la route Replenish on Order est présente mais archivée. Il faut d'abord la réactiver dans Inventaire → Configuration → Routes (bascule Filtres → Archivé pour la voir), puis la cocher dans la fiche produit à côté de Buy. Les deux routes fonctionnent ensemble.

6. Lead time, multi-fournisseurs et vendor pricelist

Tout ce qu'on vient de voir repose sur un élément central souvent négligé : la vendor pricelist (ou liste de prix fournisseur), configurée sur chaque fiche produit dans l'onglet Achats. Chaque ligne décrit une relation commerciale avec un fournisseur.

Onglet Achats fiche produit Samsung SSD Odoo 19 — vendor pricelist TechDistrib prix 9 500, lead time 7 jours — Vendor pricelist du Samsung SSD — fournisseur principal *TechDistrib Algérie*, prix 9 500 DZD, délai de livraison 7 jours.

Champ	Rôle dans la planification
partner_id	Qui est le fournisseur de cette ligne
price	Prix unitaire de référence (surchargé par pricelist client si pertinent)
min_qty	Quantité minimale à commander (si orderpoint calcule 5 mais min=12, Odoo passe à 12)
delay	Lead time en jours — utilisé pour calculer date_planned
date_start / date_end	Fenêtre de validité (utile pour contrats-cadres trimestriels)

Si plusieurs fournisseurs sont listés, Odoo prend par défaut le premier (celui du haut, ordonnable par sequence). Le scheduler suit cet ordre sans faire de comparaison de prix — c'est au gestionnaire de trier intelligemment, ou d'utiliser un appel d'offre (RFQ) comme vu dans la Partie 1/4 pour choisir avant de créer l'orderpoint.

L'aboutissement de cette chaîne : lead time fournisseur (7 jours pour le SSD chez TechDistrib) + days_to_order de l'orderpoint (jour supplémentaire d'anticipation) + security_lead_time de l'entreprise (sur la fiche entreprise) = la date à laquelle Odoo estime qu'il faut passer la commande pour ne pas rater la date de disponibilité souhaitée.

7. Encadré ⚠️ Changements v19 — ce qui se casse à la migration

Cette quatrième partie révèle la plus grosse surface de rupture v19 que vous avez rencontrée dans la série. Trois changements structurels majeurs qui cassent les modules tiers qui touchent à la chaîne de procurement.

Parcours complet d'un approvisionnement Odoo 19 — orderpoint MTS vs route MTO jusqu'au PO fournisseur — Deux chemins vers un PO — MTS via orderpoint + scheduler, MTO via route + confirmation SO.

⚠️ procurement.group n'existe plus en v19 — le modèle central de la chaîne de procurement a été supprimé. La méthode run_scheduler est désormais sur stock.rule (self.env['stock.rule'].run_scheduler()). Les modules personnalisés qui importaient from odoo.addons.procurement ou qui faisaient self.env['procurement.group'].run_scheduler() vont crasher à l'install en v19.

⚠️ qty_multiple supprimé sur stock.warehouse.orderpoint — le champ qui permettait d'arrondir la commande à un multiple (cartons, palettes) est parti. Son remplacement est une paire de champs : qty_to_order_computed (calcul par Odoo) et qty_to_order_manual (saisie humaine qui l'écrase). Le nouveau qty_to_order expose le bon selon la présence ou l'absence de saisie manuelle. Les vues custom qui référençaient qty_multiple en readonly ou compute doivent être migrées.

⚠️ Nouveaux champs sur l'orderpoint — snoozed_until (date jusqu'à laquelle un orderpoint manuel est mis en pause, visible dans l'interface « Réapprovisionnement »), unwanted_replenish (booléen computed qui signale quand la commande prévue dépasserait le max), et les nouvelles actions action_snooze / action_schedule_auto_reordering. Si ton module override _compute_qty_to_order, pense à gérer ces nouveaux états.

Ces trois changements, ajoutés à la suppression de stock.valuation.layer vue dans la Partie 3/4, font de la chaîne supply chain d'Odoo 19 un chantier quasi-structurel. Les migrations depuis v17/v18 demandent au moins une revue complète des modules tiers qui touchent à stock_account, stock, et purchase_stock.

À retenir

🎯 Orderpoint = min / max / qty_to_order

Un couple produit × emplacement, déclencheur auto ou manuel. Le scheduler traite uniquement les orderpoints auto et génère les PO en brouillon. Le manager valide ensuite.

⚡ MTO = route, pas orderpoint

La route Replenish on Order est à réactiver (archivée par défaut) puis à cocher sur la fiche produit avec la route Buy. Chaque vente confirmée crée alors un PO instantané au fournisseur primaire.

📅 Lead time = vendor pricelist + days_to_order

Délai fournisseur renseigné sur la product.supplierinfo, days_to_order optionnel sur l'orderpoint, security_lead_time sur la société. L'addition donne la date à laquelle Odoo veut que la commande soit passée.

💥 3 breaking changes v19

procurement.group supprimé → stock.rule.run_scheduler. qty_multiple supprimé → qty_to_order_manual/computed. Nouveaux champs snoozed_until et unwanted_replenish. Migration v17/v18 → v19 = chantier structurel sur la supply chain.

Fin de la Saison 8 — Maîtriser les Achats & Approvisionnements

Tu as maintenant un cycle d'achats complet dans Odoo 19 CE : contrats-cadres et appels d'offre pour choisir les fournisseurs, landed costs pour calculer le vrai coût, valorisation FIFO/AVCO pour un stock fidèle, et planification (orderpoints + MTO) pour automatiser les commandes. La compta suit, les marges sont honnêtes, la trésorerie respire.

Prochaine saison en préparation : Configurateur Produit (Saison 9 — variantes, pricelists, matrix configurator).