Confirmer une commande d'achat engage l'entreprise auprès d'un tiers, déclenche une réception attendue et, souvent, une facture. Odoo laisse ce geste à tout utilisateur du groupe Achats, et le rend immédiat.
Dix-sept modules communautaires l'encadrent : un état intermédiaire, des paliers d'approbation, des blocages motivés, et une visibilité qui cesse d'être totale.
Résumé
purchase_order_approved ajoute un état « Approuvé » entre la demande de prix et la commande : une première validation acte l'accord sans rien déclencher, une seconde engage réellement. purchase_tier_validation branche le moteur générique de validation par paliers — un ou plusieurs valideurs désignés par des règles conditionnelles. purchase_order_approval_block bloque l'approbation d'une demande de prix tant qu'un motif de blocage n'est pas levé par une personne habilitée.
purchase_security cloisonne : il crée des équipes d'achat et limite la visibilité des commandes, là où Odoo standard montre tout à tout utilisateur du groupe Achats. purchase_partner_selectable_option empêche de choisir comme fournisseur un contact qui n'en est pas un.
Le reste trace et signale : motif d'annulation obligatoire, confirmation au moment d'annuler, sous-états, étiquettes, archivage des commandes closes, date d'approbation redevenue modifiable, note interne jamais imprimée, avertissement fournisseur affiché en permanence et messages d'avertissement prédéfinis, propriétaire assigné reporté sur la réception, et correction du représentant achats sur les commandes générées automatiquement.
L'essentiel
- Un état « Approuvé » intermédiaire : valider sans encore déclencher la logistique.
- La validation par paliers avec des règles conditionnelles — montant, fournisseur, type.
- Un blocage d'approbation motivé, levé par une personne habilitée.
- Des équipes d'achat et une visibilité restreinte : le standard montre tout à tous.
- Un motif d'annulation obligatoire, choisi dans une liste configurable.
- Une note interne qui n'apparaît jamais sur le document envoyé au fournisseur.
- L'avertissement fournisseur affiché en permanence, et non une fois sur deux.
- Le représentant achats corrigé sur les commandes générées par une règle de réapprovisionnement.
Ce que ces modules ajoutent à l'instance
| Module | Rôle | Version | Licence |
|---|---|---|---|
purchase_order_approved | État « Approuvé » intermédiaire | 18.0.1.0.2 | AGPL-3 |
purchase_tier_validation | Validation par paliers | 18.0.1.0.0 | AGPL-3 |
purchase_order_approval_block | Blocage motivé de l'approbation | 18.0.1.1.0 | AGPL-3 |
purchase_security | Équipes d'achat et visibilité restreinte | 18.0.1.1.2 | AGPL-3 |
purchase_cancel_reason | Motif d'annulation obligatoire | 18.0.1.0.0 | AGPL-3 |
purchase_cancel_confirm | Confirmation avant annulation | 18.0.1.0.0 | AGPL-3 |
purchase_substate | Sous-états de la commande | 18.0.1.0.0 | AGPL-3 |
purchase_tag | Étiquettes colorées sur la commande | 18.0.1.1.0 | AGPL-3 |
purchase_order_archive | Archivage des commandes closes | 18.0.1.0.0 | AGPL-3 |
purchase_order_date_approve_editable | Date d'approbation modifiable | 18.0.1.0.0 | AGPL-3 |
purchase_order_internal_note | Onglet de note interne | 18.0.1.0.0 | AGPL-3 |
purchase_warn_message | Avertissement fournisseur permanent | 18.0.1.0.0 | AGPL-3 |
purchase_warn_option | Messages d'avertissement prédéfinis | 18.0.1.0.1 | LGPL-3 |
purchase_order_owner | Propriétaire assigné reporté sur la réception | 18.0.1.0.0 | LGPL-3 |
purchase_representative | Représentant achats corrigé | 18.0.1.0.0 | AGPL-3 |
purchase_commercial_partner | Entité commerciale du fournisseur | 18.0.1.0.0 | AGPL-3 |
purchase_partner_selectable_option | Fournisseurs sélectionnables filtrés | 18.0.1.0.0 | AGPL-3 |
Quatre menus de configuration sont ajoutés, tous dans Achats ▸ Configuration : motifs de blocage d'approbation, motifs d'annulation, étiquettes, et équipes d'achat.
Trois façons de contrôler une approbation
Elles ne s'excluent pas, et elles ne traitent pas le même risque.
| Module | Ce qu'il impose | Risque traité |
|---|---|---|
purchase_order_approved | Un état intermédiaire : valider, puis engager | L'engagement logistique déclenché trop tôt |
purchase_tier_validation | L'accord d'un ou plusieurs valideurs désignés | La dépense non autorisée |
purchase_order_approval_block | La levée d'un blocage par une personne habilitée | La commande qui part malgré un point en suspens |
L'état « Approuvé »
La première confirmation fait passer la commande à « Approuvé » sans générer de mouvement de stock. La seconde l'engage réellement. Entre les deux, l'entreprise a acté son accord sans que l'entrepôt attende une réception ni que le fournisseur soit officiellement engagé.
C'est la réponse au cas fréquent d'une commande validée en interne mais pas encore envoyée — parce qu'on attend une confirmation de prix, une date, un accord de budget.
Les paliers
purchase_tier_validation branche le moteur générique décrit dans la fiche base_tier_validation : des définitions de paliers conditionnelles — au-delà d'un montant, pour un fournisseur donné, pour un type de commande — imposent l'accord d'un ou plusieurs valideurs avant confirmation.
Le blocage motivé
purchase_order_approval_block empêche l'approbation d'une demande de prix tant qu'un motif de blocage y figure. Tant qu'il n'est pas levé par une personne habilitée, la confirmation déclenche le mécanisme d'exception — donc un refus explicite, avec sa raison.
Le module s'appuie sur les règles d'exception d'achat : c'est le même moteur qui dit pourquoi une commande ne peut pas passer.
Qui voit quoi, et qui peut être fournisseur
Dans Odoo standard, tout utilisateur du groupe Achats voit toutes les commandes d'achat. Pour une entreprise à plusieurs sites, plusieurs filiales ou plusieurs acheteurs spécialisés, c'est une exposition inutile — les conditions négociées avec un fournisseur sont une information sensible.
purchase_security introduit un modèle d'équipe d'achat et restreint la visibilité des commandes par utilisateur ou par équipe. Les équipes se configurent dans Achats ▸ Configuration ▸ Purchase Teams.
purchase_partner_selectable_option traite un risque plus prosaïque : une case sur la fiche contact exclut un partenaire de la liste des fournisseurs sélectionnables. Les clients, les contacts techniques et les salariés cessent d'apparaître dans une liste où ils n'ont rien à faire — et où une sélection accidentelle crée une commande sur le mauvais tiers.
purchase_commercial_partner complète en portant sur la commande l'entité commerciale du fournisseur — la société mère qui facture — ce qui permet de regrouper les analyses par groupe plutôt que par établissement.
Tracer, classer, signaler
Les traces
purchase_cancel_reasonimpose un motif d'annulation choisi dans une liste configurable : changement de fournisseur, besoin devenu obsolète, erreur de saisie. C'est ce qui rend les annulations analysables.purchase_cancel_confirmajoute une confirmation avant l'annulation, pour éviter le clic malheureux dans une liste.purchase_substateajoute des sous-états à l'intérieur d'un statut, pour suivre une attente de prix ou une vérification technique.purchase_tagajoute des étiquettes colorées : type d'achat, urgence, projet, service demandeur.purchase_order_archivearchive les commandes verrouillées ou annulées, pour garder la liste lisible sur une base volumineuse.
purchase_order_date_approve_editable rend par ailleurs la date d'approbation modifiable, alors qu'Odoo la fige. C'est utile pour refléter la réalité d'un accord donné avant la saisie — et c'est à encadrer, puisque cette date sert d'horodatage.
Les signaux
| Module | Ce qu'il affiche | Où |
|---|---|---|
purchase_warn_message | L'avertissement configuré sur le fournisseur, en bandeau permanent | Le formulaire de commande |
purchase_warn_option | Des messages d'avertissement prédéfinis et réutilisables | Fiches fournisseur et produit |
purchase_order_internal_note | Un onglet de note interne, jamais imprimée | La commande |
Le premier corrige un comportement standard irrégulier : l'avertissement fournisseur n'apparaît pas toujours, selon la façon dont le formulaire a été rafraîchi. Un fournisseur sous surveillance — litige, retard chronique, encours — doit se signaler à chaque commande.
Le troisième répond à un besoin quotidien : écrire « négocié par téléphone avec Martin, remise acceptée à 7 % » sans que cela parte chez le fournisseur.
Deux corrections techniques qui comptent
Le représentant achats des commandes automatiques
Quand une commande d'achat est générée par une règle de réapprovisionnement, le représentant achats enregistré est souvent l'utilisateur technique qui a lancé le traitement — pas l'acheteur responsable.
purchase_representativecorrige ce défaut connu.
L'effet est direct : les filtres « mes commandes », les relances et les statistiques par acheteur redeviennent justes. Sans ce module, une part des commandes appartient à un utilisateur qui n'existe pas dans l'organigramme.
Le propriétaire de la marchandise
purchase_order_owner ajoute un propriétaire assigné sur la commande, reporté sur le bon de réception généré. Le cas métier : acheter de la marchandise qui appartient à un tiers — dépôt-vente, consignation, achat pour le compte d'un client.
La gestion du stock en consignation et la propriété des marchandises sont des sujets connexes, traités côté entrepôt dans stock : négatif, zones et rangement.
Limites connues
- L'état « Approuvé » ajoute une étape : elle doit correspondre à une réalité d'organisation, sinon elle est cliquée machinalement.
- Paliers et blocages se recouvrent : l'un autorise la dépense, l'autre retient une commande incomplète. Les mélanger use les valideurs.
purchase_securityrestreint la visibilité : prévoir les profils qui doivent voir au-delà de leur équipe (comptabilité, direction).- La date d'approbation modifiable affaiblit l'horodatage : à réserver à un rôle identifié.
purchase_cancel_confirmest peu documenté dans le relevé : son comportement exact se vérifie sur le dépôt.- Les avertissements prédéfinis dépendent d'un socle du dépôt
server-ux, à installer avec eux.
Identité technique
Les dix-sept modules viennent du dépôt OCA purchase-workflow, branche 18.0 — 107 modules au total —, en licence AGPL-3 sauf purchase_warn_option et purchase_order_owner (LGPL-3). Quatre s'appuient sur des socles génériques du dépôt server-ux : validation par paliers, sous-états, confirmation d'annulation, options d'avertissement.
Les familles voisines : les demandes d'achat en amont, et achats : types, remises et blocages pour le circuit de commande.
Questions fréquentes
À quoi sert un état « Approuvé » avant l'état Commande ?
À séparer l'accord interne de l'engagement. Avec purchase_order_approved, la première validation fait passer la commande à « Approuvé » sans générer de mouvement de stock ; la seconde l'engage réellement. C'est le cas de la commande validée en interne mais pas encore envoyée, faute d'un prix, d'une date ou d'un accord de budget.
Peut-on exiger l'accord d'un responsable au-delà d'un montant ?
Oui, avec purchase_tier_validation : des définitions de paliers conditionnelles — montant, fournisseur, type de commande — imposent l'accord d'un ou plusieurs valideurs avant confirmation. Le moteur est le même que pour les demandes d'achat et les autres documents.
Tous les acheteurs voient-ils toutes les commandes ?
Dans Odoo standard, oui : tout utilisateur du groupe Achats voit toutes les commandes d'achat. purchase_security introduit des équipes d'achat et restreint la visibilité par utilisateur ou par équipe — utile dès qu'il y a plusieurs sites, filiales ou acheteurs spécialisés, car les conditions négociées sont une information sensible.
Comment garder une remarque interne hors du bon de commande ?
purchase_order_internal_note ajoute un onglet note interne qui n'apparaît jamais sur le document imprimé envoyé au fournisseur. C'est l'endroit où écrire le contexte d'une négociation ou une consigne pour la réception, sans risque de le transmettre.
Pourquoi les commandes générées automatiquement ont-elles le mauvais acheteur ?
Parce qu'Odoo enregistre comme représentant achats l'utilisateur qui a déclenché le traitement d'approvisionnement — souvent un utilisateur technique. purchase_representative corrige ce défaut connu, ce qui rétablit les filtres « mes commandes », les relances et les statistiques par acheteur.
Se faire accompagner
L'approbation d'achat est le domaine où l'on confond le plus souvent trois questions : qui a le droit de commander, qui autorise la dépense, et qu'est-ce qui empêche une commande incomplète de partir. Un seul dispositif pour les trois produit un circuit lourd que tout le monde contourne.
Nous séparons donc : les droits d'abord, les paliers par montant ensuite, les blocages de qualité en dernier — et nous mesurons le délai moyen d'approbation au bout d'un mois. Un circuit qui rallonge les délais sans réduire les erreurs doit être simplifié. Voir les prestations d'Atalios Consulting, notre méthode ou demander un rappel.
Pour aller plus loin
- Demandes d'achat : exprimer un besoin avant d'engager
- Achats : types, remises et blocages
- Circuits de validation avec base_tier_validation
En résumé
Un état intermédiaire qui sépare l'accord de l'engagement, des paliers d'approbation conditionnels, des blocages motivés, et une visibilité qui cesse d'être totale. S'y ajoutent les traces — motif d'annulation, note interne — et deux corrections techniques dont celle du représentant achats des commandes automatiques. Parlons de votre circuit d'approbation.
