Réapprovionnements

Réapprovisionnement et délais dans Odoo — note de connaissance

Le moteur d'approvisionnement, socle commun

Tout réapprovisionnement dans Odoo passe par le même moteur. Un besoin (procurement) se formule toujours de la même façon : il faut telle quantité, de tel produit, à tel emplacement, pour telle date. Ce besoin est ensuite résolu par une route, elle-même composée de règles (stock.rule), qui décident du document généré : une commande d'achat (Acheter), un ordre de fabrication (Fabriquer), ou un transfert interne (Transférer).

Les différents « déclencheurs » de réappro ne sont donc que des façons différentes de créer ce besoin. La route décide ensuite comment on le couvre. C'est la clé pour ne pas confondre le déclenchement (quand / combien) et la couverture (achat, fabrication, transfert).

Les déclencheurs de besoin

On peut ranger les mécanismes natifs en trois familles.

Sur seuil — les règles de réapprovisionnement. C'est le mécanisme min/max, porté par le modèle stock.warehouse.orderpoint. Un enregistrement = un couple produit / emplacement, avec sa quantité min, sa quantité max, sa quantité multiple, son mode de déclenchement et ses jours de visibilité. À retenir : l'« orderpoint », c'est exactement la règle de réappro elle-même, rien de plus.

Sur demande — le MTO (Make To Order). C'est une route posée sur le produit ou la catégorie. Ici, pas de stock tampon : chaque besoin réel (ligne de vente, composant d'OF) génère immédiatement son propre approvisionnement, systématiquement, quel que soit le stock. Se combine avec la route de couverture : MTO + Acheter, ou MTO + Fabriquer. On le réserve plutôt aux produits qu'on ne veut jamais stocker (sur-mesure, coûteux, périssable), et souvent à la fabrication quand on veut automatiser la création de l'OF.

Manuel. Deux entrées :

• le bouton Réapprovisionner sur la fiche produit notamment (et aussi dans les ventes en cliquant sur la petite montagne rouge ou verte) : assistant qui propose quantité, route et date
• le rapport de réapprovisionnement (Inventaire → Opérations → Réapprovisionnement), vue consolidée où l'on valide les besoins en masse.

Prévisionnel sur ventes/consommations passées: 

Depuis une commande d'achat, cliquer sur catalogue

Puis activer "SUGGERER" et adapter les curseurs pour voir les produits à réapprovisionner pour CE fournisseur.

Dans tous les cas, la demande de prix / commande d'achat est générée en brouillon : on garde la main pour confirmer ou non.

Le planificateur

Le cron « MRP : Planificateur » orchestre le tout en arrière-plan. Il évalue les orderpoints en mode auto, traite les besoins en attente et génère les documents (PO, OF, transferts) selon les routes et les délais. On peut aussi le lancer à la main. Sans lui, les règles en mode auto ne produisent rien.

Comment une règle min/max calcule vraiment

C'est le point le plus contre-intuitif, parce que le raisonnement d'Odoo diffère du calcul « comptable » d'un solde prévisionnel.

Le prévisionnel dans une fenêtre, pas à l'infini

