Il reste, dans le plus gros dépôt du catalogue OCA, une poignée de modules qui ne forment pas une famille : une approbation, un ménage automatique, un cloisonnement par équipe, quelques liaisons techniques.
Ils ont pourtant un point commun : chacun répond à une question qu'une entreprise pose au bout de six mois d'utilisation, pas au démarrage.
Résumé
sale_tier_validation applique aux commandes de vente le moteur générique d'approbation à plusieurs niveaux : la confirmation reste bloquée tant que les valideurs désignés n'ont pas donné leur accord. sales_team_security crée un groupe intermédiaire « documents de mon équipe uniquement », qui limite ce qu'un commercial voit aux documents de son équipe.
sale_validity_auto_cancel annule automatiquement les devis périmés après un délai configurable — le ménage que personne ne fait et qui finit par rendre les listes inexploitables. sale_warn_option remplace les messages d'avertissement saisis à la main par des messages prédéfinis réutilisables sur les clients et les produits.
Le reste relie des mécaniques existantes : la disponibilité du stock dans l'assistant de recommandation, les transactions de paiement accessibles depuis la commande, le projet créé avant la confirmation d'une vente de services, une règle d'exception sur les produits réservés à certains clients, l'entrepôt remonté dans l'en-tête du formulaire, un état de livraison calculé réutilisable, une liste de souhaits client, un point d'accès HTTP pour le cache de prix, et une colle d'affichage des libellés produit.
L'essentiel
- L'approbation à plusieurs niveaux sur les commandes, avec blocage de la confirmation.
- Un groupe « mon équipe uniquement » pour cloisonner la visibilité commerciale.
- Les devis périmés annulés automatiquement après un délai configurable.
- Des messages d'avertissement prédéfinis, réutilisables au lieu d'être retapés.
- La disponibilité affichée dans l'assistant de recommandation, avant d'ajouter le produit.
- Le projet et les tâches créés avant la confirmation d'une vente de services.
- Les transactions de paiement accessibles depuis la commande.
- Un point d'accès HTTP pour servir les prix en cache à un site externe.
Ce que ces modules ajoutent à l'instance
| Module | Rôle | Version | Licence |
|---|---|---|---|
sale_tier_validation | Approbation à plusieurs niveaux des commandes | 18.0.1.1.0 | AGPL-3 |
sales_team_security | Visibilité limitée à son équipe | 18.0.1.0.0 | AGPL-3 |
sale_validity_auto_cancel | Annulation des devis périmés | 18.0.1.1.0 | LGPL-3 |
sale_warn_option | Messages d'avertissement prédéfinis | 18.0.1.0.2 | LGPL-3 |
sale_stock_product_recommendation | Disponibilité dans l'assistant de recommandation | 18.0.1.0.0 | AGPL-3 |
sale_timesheet_project_manual | Projet créé avant la confirmation | 18.0.1.0.0 | AGPL-3 |
sale_transaction_form_link | Transactions de paiement depuis la commande | 18.0.1.0.0 | AGPL-3 |
sale_exception_product_sale_manufactured_for | Exception sur produits réservés à des clients | 18.0.1.1.0 | AGPL-3 |
sale_order_warehouse_header | Entrepôt dans l'en-tête, filtres et regroupement | 18.0.1.0.0 | AGPL-3 |
sale_delivery_state | État de livraison calculé, brique réutilisable | 18.0.1.2.1 | AGPL-3 |
sale_wishlist | Liste de souhaits rattachée à un client | 18.0.1.0.0 | AGPL-3 |
pricelist_cache_rest | Point d'accès HTTP pour les prix en cache | 18.0.1.0.0 | AGPL-3 |
web_widget_product_label_section_and_note_full_label_sale | Colle d'affichage des libellés produit | 18.0.1.0.0 | AGPL-3 |
Aucun n'ajoute de menu propre : ils enrichissent la commande, les groupes de sécurité, ou servent de liaison entre deux mécaniques.
Qui approuve, et qui voit quoi
L'approbation à plusieurs niveaux
sale_tier_validation applique aux commandes de vente le moteur générique d'approbation de l'OCA : des niveaux de validation définis par des règles — montant, client, type de commande — et une confirmation bloquée tant que les valideurs désignés n'ont pas statué.
Le moteur lui-même, ses définitions de niveaux et ses pièges sont décrits dans la fiche base_tier_validation. Le module de vente n'est que son application à la commande client.
À distinguer de
sale_confirm_group, qui réserve le droit de confirmer à certains profils. L'approbation dit « quelqu'un d'autre doit donner son accord » ; le droit dit « seuls ceux-là peuvent cliquer ». Les deux se combinent, et ne traitent pas le même risque.
Le cloisonnement par équipe
sales_team_security ajoute un groupe de sécurité intermédiaire — « User: Team Documents Only » — qui restreint la visibilité des documents commerciaux à l'équipe de l'utilisateur.
Le relevé précise une limite importante : dans ce dépôt, le module couvre les contacts ; l'extension aux devis, commandes, pistes et opportunités passe par des modules complémentaires qui ne s'y trouvent pas. À vérifier avant d'annoncer un cloisonnement complet.
Le besoin, lui, est fréquent : plusieurs équipes commerciales sur des territoires ou des gammes distinctes, qui n'ont pas à voir les affaires les unes des autres.
Le ménage et les avertissements
Les devis périmés
sale_validity_auto_cancelannule automatiquement les devis dont la date de validité est dépassée depuis un nombre de jours configurable — brouillons comme devis envoyés, jamais confirmés.
C'est une tâche que personne ne fait : nettoyer les devis morts. Au bout de deux ans, la liste des devis en cours contient surtout des devis qui ne le sont plus, et plus personne ne la regarde — donc les vrais devis en attente passent inaperçus.
Le délai configurable est le bon réglage : un devis périmé depuis trois jours mérite une relance, un devis périmé depuis trois mois mérite une annulation.
Les messages d'avertissement
Odoo permet d'écrire un message d'avertissement sur un client ou un produit — il s'affiche à la saisie. sale_warn_option permet de choisir un message prédéfini dans une liste plutôt que de le retaper.
L'intérêt est la cohérence : « client en litige », « produit à commander par 6 », « vérifier l'encours » doivent dire la même chose partout. Des messages libres finissent par se contredire d'une fiche à l'autre.
Les liaisons qui ferment des angles morts
| Module | Ce qu'il relie | Pourquoi c'est utile |
|---|---|---|
sale_stock_product_recommendation | Recommandation et stock | La disponibilité est visible avant d'ajouter le produit recommandé |
sale_transaction_form_link | Commande et transactions de paiement | Vérifier un paiement en ligne sans quitter la commande |
sale_exception_product_sale_manufactured_for | Règles d'exception et produits réservés | Bloquer la vente d'un produit fabriqué pour un autre client |
sale_timesheet_project_manual | Vente de services et projet | Créer le projet et les tâches avant la confirmation |
Le troisième mérite une explication. Certains produits sont fabriqués pour un client précis — marque blanche, pièce sur plan, série dédiée. Les vendre à un autre est une faute contractuelle, et c'est le genre d'erreur qu'un commercial commet de bonne foi en cherchant du stock disponible. Le module ajoute une règle d'exception qui bloque la commande.
Le quatrième répond à un besoin de société de services : en standard, le projet et ses tâches ne sont créés qu'à la confirmation de la commande. Or on prépare souvent le projet pendant la négociation. Le module ajoute un bouton pour le générer avant.
Restent quatre modules plus discrets :
sale_order_warehouse_headerremonte le champ entrepôt dans l'en-tête du formulaire et ajoute filtre et regroupement par entrepôt dans la recherche — trois minutes d'installation, un confort quotidien pour une entreprise multi-dépôts.sale_delivery_statecalcule un état de livraison sur la commande à partir des quantités livrées : c'est une brique technique, utilisée par d'autres modules, notamment sa colle avec le stock.sale_wishlistétend les ensembles de produits avec une typologie liste de souhaits rattachée à un client — une base pour proposer plus tard ce qu'il avait mis de côté.pricelist_cache_restexpose un point d'accès HTTP en lecture pour récupérer les prix en cache d'un client, à destination d'un site e-commerce ou d'une application tierce. Il s'appuie sur l'authentification par clé d'API.
Ce dernier complète le cache de prix décrit dans remises, prix et tarifs : le cache calcule, le point d'accès sert.
Limites connues
sales_team_securityne couvre pas tout dans ce dépôt : l'extension aux devis, commandes et opportunités passe par des modules complémentaires absents d'ici.- L'annulation automatique des devis est irréversible : choisir le délai avec les commerciaux, et prévenir avant la première exécution.
- L'approbation à plusieurs niveaux se combine mal avec une automatisation : un workflow automatique qui confirme des commandes court-circuite l'intérêt du dispositif.
- Le point d'accès HTTP expose des prix : il demande une clé d'API et une réflexion sur ce qu'on publie.
sale_delivery_stateest une brique technique : seul, il n'apporte rien de visible.- La liste de souhaits est une base, pas une fonctionnalité finie : elle attend un usage qu'on construit.
Identité technique
Les treize modules viennent du dépôt OCA sale-workflow, branche 18.0, en licence AGPL-3 sauf sale_validity_auto_cancel et sale_warn_option (LGPL-3). Cinq dépendent de modules d'autres dépôts : moteur d'approbation et options d'avertissement (server-ux), clé d'API et sérialisation (server-auth, rest-framework), produits réservés à un client (product-attribute).
Le dépôt sale-workflow est désormais entièrement couvert : 172 modules, répartis en dix fiches. La porte d'entrée reste les types de commande et les workflows.
Questions fréquentes
Quelle différence entre approbation et droit de confirmer ?
sale_tier_validation impose qu'un tiers donne son accord avant que la commande puisse être confirmée, selon des règles de montant, de client ou de type. sale_confirm_group réserve le droit de cliquer sur Confirmer à certains profils. Le premier traite le contrôle, le second l'habilitation ; ils se combinent.
Comment nettoyer les devis qui ne seront jamais signés ?
sale_validity_auto_cancel annule automatiquement les devis dont la date de validité est dépassée depuis un nombre de jours configurable — brouillons comme devis envoyés. Sans ce ménage, la liste des devis en cours finit par contenir surtout des devis morts, et les vrais passent inaperçus.
Peut-on limiter la visibilité d'un commercial à son équipe ?
sales_team_security ajoute un groupe intermédiaire « documents de mon équipe uniquement ». Attention : dans ce dépôt, il couvre les contacts ; l'extension aux devis, commandes et opportunités passe par des modules complémentaires qui n'y figurent pas. À vérifier avant d'annoncer un cloisonnement complet.
Peut-on créer le projet avant de confirmer une vente de services ?
Oui, avec sale_timesheet_project_manual : un bouton génère manuellement le projet et les tâches avant la confirmation. En standard, ils ne sont créés qu'à la confirmation — alors que la préparation du projet commence souvent pendant la négociation.
Comment éviter de vendre un produit réservé à un autre client ?
sale_exception_product_sale_manufactured_for ajoute une règle d'exception qui bloque la commande quand le produit est marqué comme fabriqué pour un autre client. C'est une erreur commise de bonne foi par un commercial qui cherche du stock disponible — et une faute contractuelle vis-à-vis du donneur d'ordre.
Se faire accompagner
Ces treize modules répondent à des questions de maturité : qui approuve au-delà d'un certain montant, qui voit quoi, et comment on empêche l'instance de se remplir de documents morts. Ce sont rarement des sujets de démarrage, et toujours des sujets de deuxième année.
Nous les traitons lors des revues d'instance, quand les usages sont stabilisés et que les irritants sont connus : c'est le moment où une règle d'approbation est acceptée, parce qu'elle répond à un incident que tout le monde a en tête. Voir les prestations d'Atalios Consulting, notre méthode ou demander un rappel.
Pour aller plus loin
- Circuits de validation avec base_tier_validation
- Devis et commandes : révisions, annulations et droits
- Remises, prix et tarifs
En résumé
L'approbation à plusieurs niveaux, le cloisonnement par équipe, le ménage automatique des devis périmés et quelques liaisons qui ferment des angles morts — dont la vente interdite d'un produit fabriqué pour un autre client. Avec cette fiche, les 172 modules du dépôt des ventes sont couverts. Parlons de vos règles d'approbation.
