Entre la commande envoyée et la marchandise rangée, il se passe tout ce qui fait le quotidien d'un approvisionneur : un fournisseur qui livre en trois fois, un conteneur qui arrive avec deux semaines de retard, une prestation à faire valider avant d'être payée.
Dix-huit modules communautaires traitent ce segment — dont un dispositif complet de recette de travaux avec évaluation et pénalités.
Résumé
Trois modules installent un statut de réception : au niveau de la commande (rien reçu / partiellement / entièrement, avec forçage manuel possible), au niveau de la ligne, et un module de colle qui réconcilie cette logique avec le champ natif d'Odoo. purchase_reception_notify prévient les suiveurs de la commande dès que la marchandise est reçue.
Côté logistique : purchase_delivery_split_date génère un bon de réception par date planifiée, purchase_manual_delivery supprime la création automatique et laisse créer les réceptions ligne par ligne au fil des livraisons, purchase_all_shipments fait apparaître les transferts chaînés sur le bouton de réception, et purchase_order_supplier_return gère un retour fournisseur par une ligne de quantité négative.
Pour l'import : des champs de date de départ et d'arrivée estimées, un suivi complet des conteneurs (transitaire, dates réelles, type), un seuil de franco de port par fournisseur qui bloque la confirmation en dessous, un délai de transport distinct du délai fournisseur, et un calendrier d'ouverture du fournisseur pour que les délais se comptent en jours ouvrés.
L'essentiel
- Un statut de réception par ligne, et pas seulement au niveau de la commande.
- Une réception créée manuellement, ligne par ligne, au fil des livraisons réelles.
- Un bon de réception par date planifiée quand les lignes ont des dates différentes.
- La recette de travaux : un document de validation intercalé avant la réception ou la facturation.
- Une évaluation du fournisseur sur des critères configurables — délai, qualité produit, qualité de service.
- Des pénalités de retard calculées et comptabilisées automatiquement.
- Le suivi des conteneurs : transitaire, dates estimées et réelles, type de conteneur.
- Le franco de port par fournisseur, bloquant la confirmation sous le seuil.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Statut de réception | purchase_reception_status, purchase_reception_status_line, purchase_stock_reception_status, purchase_reception_notify | 4 |
| Création des réceptions | purchase_manual_delivery, purchase_delivery_split_date, purchase_receipt_expectation, purchase_all_shipments, purchase_order_supplier_return | 5 |
| Import et transport | purchase_container, purchase_order_etd_eta, purchase_fop_shipping, vendor_transport_lead_time, supplier_calendar | 5 |
| Recette de travaux | purchase_work_acceptance, purchase_work_acceptance_evaluation, purchase_work_acceptance_invoice_plan, purchase_work_acceptance_late_fines | 4 |
Les menus ajoutés : Achats ▸ Commandes ▸ Work Acceptance, Achats ▸ Commandes ▸ Containers, Achats ▸ Configuration ▸ Container Types, ainsi que la configuration et le rapport d'évaluation des recettes.
Savoir ce qui est arrivé, ligne par ligne
| Module | Niveau | Apport |
|---|---|---|
purchase_reception_status | Commande | Rien reçu / partiellement / entièrement, avec forçage manuel |
purchase_reception_status_line | Ligne | Le même statut, ligne par ligne |
purchase_stock_reception_status | — | Colle avec le champ natif d'Odoo |
purchase_reception_notify | — | Message aux suiveurs dès la réception effective |
Le statut par ligne est ce qui transforme une relance en information utile : au lieu d'écrire « votre commande est partiellement livrée », on écrit « il manque les deux références suivantes » — et le fournisseur répond.
La notification automatique traite un autre irritant : le demandeur d'un achat n'a aucune raison de surveiller l'entrepôt. Un message dans le fil de discussion de la commande au moment de la réception effective suffit à fermer la boucle.
Le module de colle mérite une mention : Odoo possède son propre champ de statut de réception, et les deux logiques devaient être réconciliées. C'est un détail d'implémentation, mais il explique pourquoi trois modules sont nécessaires là où on en attendait un.
Décider quand et comment la réception est créée
La réception manuelle
purchase_manual_delivery supprime la création automatique des bons de réception à la confirmation et fournit un assistant pour les créer ligne par ligne, au fur et à mesure que le fournisseur annonce ses livraisons.
C'est le bon mode pour les achats à long délai, où une réception créée à la confirmation reste ouverte pendant des mois et pollue les écrans de l'entrepôt. C'est aussi le symétrique exact de ce que sale_manual_delivery fait côté vente.
Le découpage par date
purchase_delivery_split_date génère un bon de réception distinct par date planifiée présente sur les lignes. Un fournisseur qui annonce trois dates produit trois réceptions attendues, chacune à sa date — ce qui rend le planning de l'entrepôt réaliste.
Deux outils de visibilité
purchase_all_shipmentsfait afficher au bouton de réception tous les transferts chaînés — règles de poussée, réceptions groupées — et pas seulement le transfert généré directement par la commande. Sur un flux en plusieurs étapes, c'est ce qui évite de croire la marchandise perdue.purchase_receipt_expectationest un module technique extensible : il ne change rien par lui-même, il fournit le mécanisme permettant à d'autres modules de piloter la façon dont les réceptions sont créées à l'approbation.
Le retour fournisseur
purchase_order_supplier_return permet de retourner des produits en créant une ligne de quantité négative sur la commande d'achat, et fait en sorte que la quantité reçue de cette ligne soit correctement mise à jour une fois le transfert effectué.
C'est la mécanique symétrique de la demande de retour client — avec une différence : côté achat, le retour vit dans la commande elle-même.
Importer : conteneurs, délais et franco
Cinq modules s'adressent aux entreprises qui achètent loin.
| Module | Ce qu'il apporte |
|---|---|
purchase_container | Un suivi des conteneurs : référence, transitaire, dates estimées et réelles de départ et d'arrivée, type de conteneur — rattaché aux commandes et aux réceptions |
purchase_order_etd_eta | Des champs ETD / ETA (départ et arrivée estimés) et une note de calendrier d'expédition |
purchase_fop_shipping | Un seuil de franco de port par fournisseur et par société, bloquant la confirmation en dessous |
vendor_transport_lead_time | Le délai fournisseur séparé du délai de transport sur la fiche fournisseur du produit |
supplier_calendar | Un calendrier d'ouverture du fournisseur : les délais se comptent en jours ouvrés, pas en jours calendaires |
Les deux derniers corrigent la même illusion : un délai de 30 jours annoncé par un fournisseur asiatique n'est ni 30 jours calendaires, ni un délai unique — c'est un délai de production plus un délai de transport, et le fournisseur ne travaille pas pendant ses congés.
Séparer les deux composantes permet de recalculer correctement une date d'arrivée quand le mode de transport change — passer de la mer à l'air modifie le délai de transport, pas celui de production.
Le franco de port, lui, est un blocage assumé : commander 400 € chez un fournisseur dont le franco est à 500 € coûte des frais de port qui annulent la marge. Le module le refuse par défaut, et c'est une bonne valeur par défaut.
La recette de travaux : valider avant de payer
C'est le dispositif le plus structurant de ce lot, et il s'adresse aux achats de prestations et de travaux.
purchase_work_acceptancecrée un document de recette intercalé entre la commande et sa réception en stock ou sa facturation : seuls les produits et services effectivement reçus et acceptés passent à l'étape suivante.purchase_work_acceptance_evaluationajoute une évaluation qualitative sur des critères configurables — délai, qualité du produit, qualité de service — avec son rapport dédié.purchase_work_acceptance_invoice_planrelie la recette à l'échéancier de facturation : une échéance se déclenche quand la recette correspondante est acceptée.purchase_work_acceptance_late_finescalcule la pénalité de retard à facturer au fournisseur et génère la pièce comptable.
L'enchaînement complet — recette, évaluation, échéance de facturation, pénalité — est rare dans l'écosystème Odoo. Il correspond à la commande publique et aux marchés de travaux, où la réception contradictoire conditionne le paiement.
L'évaluation mérite une remarque : elle produit la notation fournisseur que beaucoup d'entreprises tiennent dans un tableur. Adossée aux recettes réelles plutôt qu'à une impression annuelle, elle devient opposable lors d'une renégociation.
La pénalité automatique est à manier avec soin : générer une pièce comptable de pénalité suppose que le contrat la prévoie et que la relation commerciale la supporte. Le module calcule ; la décision reste humaine. Voir aussi l'approbation des achats pour le contrôle en amont.
Limites connues
- Trois modules pour un statut de réception : le module de colle avec le champ natif est indispensable, son oubli produit deux statuts divergents.
- La réception manuelle déplace la charge : quelqu'un doit créer les réceptions, sinon rien n'arrive dans l'entrepôt.
- Le franco de port bloque par défaut : prévoir qui peut passer outre, sinon les achats urgents sont paralysés.
- Le calendrier fournisseur demande des données : les horaires de chaque fournisseur, ce qui n'a de sens que pour les principaux.
- La recette de travaux ajoute une étape : elle se justifie pour les prestations et les travaux, rarement pour l'achat de fournitures.
- Les pénalités de retard génèrent une pièce comptable : à n'activer que si le contrat les prévoit.
Identité technique
Les dix-huit modules viennent du dépôt OCA purchase-workflow, branche 18.0, en licence AGPL-3 sauf supplier_calendar (LGPL-3). La plupart dépendent de purchase_stock ; supplier_calendar s'appuie en plus sur le module de ressources d'Odoo pour les calendriers de travail.
Les familles voisines : l'approbation des achats, la facturation fournisseur et les demandes d'achat.
Questions fréquentes
Peut-on savoir quelle ligne d'une commande reste à recevoir ?
Oui : purchase_reception_status_line calcule un statut de réception par ligne — rien reçu, partiellement, entièrement. Au lieu de relancer un fournisseur sur « votre commande est partiellement livrée », on lui indique les références manquantes, ce à quoi il peut répondre.
Comment éviter des réceptions ouvertes pendant des mois ?
purchase_manual_delivery supprime la création automatique des bons de réception à la confirmation et permet de les créer ligne par ligne, au fil des livraisons annoncées. C'est le mode adapté aux achats à long délai, où une réception créée trop tôt pollue les écrans de l'entrepôt.
Qu'est-ce qu'une recette de travaux dans Odoo ?
Un document intercalé entre la commande d'achat et sa réception ou sa facturation, fourni par purchase_work_acceptance : seuls les produits et services effectivement reçus et acceptés passent à l'étape suivante. Trois extensions y ajoutent l'évaluation du fournisseur, le déclenchement d'échéances de facturation et le calcul de pénalités de retard.
Peut-on noter ses fournisseurs sur des critères objectifs ?
purchase_work_acceptance_evaluation permet d'évaluer chaque recette sur des critères configurables — délai, qualité du produit, qualité de service — avec un rapport dédié. Adossée aux réceptions réelles plutôt qu'à une impression annuelle, cette notation devient opposable en renégociation.
Comment gérer un délai fournisseur à l'import ?
En le décomposant : vendor_transport_lead_time sépare le délai fournisseur du délai de transport sur la fiche fournisseur du produit, et supplier_calendar fait compter les délais en jours ouvrés du fournisseur plutôt qu'en jours calendaires. Changer de mode de transport ne modifie alors que la composante concernée.
Se faire accompagner
La réception est l'endroit où un achat devient une dette : tant que la marchandise n'est pas reçue et acceptée, la facture ne devrait pas être payée. Beaucoup de PME paient sur la foi d'un bon de livraison signé par quelqu'un qui n'a rien contrôlé.
Nous construisons donc le circuit dans l'ordre inverse du paiement : qui accepte, sur quels critères, et ce qui se passe en cas de retard. La recette de travaux ne se justifie pas partout, mais le statut de réception par ligne, oui. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- Facturation fournisseur : échéanciers, acomptes et cadres
- Ventes et stock : livraisons, blocages et retours
- Transport et logistique avec Odoo
En résumé
Le statut de réception descend à la ligne, la réception se crée quand le fournisseur livre vraiment, les conteneurs et les délais d'import se suivent, et les prestations passent par une recette qui conditionne le paiement — avec évaluation du fournisseur et pénalités calculées. Parlons de vos réceptions.