La règle ne regarde pas tout le prévisionnel futur. Elle se place à une date prévue = date du jour + somme des délais (fournisseur, sécurité, jours d'achat). Seule la demande dont l'échéance tombe avant cette date prévue est comptée dans le « Prévu » de la règle. Une commande dont la date de livraison est postérieure à la date prévue n'est pas prise en compte — elle n'apparaît que dans le rapport prévisionnel long terme (le graphe).

Conséquence directe : sans délais, la date prévue = aujourd'hui, et une commande à J+10 reste « invisible » pour la règle jusqu'à ce que la date prévue rattrape son échéance. Le déclenchement se produit quand la date prévue rejoint l'échéance de la commande, pas au moment où la commande est confirmée.

On remplit jusqu'au max, en tenant compte du déficit

La formule est :

Quantité à commander = Max − Prévu

où le Prévu = stock à la main + entrées − sorties dans la fenêtre. Le min n'est que le seuil de déclenchement ; le max est la cible de remplissage.

Exemple. Stock 10, règle min 5 / max 15, une commande de 15 entre dans la fenêtre. Le prévu tombe à 10 − 15 = −5. Comme −5 < 5, ça déclenche, et la quantité à commander = 15 − (−5) = 20. Vérification physique : 10 + 20 − 15 = 15, soit le max. On ne revient donc pas au min après une vente, mais bien au max — et il reste ensuite tout le tampon (max − min) à consommer avant le prochain ordre. La seule chose qui modifie ce chiffre est la quantité multiple, qui arrondit au multiple supérieur.

Jours de visibilité et jours d'horizon

Deux réglages élargissent la fenêtre de déclenchement, mais ne décalent aucune date :

Les jours de visibilité (visibility_days sur l'orderpoint) regardent plus loin pour grouper des besoins proches — mais seulement si un réappro est déjà déclenché à la date prévue. Ils grossissent un ordre, ils ne l'anticipent pas.

Les jours d'horizon définissent la fenêtre du rapport de réappro, qui fait remonter les produits plus tôt dans la liste.

À ne pas confondre avec les délais de planification ci-dessous, qui eux décalent réellement les dates.

Les délais : la planification à rebours

Odoo cale toute la chaîne à rebours, en partant de la date de livraison saisie sur la commande (ce que voit l'utilisateur). Il recule ensuite délai après délai jusqu'à la deadline de la commande d'achat ou la date de début de l'ordre de fabrication.

Chaîne aval (commune)

Date de livraison − délai de sécurité de vente = date d'expédition. − délais de route (étapes internes : préparation, expédition…) = date de besoin en stock. C'est ce point de besoin que les chaînes achat et fabrication doivent couvrir.

Chaîne amont — achat

Besoin + coussin de sécurité achat, puis délai fournisseur, puis jours pour acheter (temps de transformer la demande de prix en commande) donnent la deadline de la commande fournisseur.

Chaîne amont — fabrication

Besoin + sécurité fabrication, puis délai de fabrication, puis en amont l'appro des composants (matérialisée par les jours pour préparer l'OF sur la nomenclature) — chaque composant ayant lui-même son propre délai fournisseur.

Le délai client, à part

Le délai client travaille dans l'autre sens : il ne recule pas une date, il projette la date de livraison suggérée au moment de la confirmation du devis (date de confirmation + délai client = date de livraison proposée).

Récapitulatif des délais

Deux points d'attention transverses : les durées sont en jours calendaires (Odoo ne saute pas les week-ends nativement, hors calendrier de ressources) ; et manufacturing_lead / days_to_prepare_mo sont les deux seuls dont le nom technique peut varier légèrement selon la version, leur emplacement UI restant stable.

La politique d'expédition

Ce n'est pas un délai mais un arbitre. Sur une commande multi-produits, la politique d'expédition (picking_policy sur sale.order, onglet Autres informations : « au plus tôt » vs « quand tout est prêt ») décide si l'on retient le délai le plus court ou le plus long. Défaut paramétrable, corrigeable par commande.

Ce qu'on peut, ou non, industrialiser par catégorie

Routes : oui, natif par catégorie

La catégorie de produit (product.category) porte un champ route_ids (section Logistique). Appliquer une route sur une catégorie applique ses règles à tous les produits de la catégorie, et les configurations de la catégorie « All » sont héritées par les sous-catégories (sauf surcharge). MTO, Fabriquer, Acheter, Dropship sont donc attachables par catégorie, et la hiérarchie de catégories permet d'affiner.

Trois limites natives à garder en tête : l'application est uniforme (une catégorie applique sa route à tous ses produits, pas de conditionnel natif « ceux qui ont une nomenclature → Fabriquer, les autres → Acheter ») ; le moteur choisit la route par priorité (règle du produit et de la catégorie + parents, puis entrepôt ; la plus haute priorité gagne) ; et le tri Acheter / Fabriquer reste in fine dicté produit par produit par la présence d'une nomenclature et/ou d'un fournisseur.

Délais : rien de natif par catégorie

Aucun délai produit n'est portable au niveau catégorie. Le délai client, le délai fournisseur et le délai de fabrication se règlent tous au niveau produit (ou ligne fournisseur / nomenclature). Il n'existe pas de champ « délai par catégorie » qui se propagerait.

Les seuls leviers natifs de masse sont l'édition en lot dans la vue liste (sélection multiple → Modifier) et l'import. Pour une logique réellement « par catégorie », il faut passer par une action serveur / automatisation groupée par categ_id.

À retenir en une phrase

Le déclenchement (seuil, demande, manuel) et la couverture (achat, fabrication, transfert) sont deux choses distinctes ; les règles min/max remplissent jusqu'au max en ne voyant que la demande de leur fenêtre ; toute la planification se cale à rebours depuis la date de livraison ; et si les routes s'industrialisent par catégorie, les délais, eux, ne se posent qu'au produit — d'où l'importance d'une catégorisation propre en préalable de tout paramétrage de masse.