Un devis vit : il est envoyé, discuté, repris, parfois annulé, parfois confirmé par quelqu'un qui n'aurait pas dû. Odoo le traite comme un enregistrement qu'on modifie sur place, sans trace des versions ni contrôle de qui transforme un devis en engagement.
Dix-sept modules communautaires encadrent cette vie : versions, motifs, droits, sous-états, priorités.
Résumé
sale_order_revision crée une nouvelle version d'un devis envoyé ou annulé, archive la précédente et conserve le lien — la négociation garde son historique au lieu d'être écrasée. sale_quotation_number donne aux devis une séquence distincte de celle des commandes, pour qu'un numéro dise ce qu'on regarde.
Trois modules verrouillent : sale_confirm_group réserve le droit de confirmer une commande à des groupes choisis, par société ; sale_readonly_security crée un groupe sans lequel un utilisateur ne peut que consulter les ventes ; sale_cancel_confirm et sale_cancel_reason imposent respectivement une confirmation et un motif à l'annulation, tracé dans le fil de discussion.
Le reste affine le suivi : des sous-états par état standard, un sémaphore de remise à trois couleurs sur la ligne, l'avertissement client rendu permanent, l'exigence d'une référence de bon de commande avant confirmation pour certains clients, des étiquettes sur la commande, une priorité propagée jusqu'au bon de livraison, l'archivage des commandes anciennes, le blocage de la duplication d'une commande contenant un produit archivé, et des stratégies de scission d'une commande en deux.
L'essentiel
- Des révisions de devis avec archivage de la version précédente et lien conservé.
- Une séquence distincte pour les devis : le numéro dit si c'est un devis ou une commande.
- Le droit de confirmer réservé à des groupes choisis, par société.
- Un motif d'annulation obligatoire, choisi dans une liste et tracé — y compris en annulation de masse.
- Des sous-états pour suivre finement sans toucher à la machine à états d'Odoo.
- Un sémaphore de remise à trois couleurs sur la ligne : le prix respecte-t-il la politique ?
- La priorité propagée au bon de livraison : l'urgence commerciale devient une urgence logistique.
- La scission d'une commande selon un filtre sur les lignes, utile pour les commandes venues d'un site ou d'un échange de données.
Ce que ces modules ajoutent à l'instance
| Module | Rôle | Version | Dépend de |
|---|---|---|---|
sale_order_revision | Révisions de devis avec historique | 18.0.1.0.1 | base_revision |
sale_quotation_number | Séquence distincte pour les devis | 18.0.1.0.0 | sale_management |
sale_confirm_group | Droit de confirmer réservé | 18.0.1.0.0 | sale |
sale_readonly_security | Groupe de lecture seule sur les ventes | 18.0.1.0.0 | sale |
sale_cancel_reason | Motif d'annulation obligatoire | 18.0.1.0.0 | sale |
sale_cancel_confirm | Confirmation avant annulation | 18.0.1.0.0 | base_cancel_confirm |
sale_substate | Sous-états par état standard | 18.0.1.0.0 | base_substate |
sale_semaphore | Sémaphore de respect de la politique de remise | 18.0.1.0.3 | sale |
sale_order_warn_message | Avertissement client rendu permanent | 18.0.1.0.1 | sale |
sale_require_po_doc | Référence de bon de commande exigée | 18.0.1.0.1 | sale_management |
sale_order_type_confirm_message | Message du type de commande à valider | 18.0.1.0.0 | sale_order_type |
sale_order_tag | Étiquettes sur la commande | 18.0.1.0.0 | crm, sale_management |
sale_order_priority | Priorité propagée à la livraison | 18.0.1.0.0 | sale_stock |
sale_order_archive | Archivage des commandes | 18.0.1.0.0 | sale |
sale_order_restrict_copy_archived_product | Pas de duplication avec produit archivé | 18.0.1.0.0 | sale |
sale_order_split_strategy | Stratégies de scission de commande | 18.0.1.1.0 | sale |
sale_production_state | État de fabrication sur la commande | 18.0.1.0.0 | sale_mrp |
Quatre menus de configuration sont ajoutés : motifs d'annulation, étiquettes de commande, stratégies de scission, et — via un module voisin — les motifs de blocage. Tous dans Ventes ▸ Configuration.
Garder l'historique d'une négociation
Un devis retravaillé trois fois en deux semaines est le quotidien d'un commercial. Dans Odoo, les trois versions sont le même enregistrement modifié : la première proposition n'existe plus.
sale_order_revisionpermet de créer une nouvelle version d'un devis envoyé ou annulé.- La version précédente est archivée automatiquement, et le lien entre les versions est conservé.
- On retrouve donc ce qui a été proposé, à quel prix, et dans quel ordre.
L'intérêt n'est pas documentaire : c'est de pouvoir répondre, six mois plus tard, à « mais vous m'aviez proposé autre chose » — avec le document, pas avec un souvenir.
sale_quotation_number complète en donnant aux devis une séquence de numérotation distincte de celle des commandes confirmées. Odoo réutilise le même numéro du début à la fin ; avec ce module, un numéro dit immédiatement si l'on parle d'un devis ou d'un engagement.
sale_order_archive traite l'autre bout du cycle : les commandes anciennes disparaissent des listes sans être supprimées. Sur une base qui compte des dizaines de milliers de ventes, c'est ce qui rend les écrans de travail à nouveau lisibles.
Qui a le droit de transformer un devis en engagement
Confirmer une commande, c'est engager l'entreprise : du stock réservé, une production lancée, un prix figé. Odoo laisse ce droit à tout utilisateur des ventes.
| Module | Ce qu'il restreint | Granularité |
|---|---|---|
sale_confirm_group | Le droit de confirmer une commande | Par société, à une liste de groupes |
sale_readonly_security | La création, la modification et la suppression | Un groupe dédié ; sans lui, lecture seule |
sale_cancel_confirm | L'annulation, qui demande une confirmation explicite | Toutes les annulations |
sale_cancel_reason | L'annulation sans motif | Motif obligatoire, y compris en masse |
Le deuxième module est celui qui manque le plus souvent : beaucoup d'entreprises veulent que l'atelier, la logistique ou le support voient les commandes sans pouvoir les toucher. Odoo oblige sinon à bricoler des règles d'accès.
Le motif d'annulation, lui, est stocké sur la commande et tracé dans son fil de discussion — y compris lors d'une annulation de masse, ce qui est précisément le moment où l'on perd l'information.
Ces restrictions se combinent avec les circuits de validation décrits dans base_tier_validation : l'un dit qui peut confirmer, l'autre qui doit approuver avant.
Avertir au bon moment
Trois modules placent un signal là où la décision se prend.
Le sémaphore de remise
sale_semaphoreajoute un indicateur à trois couleurs sur les lignes de commande : le prix proposé respecte-t-il la politique de remise définie pour ce produit ou cette catégorie ? Le même indicateur est repris au niveau de la commande.
C'est la meilleure façon connue d'appliquer une politique tarifaire sans bloquer un commercial : il voit qu'il sort du cadre, il peut le faire, et son responsable le voit aussi. Un blocage dur, à l'inverse, produit des contournements — des remises déguisées en lignes de service.
L'avertissement client, rendu permanent
Odoo affiche un avertissement configuré sur un client, mais seulement lorsqu'il a été rafraîchi. sale_order_warn_message le rend visible en permanence sur le formulaire de commande. Un client en litige ou en dépassement d'encours doit se signaler à chaque fois, pas une fois sur deux.
La confirmation qui demande une confirmation
sale_order_type_confirm_message ajoute une étape de validation explicite quand le type de commande porte un message d'avertissement. On rappelle ainsi une règle au moment exact où elle s'applique — « cette commande exige un acompte », « vérifier l'encours ».
sale_require_po_doc marque enfin certains clients comme exigeant une référence de bon de commande ou une documentation avant confirmation. Pour les grands comptes et le secteur public, c'est ce qui évite la facture rejetée des semaines plus tard faute de référence d'engagement.
Suivre, prioriser, scinder
Les sous-états
sale_substate ajoute un sous-état à la commande, défini par état standard — devis, devis envoyé, commande, annulé. On affine le suivi sans toucher à la machine à états d'Odoo, qui est précisément ce qu'il ne faut pas modifier.
Exemples réels : « en attente de plan », « chez le client pour signature », « en attente d'acompte » sur l'état Devis envoyé. Ces informations vivent sinon dans un tableur parallèle.
Les étiquettes et la priorité
sale_order_tagajoute des étiquettes propres aux commandes, indépendantes de celles du CRM : type de vente, origine, circuit particulier.sale_order_priorityajoute une priorité sur la commande et ses lignes, propagée au bon de livraison à la confirmation. L'urgence commerciale cesse de se transmettre par téléphone.
La propagation est le point important : une priorité qui reste dans la commande ne sert à rien, puisque c'est l'entrepôt qui décide de l'ordre des préparations.
Scinder une commande
sale_order_split_strategy définit des stratégies de scission : un filtre sur les lignes, et la commande se coupe en deux. Le cas typique est une commande venue d'un site web ou d'un échange de données qui mélange des articles aux circuits différents — des produits en stock et des produits à fabriquer, par exemple.
Deux modules complètent le tableau : sale_order_restrict_copy_archived_product empêche de dupliquer une commande contenant un produit archivé — la façon la plus courante de revendre un article qui n'est plus au catalogue — et sale_production_state affiche l'état d'avancement de la fabrication sur la commande, calculé depuis les ordres de fabrication générés.
Ce dernier est le complément naturel de la production MRP : le commercial répond au client sans appeler l'atelier.
Limites connues
- Les révisions dépendent d'un socle (
base_revision) partagé avec d'autres documents : son comportement est commun, pas spécifique aux ventes. - Une séquence distincte pour les devis change la numérotation : à décider avant la mise en service, pas après six mois d'historique.
- Le groupe de lecture seule doit être attribué explicitement : tant qu'il ne l'est pas, les utilisateurs perdent leurs droits d'écriture.
- Les sous-états s'ajoutent à l'état standard : sans règle d'usage, ils deviennent un champ de plus que personne ne remplit.
- Le sémaphore signale, il ne bloque pas : c'est un choix, et il suppose que quelqu'un regarde.
- Deux modules sont peu documentés dans le relevé (
sale_cancel_confirm, et le socle de confirmation d'annulation) : comportement à vérifier sur le dépôt.
Identité technique
Les dix-sept modules viennent du dépôt OCA sale-workflow, branche 18.0, tous en licence AGPL-3. Quatre s'appuient sur des socles génériques du dépôt server-ux — révisions, sous-états, confirmation d'annulation — qui servent aussi aux achats et aux autres documents.
Les familles voisines : types de commande et blocages, facturation des ventes, automatiser le cycle de vente.
Questions fréquentes
Peut-on garder l'historique des versions d'un devis ?
Oui, avec sale_order_revision : il crée une nouvelle version d'un devis envoyé ou annulé, archive automatiquement la précédente et conserve le lien entre les versions. Sans lui, les trois propositions successives sont le même enregistrement modifié — et la première n'existe plus.
Comment réserver le droit de confirmer une commande ?
sale_confirm_group restreint, par société, le droit de confirmer à une liste de groupes de sécurité. C'est le contrôle adapté quand confirmer engage réellement l'entreprise — stock réservé, production lancée. Pour un contrôle en lecture seule plus large, sale_readonly_security crée un groupe sans lequel l'utilisateur ne peut que consulter.
Peut-on exiger un motif pour annuler une commande ?
Oui : sale_cancel_reason impose de choisir un motif dans une liste configurable, pour une annulation individuelle comme pour une annulation en masse, et le trace sur la commande et dans son fil de discussion. C'est précisément en annulation de masse que l'information se perd d'habitude.
À quoi sert un sous-état sur une commande ?
À suivre finement sans toucher à la machine à états d'Odoo. sale_substate permet de définir, pour chaque état standard, des sous-états métier : « chez le client pour signature », « en attente d'acompte », « en attente de plan ». Ces informations vivent sinon dans un tableur parallèle.
Comment signaler une commande urgente à l'entrepôt ?
sale_order_priority ajoute une priorité sur la commande et ses lignes, et surtout la propage au bon de livraison généré à la confirmation. Une priorité qui resterait dans la commande ne servirait à rien : c'est l'entrepôt qui décide de l'ordre des préparations.
Se faire accompagner
Ces dix-sept modules répondent presque tous à une question d'organisation déguisée en question technique : qui engage l'entreprise, qui annule, qui révise un prix, et ce qui reste écrit de ces décisions.
Nous traitons donc d'abord la matrice des droits — qui confirme, qui annule, qui voit sans toucher — puis les traces : motif d'annulation, révisions, sous-états. Le paramétrage prend une journée, la discussion en prend deux, et c'est elle qui vaut. Voir les prestations d'Atalios Consulting, notre méthode ou demander un rappel.
Pour aller plus loin
- Ventes : types de commande, workflows et blocages
- Circuits de validation avec base_tier_validation
- Droits utilisateurs et sécurité des accès dans Odoo
En résumé
Le devis cesse d'être un enregistrement qu'on écrase : il a des versions, un numéro qui le distingue d'une commande, un motif quand on l'annule, et un droit de confirmation réservé. S'y ajoutent les signaux qui comptent — sémaphore de remise, avertissement client permanent, priorité transmise à l'entrepôt. Parlons de vos règles commerciales.
