Quand un besoin déclenche un achat — règle de réapprovisionnement, flux tendu, livraison directe —, Odoo décide seul de la commande fournisseur dans laquelle il atterrit. Il fusionne, il regroupe, et il choisit le fournisseur.
Onze modules communautaires reprennent ces décisions, et rétablissent le lien entre la vente d'origine et l'achat qu'elle a provoqué.
Résumé
procurement_purchase_no_grouping donne quatre modes de regroupement des approvisionnements en commandes d'achat, et purchase_line_procurement_group empêche la fusion systématique de deux besoins portant sur le même produit dans une seule ligne. Un troisième module assure la compatibilité de ces réglages avec l'achat de services sous-traités généré depuis une vente.
sale_purchase_force_vendor permet de choisir le fournisseur sur la ligne de vente quand celle-ci déclenche un achat, et purchase_sale_link_by_origin renforce le lien entre commande d'achat et commande de vente en s'appuyant aussi sur le champ d'origine — là où le lien natif ne repose que sur les lignes.
Le reste traite le prix et le confort : une remise générale appliquée à toutes les lignes, un recalcul manuel du prix, de la date et du libellé depuis les informations fournisseur actuelles, la protection du prix négocié contre le recalcul au changement de quantité, la synchronisation du prix sur des mouvements de stock déjà validés, un incoterm d'achat par défaut sur la fiche fournisseur, un tableau de bord par type de commande, et des filtres sur les quantités en attente.
L'essentiel
- Quatre modes de regroupement des approvisionnements, dont « aucun regroupement ».
- Pas de fusion automatique de deux besoins dans la même ligne de commande.
- Le fournisseur choisi sur la ligne de vente, et respecté par l'achat généré.
- Le lien vente-achat par l'origine, en plus du lien natif par les lignes.
- Une remise générale appliquée en une saisie à toutes les lignes.
- Le prix négocié protégé du recalcul quand la quantité change.
- Le prix synchronisé sur les mouvements déjà validés quand il est corrigé après coup.
- Des filtres sur les quantités en attente de réception ou de facturation.
Ce que ces modules ajoutent à l'instance
| Module | Rôle | Version |
|---|---|---|
procurement_purchase_no_grouping | Quatre modes de regroupement | 18.0.1.0.1 |
procurement_purchase_sale_no_grouping | Compatibilité avec les services sous-traités | 18.0.1.0.0 |
purchase_line_procurement_group | Pas de fusion de besoins dans une ligne | 18.0.1.0.0 |
sale_purchase_force_vendor | Fournisseur imposé depuis la ligne de vente | 18.0.2.0.0 |
purchase_sale_link_by_origin | Lien vente-achat renforcé par l'origine | 18.0.1.0.0 |
purchase_order_general_discount | Remise générale sur la commande | 18.0.1.0.0 |
purchase_order_price_recalculation | Recalcul du prix, de la date et du libellé | 18.0.1.0.0 |
purchase_order_qty_change_no_recompute | Prix protégé du recalcul | 18.0.1.0.0 |
purchase_stock_price_unit_sync | Prix synchronisé sur les mouvements validés | 18.0.1.0.0 |
purchase_partner_incoterm | Incoterm et adresse d'incoterm par défaut | 18.0.1.0.1 |
purchase_order_type_dashboard | Tableau de bord par type de commande | 18.0.1.0.0 |
purchase_open_qty | Filtres sur les quantités en attente | 18.0.1.0.1 |
Un seul menu ajouté : Achats ▸ Dashboard, le tableau de bord en cartes par type de commande.
Décider comment les besoins deviennent des commandes
Par défaut, Odoo regroupe les approvisionnements : deux besoins pour le même produit chez le même fournisseur fusionnent dans une seule ligne d'une seule commande. C'est efficace pour l'acheteur, et destructeur pour la traçabilité — on ne sait plus quel besoin a produit quelle quantité.
| Mode | Effet |
|---|---|
| Regroupement standard | Le comportement d'Odoo : fusion des lignes |
| Regroupement sans fusion de lignes | Une seule commande, mais une ligne par besoin |
| Aucun regroupement | Une commande par besoin |
| Regroupement par catégorie | Des commandes distinctes selon la catégorie de produit |
Le deuxième mode est le plus utile dans la pratique : on garde une commande unique pour le fournisseur — donc une négociation et une facture — tout en conservant une ligne par besoin, donc la trace de l'origine.
Le troisième se justifie en production à la commande ou en affaire : chaque projet a sa commande fournisseur, et la réception se rattache sans ambiguïté.
purchase_line_procurement_group traite la même question sous un autre angle, en empêchant la fusion de deux approvisionnements dans la même ligne, et un module de compatibilité garantit que ces réglages fonctionnent avec les services sous-traités générés depuis une commande de vente.
Le mécanisme de groupe d'approvisionnement, côté vente, est décrit dans automatiser le cycle de vente : c'est la même notion, vue depuis l'autre extrémité du flux.
Relier la vente et l'achat qu'elle provoque
Imposer le fournisseur depuis la vente
sale_purchase_force_vendor permet de choisir manuellement le fournisseur sur une ligne de commande de vente quand cette ligne déclenche un approvisionnement en achat — flux tendu ou livraison directe. La commande d'achat générée respecte ce choix.
Le besoin est courant : le client exige une marque précise, ou le commercial a négocié un délai avec un fournisseur particulier. Sans ce module, Odoo applique le fournisseur par défaut du produit et la promesse faite au client ne tient pas.
Retrouver l'un depuis l'autre
purchase_sale_link_by_origin renforce le lien entre commande d'achat et commande de vente en s'appuyant aussi sur le champ d'origine, là où le lien natif ne repose que sur les lignes d'approvisionnement.
La question « cette commande fournisseur, c'est pour quel client ? » est posée dix fois par jour dans une entreprise qui travaille en flux tendu. Le lien natif y répond mal dès que le flux passe par plusieurs étapes ; ce module le complète par l'origine, qui survit aux transformations.
Prix : remise, recalcul et correction tardive
| Module | Ce qu'il fait | Quand c'est utile |
|---|---|---|
purchase_order_general_discount | Applique une remise en pourcentage à toutes les lignes en une saisie | Le fournisseur accorde une remise globale |
purchase_order_price_recalculation | Recalcule prix, date planifiée et libellé depuis les informations fournisseur actuelles | Une commande ancienne qu'on réactive |
purchase_order_qty_change_no_recompute | Empêche le recalcul du prix quand seule la quantité change | Protéger un prix négocié |
purchase_stock_price_unit_sync | Synchronise le prix sur les mouvements de stock déjà validés | Le prix est corrigé après la réception |
Les deux derniers forment un couple instructif. Le troisième empêche un recalcul non voulu ; le quatrième propage une correction voulue jusqu'aux mouvements déjà validés — sans quoi la valorisation du stock reste à l'ancien prix, et la marge est fausse.
C'est le même motif que côté vente, où la remise négociée est protégée du recalcul automatique. Les deux problèmes ont la même cause : Odoo recalcule par défaut, et ce défaut est raisonnable jusqu'au jour où un prix a été négocié.
purchase_partner_incoterm complète côté conditions : un incoterm d'achat par défaut et une adresse d'incoterm sur la fiche fournisseur, repris à la création de la commande ou au changement de fournisseur. Pour une entreprise qui importe, c'est une ressaisie de moins et une ambiguïté de moins sur la responsabilité du transport.
Voir où en sont les achats
purchase_order_type_dashboardajoute un tableau de bord en cartes organisé par type de commande : les acheteurs voient d'un coup d'œil l'état de chaque famille d'achat.purchase_open_qtyajoute des champs calculés et des filtres de recherche pour identifier les commandes ayant encore des quantités en attente de réception ou de facturation.
Le second est l'outil de la revue hebdomadaire des achats : la liste des commandes qui ne sont pas closes, avec la raison — il manque de la marchandise, ou il manque une facture. Deux problèmes différents, deux interlocuteurs différents.
Le type de commande d'achat lui-même, qui structure ce tableau de bord, est traité dans achats : types, remises et blocages.
Limites connues
- Changer le mode de regroupement modifie un comportement de fond : à éprouver sur une copie, car il affecte toutes les commandes générées automatiquement.
- « Aucun regroupement » multiplie les commandes fournisseur : bon pour la traçabilité, lourd pour l'acheteur et parfois mal vu du fournisseur.
- Le fournisseur forcé depuis la vente contourne la logique de tarif : le prix retenu peut ne pas être le meilleur disponible.
- La remise générale écrase les remises de ligne : vérifier le comportement attendu avant de l'ouvrir aux acheteurs.
- La synchronisation du prix touche des mouvements validés : c'est une écriture de stock, à tester avant mise en production.
- Le recalcul des lignes écrase les ajustements manuels : c'est son rôle, et cela se dit avant de donner le bouton.
Identité technique
Les onze modules viennent du dépôt OCA purchase-workflow, branche 18.0, tous en licence AGPL-3. Trois dépendent de modules reliant vente et achat (sale_purchase, sale_purchase_stock), et sale_purchase_force_vendor s'appuie en plus sur un module de traçabilité des mouvements chaînés du dépôt des ventes.
Le dépôt purchase-workflow est désormais entièrement couvert : 107 modules, répartis en six fiches — demandes d'achat, approbation, facturation fournisseur, réceptions, tarifs fournisseurs et lignes de commande.
Questions fréquentes
Peut-on empêcher Odoo de fusionner les besoins dans une seule ligne ?
Oui : procurement_purchase_no_grouping offre quatre modes — regroupement standard, regroupement sans fusion de lignes, aucun regroupement, ou regroupement par catégorie. Le deuxième est le plus utile : une seule commande pour le fournisseur, mais une ligne par besoin, donc la trace de l'origine.
Peut-on imposer un fournisseur depuis une commande de vente ?
Oui, avec sale_purchase_force_vendor : le fournisseur se choisit sur la ligne de vente qui déclenche l'approvisionnement, et la commande d'achat générée le respecte. Sans lui, Odoo applique le fournisseur par défaut du produit — et la promesse faite au client sur une marque ou un délai ne tient pas.
Comment savoir à quel client correspond une commande fournisseur ?
purchase_sale_link_by_origin renforce le lien entre commande d'achat et commande de vente en s'appuyant aussi sur le champ d'origine, là où le lien natif ne repose que sur les lignes d'approvisionnement — lien qui se perd dès que le flux passe par plusieurs étapes.
Pourquoi le prix d'achat se recalcule-t-il tout seul ?
Parce qu'Odoo recalcule le prix unitaire dès que la quantité ou l'unité change, ce qui écrase un prix négocié. purchase_order_qty_change_no_recompute supprime ce recalcul. À l'inverse, quand on veut répercuter une correction de prix, purchase_stock_price_unit_sync la propage jusqu'aux mouvements de stock déjà validés.
Comment suivre les commandes non soldées ?
purchase_open_qty ajoute des champs calculés et des filtres pour repérer les commandes ayant des quantités en attente de réception ou de facturation — deux problèmes distincts, avec deux interlocuteurs distincts. C'est l'outil de la revue hebdomadaire des achats.
Se faire accompagner
Le regroupement des approvisionnements est un réglage invisible qui décide de la traçabilité de toute la chaîne. Beaucoup d'entreprises découvrent son effet le jour où elles cherchent à savoir quel chantier a consommé quelle réception — et constatent que trois besoins ont fusionné dans une ligne.
Nous le traitons donc tôt, et sur une copie : le mode « sans fusion de lignes » convient à la grande majorité des cas, et il se décide avant que l'historique ne soit construit. Voir les prestations d'Atalios Consulting, notre méthode ou demander un rappel.
Pour aller plus loin
- Lignes de commande d'achat : emplacement, lot et unité
- Automatiser le cycle de vente
- Achats : types, remises et blocages
En résumé
Le réglage invisible qui décide de la traçabilité : quatre modes de regroupement des besoins en commandes fournisseur, contre un seul en standard. S'y ajoutent le fournisseur imposé depuis la vente, le lien vente-achat retrouvé par l'origine, et le prix négocié enfin protégé du recalcul. Parlons de vos flux d'approvisionnement.
