Un bon de livraison par commande, c'est la règle d'Odoo. Dans un entrepôt réel, deux commandes du même client partant le même jour chez le même transporteur devraient voyager ensemble — et un transfert trop gros devrait pouvoir être coupé.
Seize modules communautaires décident de ces regroupements et de ces scissions, puis rendent l'avancement visible.
Résumé
Quatre modules regroupent : un index technique qui rend les requêtes de regroupement rapides, le regroupement par client et par transporteur dans un seul bon, l'ajout d'un critère de date pour ne fusionner que ce qui part le même jour, et une colle avec la politique de livraison forcée par type d'opération.
Trois scindent : un bouton de scission d'un transfert non validé, un mode par dimensions — le premier transfert respecte un volume donné — et un mode par nombre de kits. Deux autres agissent en masse : confirmer et transférer plusieurs bons d'un coup, et relever la priorité des transferts amont dès qu'un transfert aval commence à être traité.
Le reste rend lisible : un type métier calculé sur chaque transfert, des étapes de préparation configurables en plus de l'état standard, un pourcentage d'avancement affiché en barre, et quatre boutons qui ouvrent ce qui est lié — reliquats, retours, lots utilisés, transferts d'origine d'une chaîne.
L'essentiel
- Un bon de livraison pour plusieurs commandes du même client chez le même transporteur.
- Un critère de date pour ne fusionner que ce qui part ensemble.
- La scission d'un transfert sans le valider — par quantité, par dimensions ou par kits.
- La priorité des transferts amont relevée dès que l'aval démarre.
- Des étapes de préparation configurables, en plus de l'état d'Odoo.
- Un pourcentage d'avancement affiché en barre dans les listes.
- Quatre accès directs : reliquats, retours, lots utilisés, transferts d'origine.
- Un index PostgreSQL dédié — sans lui, le regroupement ralentit toute la base.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Regroupement | stock_picking_group_by_base, stock_picking_group_by_partner_by_carrier, stock_picking_group_by_partner_by_carrier_by_date, stock_picking_group_by_partner_by_carrier_force_move_type | 4 |
| Scission | stock_split_picking, stock_split_picking_dimension, stock_split_picking_kit | 3 |
| Action en masse et priorité | stock_picking_mass_action, stock_picking_consolidation_priority | 2 |
| Lisibilité | stock_picking_kind, stock_picking_stage, stock_picking_progress | 3 |
| Accès directs | stock_picking_show_backorder, stock_picking_show_return, stock_picking_show_lot, stock_picking_show_linked | 4 |
Un seul menu de configuration : Inventaire ▸ Configuration ▸ Étape de préparation. Tous les autres enrichissent le formulaire de transfert, ses listes ou le moteur de regroupement.
Regrouper : un colis plutôt que trois
Trois commandes passées dans la semaine par le même client, livrées à la même adresse par le même transporteur, produisent trois bons de livraison — donc potentiellement trois expéditions facturées. C'est le comportement standard, et il coûte directement de l'argent.
stock_picking_group_by_basecrée d'abord un index PostgreSQL sur la table des transferts : sans lui, les requêtes de regroupement deviennent lentes dès que la base grossit.stock_picking_group_by_partner_by_carrierfusionne dans un seul bon les mouvements issus de commandes différentes partageant adresse de livraison et transporteur.stock_picking_group_by_partner_by_carrier_by_dateajoute le critère de date : deux mouvements ne fusionnent que s'ils doivent partir le même jour — en tenant compte du fuseau du client.- Un module de colle assure la compatibilité avec la politique de livraison forcée par type d'opération.
Le critère de date est indispensable dès qu'on travaille avec des dates d'engagement : sans lui, une commande à livrer dans trois semaines se retrouve fusionnée avec une commande du jour, et la première bloque la seconde.
Ce regroupement est l'inverse exact du découpage décrit dans les dates de livraison : l'un éclate une commande en plusieurs livraisons, l'autre réunit plusieurs commandes en une. Les deux se combinent, et il faut savoir lequel prime.
Scinder un transfert trop gros
| Module | Mode de scission | Cas d'usage |
|---|---|---|
stock_split_picking | Par sélection ou quantité, sans valider le transfert | Une partie seulement est prête à partir |
stock_split_picking_dimension | Par dimensions : le premier transfert respecte un volume donné | Remplir un véhicule ou un contenant |
stock_split_picking_kit | Par nombre de kits | Expédier dix ensembles complets sur les trente commandés |
Le premier répond au besoin le plus fréquent : livrer ce qui est disponible sans attendre le reste, et sans valider un transfert partiel qui créerait un reliquat mal maîtrisé.
Le deuxième est l'outil du chargement : on coupe pour remplir un camion, une palette, un conteneur. Il s'appuie sur le calcul de volume des transferts.
Le troisième concerne les produits vendus en ensembles : couper au milieu d'un kit n'a pas de sens, et c'est pourtant ce que fait une scission par quantité.
stock_picking_mass_action complète par le geste inverse : confirmer et transférer plusieurs bons sélectionnés en une seule opération, depuis la liste.
Prioriser et suivre l'avancement
La priorité qui remonte la chaîne
stock_picking_consolidation_priorityaugmente automatiquement la priorité des transferts amont — réceptions, prélèvements, mouvements internes — dès qu'un transfert aval de la même chaîne commence à être traité.
C'est une mécanique d'ordonnancement fine et rarement implémentée : quand l'expédition commence, tout ce qui l'alimente devient urgent. Sans elle, l'opérateur du prélèvement traite dans l'ordre d'arrivée, et l'expédition attend la seule ligne manquante.
Rendre l'état lisible
stock_picking_kindcalcule un type métier sur chaque transfert — livraison client, réception fournisseur, retour, mouvement interne. Utile pour filtrer et pour les automatisations, là où le type d'opération est paramétrable et donc variable d'une instance à l'autre.stock_picking_stageajoute des étapes configurables en complément de l'état standard : « en attente de contrôle », « emballé », « chargé ». L'état d'Odoo dit où en est la mécanique ; l'étape dit où en est le travail.stock_picking_progresscalcule un pourcentage d'avancement sur les mouvements et les transferts, affiché en barre de progression dans les listes.
La barre d'avancement change la supervision d'un entrepôt : un chef d'équipe voit en un écran ce qui est à 10 % et ce qui est à 90 %, au lieu de lire des états binaires.
Six briques de liaison entre la vente et la livraison
Ces modules n'ont pas d'écran propre : ils transportent une information de la commande jusqu'au transfert, ou corrigent un calcul. Leur absence se voit sur le bon de livraison, jamais dans une liste de modules.
| Module | Ce qu'il transporte ou corrige |
|---|---|
delivery_procurement_group_carrier | Le transporteur choisi sur la commande, reporté vers le groupe d'approvisionnement puis vers les transferts — brique fondatrice du regroupement par transporteur |
procurement_auto_create_group_carrier | Colle entre la création automatique de groupe d'approvisionnement et le transporteur porté par ce groupe |
delivery_total_weight_from_packaging | Le poids réel des conditionnements dans le calcul du poids des mouvements, transferts et colis — et non le seul poids unitaire du produit |
product_customerinfo_picking | Le code et le nom produit du client affichés dans les lignes d'opération du transfert |
sale_line_returned_qty | La quantité déjà retournée par le client, affichée sur chaque ligne de commande de vente |
sale_line_returned_qty_mrp | La correction de ce calcul pour les produits vendus en kits — installation automatique |
sale_order_global_stock_route | Une route logistique choisie en en-tête de commande et appliquée à toutes ses lignes |
Le troisième corrige une erreur silencieuse et coûteuse : un poids calculé sur le seul produit, sans ses emballages, sous-estime chaque expédition. Le transporteur, lui, pèse le colis réel — et refacture l'écart.
Le quatrième prolonge jusqu'à l'entrepôt la logique du code produit client : l'opérateur qui prépare voit la référence que le client lira sur son bon de réception.
Le dernier évite une saisie répétitive : choisir une route particulière — expédition directe, passage par une plateforme — en tête de commande plutôt que sur chacune de ses lignes.
Quatre boutons qui font gagner des minutes
| Module | Ce qu'il ouvre depuis le transfert |
|---|---|
stock_picking_show_backorder | Les reliquats qui en découlent, dans un onglet dédié |
stock_picking_show_return | Les transferts de retour liés, et le bouton pour remonter au transfert d'origine |
stock_picking_show_lot | Les lots et numéros de série créés ou utilisés sur les lignes |
stock_picking_show_linked | Les transferts d'origine d'une route chaînée |
Ces quatre modules ne changent aucun comportement : ils évitent des recherches. Sur un flux chaîné à trois étapes, retrouver le transfert amont d'une expédition demande sinon une recherche dans la liste des mouvements — ce que personne ne fait sous pression.
Le deuxième mérite une mention : retrouver l'origine d'un retour est la première question d'un litige client, et la réponse déclenche tout le reste — avoir, remplacement, réclamation transporteur.
Les retours eux-mêmes sont traités dans préparations : lots, retours et liens facture et ventes et stock.
Limites connues
- Le regroupement sans critère de date fusionne des expéditions lointaines : installer le module de date avec celui de regroupement.
- L'index PostgreSQL est une modification de base : indispensable, mais à appliquer lors d'une fenêtre de maintenance sur une base volumineuse.
- Regroupement et découpage par date s'opposent : décider lequel prime avant d'installer les deux.
- La scission par dimensions suppose des volumes produit renseignés.
- Les étapes de préparation s'ajoutent à l'état standard : sans règle d'usage, elles ne sont pas remplies.
- La priorité automatique modifie l'ordonnancement : à éprouver sur une copie avant une base en production.
Identité technique
Les seize modules viennent du dépôt OCA stock-logistics-workflow, branche 18.0, tous en licence AGPL-3. Le regroupement par client et transporteur dépend de plusieurs briques — groupe d'approvisionnement par transporteur, extraction d'entrepôt, livraison — installées avec lui ; la scission par dimensions dépend du calcul de volume du dépôt stock-logistics-warehouse.
Les familles voisines : les vagues de préparation et préparations : lots, retours et liens facture.
Questions fréquentes
Peut-on livrer plusieurs commandes dans un seul bon ?
Oui : stock_picking_group_by_partner_by_carrier fusionne dans un seul bon de livraison les mouvements issus de commandes différentes partageant la même adresse et le même transporteur. Ajoutez le module de critère de date, sans lequel une commande à livrer dans trois semaines se retrouve fusionnée avec une expédition du jour.
Pourquoi un index PostgreSQL est-il nécessaire ?
Parce que le regroupement interroge la table des transferts sur plusieurs critères — partenaire, emplacements, type d'opération. stock_picking_group_by_base crée l'index correspondant ; sans lui, ces requêtes ralentissent à mesure que la base grossit, et le ralentissement touche tout l'entrepôt.
Comment expédier une partie d'un transfert sans le valider ?
Avec stock_split_picking : un bouton Split scinde un transfert non validé en deux, sans passer par la validation partielle qui créerait un reliquat. Deux extensions ajoutent une scission par dimensions (remplir un camion) et par nombre de kits (ne pas couper un ensemble en deux).
Comment faire remonter l'urgence dans la chaîne logistique ?
stock_picking_consolidation_priority relève automatiquement la priorité des transferts amont dès qu'un transfert aval de la même chaîne commence à être traité. Sans ce mécanisme, le prélèvement traite dans l'ordre d'arrivée pendant que l'expédition attend une seule ligne.
Quelle différence entre l'état et l'étape d'un transfert ?
L'état d'Odoo — brouillon, en attente, disponible, fait — décrit la mécanique. L'étape ajoutée par stock_picking_stage décrit le travail réel : en attente de contrôle, emballé, chargé. Les deux coexistent, et l'étape n'a de valeur que si une règle d'usage dit qui la met à jour et quand.
Se faire accompagner
Regrouper et scinder sont deux décisions opposées qui coexistent dans tout entrepôt : on regroupe pour économiser du transport, on scinde pour livrer plus vite. Installer les deux sans trancher la priorité produit des comportements imprévisibles — et des opérateurs qui défont à la main ce que le système vient de faire.
Nous posons donc la règle d'abord : qu'est-ce qui prime, le coût de transport ou le délai ? Puis nous paramétrons, et nous mesurons le nombre de colis par client et par semaine avant et après. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- Vagues de préparation : constituer, planifier, imprimer
- Dates de livraison, reliquats et annulations
- Transport et logistique avec Odoo
En résumé
Deux décisions opposées et nécessaires : regrouper plusieurs commandes dans un colis quand elles partagent client, transporteur et date ; scinder un transfert trop gros par volume ou par kits. Avec, autour, la priorité qui remonte la chaîne et l'avancement enfin visible. Parlons de vos expéditions.
