Dans Odoo, le premier document d'achat est la demande de prix — autrement dit, on s'adresse déjà à un fournisseur. Entre le besoin exprimé par un atelier et la consultation du marché, il manque une étape : la demande d'achat.
C'est elle qui porte la question « avons-nous besoin de ça, et qui l'autorise ? » avant la question « à qui l'achète-t-on ? ».
Résumé
purchase_request crée un document autonome, saisi par n'importe quel collaborateur, listant des besoins en matériel ou en service. Une fois approuvée, la demande alimente les commandes d'achat — manuellement ou via les mécanismes d'approvisionnement — et garde le lien avec elles.
Autour, dix modules la rendent exploitable : un type porteur de sa propre séquence et de son type d'opération, le service RH du demandeur repris automatiquement, des sous-états pour suivre à l'intérieur d'un statut, des règles de blocage qui empêchent le passage en approbation tant qu'une anomalie subsiste, une validation par paliers configurable, une confirmation obligatoire au refus avec motif, et un pont vers les appels d'offres.
Deux modules enfin changent le vocabulaire d'achat lui-même : purchase_no_rfq masque la notion de demande de prix pour les organisations qui ne consultent pas, et purchase_rfq_number donne aux demandes de prix une numérotation distincte de celle des commandes confirmées.
L'essentiel
- Un document avant la commande : le besoin s'exprime sans s'adresser à un fournisseur.
- Des types de demande portant chacun sa séquence, son type d'opération et ses options.
- Le service du demandeur repris automatiquement, pour filtrer et regrouper par département.
- Des règles de blocage qui empêchent le passage en approbation tant qu'une anomalie subsiste.
- Une validation par paliers : un ou plusieurs niveaux d'approbation, par utilisateur ou par groupe.
- Un refus qui demande confirmation et, en option, un motif.
- Un pont vers les appels d'offres pour les besoins qui justifient une consultation.
- Deux options de vocabulaire : masquer la demande de prix, ou lui donner sa propre numérotation.
Ce que ces modules ajoutent à l'instance
| Module | Rôle | Version | Licence |
|---|---|---|---|
purchase_request | Le document de demande d'achat | 18.0.2.5.1 | LGPL-3 |
purchase_request_type | Types, séquences et type d'opération | 18.0.1.0.1 | AGPL-3 |
purchase_request_department | Service RH du demandeur | 18.0.1.0.0 | AGPL-3 |
purchase_request_substate | Sous-états dans un statut | 18.0.1.0.0 | AGPL-3 |
purchase_request_exception | Règles de blocage | 18.0.1.1.0 | AGPL-3 |
purchase_request_tier_validation | Validation par paliers | 18.0.1.1.1 | AGPL-3 |
purchase_request_cancel_confirm | Confirmation et motif au refus | 18.0.1.0.0 | AGPL-3 |
purchase_request_to_requisition | Pont vers les appels d'offres | 18.0.1.0.0 | AGPL-3 |
purchase_requisition_line_description | Description d'achat sur les lignes d'accord | 18.0.1.0.0 | AGPL-3 |
purchase_no_rfq | Masquer la notion de demande de prix | 18.0.1.0.2 | AGPL-3 |
purchase_rfq_number | Numérotation distincte des demandes de prix | 18.0.1.0.0 | AGPL-3 |
Le module principal installe une application complète : un menu racine « Demandes d'achat » avec ses demandes et ses lignes, en plus d'entrées dans le menu Achats. Les satellites ajoutent leurs écrans de configuration dans Achats ▸ Configuration.
Pourquoi une demande d'achat, et pas une commande
| Demande d'achat | Demande de prix / commande | |
|---|---|---|
| Qui la saisit | N'importe quel collaborateur | Le service achats |
| Ce qu'elle exprime | Un besoin | Une consultation ou un engagement |
| Fournisseur | Pas nécessairement connu | Obligatoire |
| Engagement | Aucun | Réel dès la confirmation |
| Ce qui la suit | Une approbation, puis une ou plusieurs commandes | Une réception et une facture |
La première ligne est la raison d'être du module : donner à l'atelier, au bureau d'études ou à l'administratif un endroit où écrire ce dont ils ont besoin, sans leur donner le droit d'engager l'entreprise.
Sans ce document, le besoin circule par courriel ou oralement — et le service achats passe son temps à reconstituer qui a demandé quoi, pour quel projet, et avec quel accord. La demande d'achat remplace ce flux informel par une pièce traçable.
Une fois approuvée, elle alimente les commandes d'achat et garde le lien avec elles : on sait, depuis une commande, de quel besoin elle découle, et depuis un besoin, ce qui a été commandé.
Typer, router, suivre
Les types de demande
purchase_request_type ajoute un type configurable, et c'est le module qui structure réellement le dispositif. Chaque type porte :
- sa propre séquence de numérotation — les demandes d'investissement et les demandes de consommables ne se mélangent plus ;
- un type d'opération par défaut, donc un entrepôt et un circuit logistique de destination ;
- des options propres au circuit d'approbation.
La séquence par type est ce qui rend les demandes lisibles dans une organisation à plusieurs sites ou plusieurs natures de dépenses.
Le service demandeur
purchase_request_department associe automatiquement la demande au service RH du demandeur. Le filtrage et le regroupement par département deviennent possibles — c'est la maille d'analyse que la direction financière demande en premier : qui dépense quoi.
Les sous-états
purchase_request_substate ajoute une barre de sous-états à l'intérieur du statut principal : brouillon, à approuver, approuvé. On suit ainsi une vérification technique, une attente de devis, un arbitrage budgétaire, sans créer de statut supplémentaire.
C'est la même mécanique que les sous-états côté ventes, appuyée sur le même socle générique.
Contrôler avant d'approuver
Deux modules complémentaires, qui traitent deux risques différents.
Les règles de blocage
purchase_request_exception attache aux demandes et à leurs lignes un mécanisme d'exceptions personnalisables : des règles qui empêchent le passage à l'état « à approuver » tant qu'une anomalie subsiste — ou qui permettent de forcer avec justification.
Exemples de règles qu'on écrit en pratique : pas de compte analytique renseigné, montant supérieur à un seuil sans devis joint, produit non référencé, service demandeur absent. Chacune évite un aller-retour entre les achats et le demandeur.
Le moteur sous-jacent et ses limites sont décrits dans base_exception.
La validation par paliers
purchase_request_tier_validation branche le moteur générique d'approbation : un ou plusieurs niveaux définis par utilisateur, par groupe ou par règle — typiquement par montant. La demande ne progresse pas tant que les valideurs n'ont pas statué.
La combinaison des deux est la bonne pratique : les règles de blocage traitent la qualité de la demande, la validation par paliers traite l'autorisation de dépenser. Confondre les deux produit des circuits d'approbation qui servent à corriger des saisies, ce qui use les valideurs.
Le refus
purchase_request_cancel_confirm impose une confirmation lors du refus d'une demande, et permet d'en saisir le motif. Un refus accidentel sur une liste de demandes est vite arrivé ; et un refus sans motif génère systématiquement un appel du demandeur.
Passer à l'achat : commandes, appels d'offres, vocabulaire
Vers un appel d'offres
purchase_request_to_requisition établit un pont vers les accords d'achat d'Odoo — appels d'offres et accords-cadres : un assistant permet de transformer des lignes de demande en consultation fournisseurs.
C'est le bon circuit pour les besoins significatifs : au lieu de commander au fournisseur habituel, on consulte. Et purchase_requisition_line_description complète en affichant la description d'achat du produit sur les lignes d'accord, et pas seulement son nom — ce qui compte quand la description porte des spécifications techniques.
Deux choix de vocabulaire
| Module | Pour qui | Effet |
|---|---|---|
purchase_no_rfq | Les organisations qui ne consultent pas avant d'acheter | Masque le menu des demandes de prix et renomme les états : tout est une commande |
purchase_rfq_number | Celles qui consultent souvent | Donne aux demandes de prix une séquence distincte des commandes confirmées |
Les deux sont exclusifs dans l'esprit, et chacun correspond à une maturité d'organisation. Le premier simplifie l'interface pour une PME qui commande à des fournisseurs référencés ; le second structure une fonction achats qui met en concurrence.
Le second est l'équivalent, côté achats, de la numérotation distincte des devis décrite dans devis et commandes.
Limites connues
- La demande d'achat est une application de plus : elle n'a de sens que si les demandeurs y ont accès et l'utilisent — sinon le besoin continue de circuler par courriel.
- Le service demandeur suppose le module RH installé et des fiches employés à jour.
- Validation par paliers et règles de blocage se confondent facilement : l'une autorise la dépense, l'autre contrôle la saisie. Les mélanger use les valideurs.
purchase_no_rfqmodifie le vocabulaire de l'application entière : décision d'organisation, pas réglage d'affichage.- Le pont vers les appels d'offres dépend du module standard
purchase_requisition_stock, qui doit être installé. - Une numérotation distincte se décide au démarrage : la changer après coup laisse un historique hétérogène.
Identité technique
| Module | Dépend de |
|---|---|
purchase_request | purchase_stock |
purchase_request_type | purchase_request |
purchase_request_department | hr, purchase_request |
purchase_request_substate | base_substate, purchase_request |
purchase_request_exception | base_exception, purchase_request |
purchase_request_tier_validation | base_tier_validation, purchase_request |
purchase_request_to_requisition | purchase_requisition_stock |
Les onze modules viennent du dépôt OCA purchase-workflow, branche 18.0 — 107 modules au total. Les autres familles sont traitées dans achats : types, remises et blocages et dans les fiches voisines.
Questions fréquentes
Quelle différence entre une demande d'achat et une demande de prix ?
La demande d'achat exprime un besoin interne, saisie par n'importe quel collaborateur, sans fournisseur ni engagement. La demande de prix s'adresse déjà à un fournisseur. Entre les deux, il y a l'approbation : c'est précisément l'étape que le document ajoute, et qu'Odoo standard ne connaît pas.
Peut-on faire approuver une demande selon son montant ?
Oui, avec purchase_request_tier_validation, qui branche le moteur générique de validation par paliers : un ou plusieurs niveaux définis par utilisateur, par groupe ou par règle — le montant étant le critère le plus courant. La demande ne progresse pas tant que les valideurs n'ont pas statué.
Comment éviter des demandes incomplètes ?
Avec purchase_request_exception : des règles de blocage empêchent le passage à l'état « à approuver » tant qu'une anomalie subsiste — compte analytique manquant, devis absent au-delà d'un seuil, produit non référencé — avec la possibilité de forcer en justifiant. C'est du contrôle de saisie, à distinguer de l'autorisation de dépenser.
Peut-on analyser les demandes par service ?
Oui : purchase_request_department associe automatiquement chaque demande au service RH du demandeur, ce qui permet de filtrer et de regrouper par département. C'est la maille que la direction financière demande en premier. Le module suppose l'application RH installée et des fiches employés à jour.
Comment simplifier Odoo pour une PME qui ne consulte pas ses fournisseurs ?
purchase_no_rfq masque le menu des demandes de prix et renomme les états pour que tout document d'achat s'appelle une commande. C'est un choix d'organisation : il convient à une entreprise qui commande à des fournisseurs référencés, et pas à une fonction achats qui met en concurrence.
Se faire accompagner
La demande d'achat est le module qui révèle le plus vite si une organisation est prête : il suppose que les demandeurs saisissent eux-mêmes, et que quelqu'un approuve dans la journée. Déployé sans ces deux conditions, il devient un formulaire que le service achats remplit à la place des autres — c'est-à-dire du travail en plus.
Nous commençons donc par la matrice : qui demande, qui contrôle la saisie, qui autorise la dépense, et à partir de quel montant. Puis nous paramétrons les types, les règles de blocage et les paliers — dans cet ordre. Voir les prestations d'Atalios Consulting, notre méthode ou demander un rappel.
Pour aller plus loin
- Achats : types, remises et blocages
- Circuits de validation avec base_tier_validation
- Les achats et les fournisseurs dans Odoo
En résumé
Le document qui manque entre le besoin et l'engagement : saisi par le demandeur, typé, rattaché à son service, contrôlé par des règles de blocage, approuvé par paliers, puis transformé en commande ou en appel d'offres. Avec deux options de vocabulaire selon que l'entreprise consulte ses fournisseurs ou non. Parlons de votre circuit d'achat.
