Le cycle de vente standard d'Odoo suppose qu'une commande ressemble à toutes les autres, et qu'un humain la fait avancer à chaque étape. Deux hypothèses fausses dès qu'une entreprise a plusieurs lignes de métier, ou plusieurs centaines de commandes par mois.
Sept modules du dépôt sale-workflow traitent ces deux cas : la typologie des commandes, et leur automatisation. Plus un troisième sujet, moins évident et souvent le plus rentable : les règles de blocage.
Résumé
Sept modules d'un dépôt qui en compte 157 : un type de commande qui porte neuf valeurs par défaut, un workflow pour les flux à fort volume, des règles qui bloquent avant confirmation, une remise globale, et une date d'engagement par ligne.
La règle à retenir tient en une phrase : jamais d'automatisation sans règles de blocage. sale_automatic_workflow seul valide et facture les commandes aberrantes à la chaîne — les deux modules se posent ensemble, ou pas du tout.
L'essentiel
sale_order_type: un type de commande porte 9 valeurs par défaut — entrepôt, route, séquence, journal, conditions de paiement, liste de prix, incoterm, commercial, équipe.sale_automatic_workflow: automatise validation, courriel, facture, paiement et verrouillage. Conçu pour les flux à fort volume — le dépôt cite les connecteurs e-commerce.sale_exception: bloque la confirmation d'une commande qui enfreint une règle, avec possibilité d'ignorer pour un utilisateur habilité.sale_order_general_discount: une remise globale répercutée sur chaque ligne, avec exclusion par produit.sale_order_line_date: une date d'engagement par ligne, propagée aux mouvements de stock — 1 seul champ ajouté.sale_commercial_partner: regrouper les commandes par entité commerciale, pour le reporting B2B.
Ce que ces modules ajoutent à l'instance
| Module | Modèles étendus | Champs | Menus | Version |
|---|---|---|---|---|
sale_order_type | 11 | 39 | 1 | 18.0.1.4.0 |
sale_automatic_workflow | 5 | 42 | 2 | 18.0.1.2.0 |
sale_exception | 5 | 29 | 1 | 18.0.2.3.2 |
sale_order_general_discount | 5 | 16 | 0 | 18.0.1.0.2 |
sale_commercial_partner | 3 | 8 | 0 | 18.0.1.2.0 |
sale_order_line_date | 2 | 1 | 0 | 18.0.1.0.2 |
sale_commission_oca | — | — | — | — |
sale_order_line_date est le module le plus économe de tout notre catalogue : un champ. Et c'est l'un des plus utiles en négoce, pour une raison qu'on verra plus bas.
À l'inverse, sale_order_type touche 11 modèles : c'est le signe d'un module qui s'insère profondément — commande, facture, livraison, journal, partenaire, équipe commerciale.
sale_order_type : les lignes de métier, en un champ
L'idée est simple et son effet considérable : un type de commande regroupe un jeu de paramètres par défaut, appliqués automatiquement dès que le type est choisi.
| Ce que le type porte | Ce que cela évite |
|---|---|
| Entrepôt | Expédier depuis le mauvais site |
| Route | Un cheminement logistique incohérent |
| Séquence de numérotation | Des commandes de natures différentes dans la même série |
| Journal de facturation | Des ventes export dans le journal domestique |
| Conditions de paiement | Un délai qui ne correspond pas au canal |
| Liste de prix | Un tarif qui ne correspond pas au type de client |
| Incoterm | Une ambiguïté sur qui paie le transport |
| Commercial | Une commission mal attribuée |
| Équipe commerciale | Un reporting faussé |
Le dépôt propose une image juste : les types de commande sont des « lignes de métier » — vente standard, export, avoir, vente au comptoir. Et un type par défaut peut être associé à chaque partenaire, ce qui supprime même le geste de sélection.
L'avertissement de conflit de liste de prix illustre le soin du module : quand le type impose un tarif différent de celui du client, il le signale au lieu de trancher silencieusement.
C'est le module que nous installons le plus souvent dans ce domaine, et le premier à envisager quand une entreprise a deux activités commerciales distinctes dans la même instance.
sale_automatic_workflow : pour les flux où personne ne clique
Celui-ci est conçu pour un cas précis, et il faut le dire parce qu'il détermine s'il vous concerne : les flux à fort volume avec peu d'intervention manuelle. Le dépôt mentionne explicitement son usage par les connecteurs e-commerce Magento et Prestashop.
Le module introduit un modèle sale.workflow.process qui automatise tout ou partie du cycle :
- Validation de la commande.
- Envoi du courriel de confirmation.
- Création de la facture.
- Validation de la facture.
- Enregistrement du paiement.
- Verrouillage de la commande.
Chaque étape s'active indépendamment : on peut automatiser la validation et la facturation sans toucher au paiement, par exemple.
L'avertissement d'usage : sur un flux où un commercial relit chaque commande, ce module n'apporte rien et retire un point de contrôle. Il se justifie quand le volume rend la relecture impossible — une boutique en ligne, un flux EDI, un portail de commande client.
Dans ce cas, le contrôle doit se déplacer en amont, sur les données : c'est exactement le rôle du module suivant. Voir la boutique en ligne intégrée.
sale_exception : bloquer avant de confirmer
Ce module est l'implémentation de base_exception pour les ventes — celui qui donne enfin un effet au socle générique.
Il permet de définir des règles, écrites en domaine ou en code Python simple, évaluées automatiquement sur les commandes et leurs lignes. Quand une commande correspond à une règle active, sa confirmation est bloquée et un message d'explication s'affiche.
Les exemples que donne le dépôt sont parlants :
- une adresse de livraison sans code postal,
- un stock insuffisant,
- un avertissement client ou produit.
Un utilisateur habilité peut ignorer l'exception pour forcer la confirmation — ce qui est la bonne conception : le blocage informe, l'habilitation tranche.
C'est le complément indispensable de l'automatisation. Un flux automatique sans règles de blocage valide et facture tout, y compris les commandes aberrantes. Les deux modules se posent ensemble, pas l'un sans l'autre.
Et comme pour le socle, une mise en garde : les règles en code Python passent par safe_eval, avec le risque de sécurité que le dépôt de base_exception signale. Privilégiez le mode domaine, et réservez la création de règles aux administrateurs.
Les trois modules de détail qui changent un quotidien
sale_order_line_date : une date par ligne
Un seul champ ajouté, et il résout un problème que tout négociant connaît : une commande de dix articles dont trois sont disponibles maintenant et sept dans six semaines.
Le module ajoute une date d'engagement propre à chaque ligne, en plus de celle de la commande, et — c'est le point décisif — propage ces dates vers les mouvements de stock et les réceptions ou livraisons associées.
Sans lui, il faut soit annoncer la date la plus tardive pour toute la commande, soit la scinder en deux. Les deux solutions se paient en relation client.
sale_order_general_discount : une remise globale
Une remise en pourcentage au niveau de la commande, répercutée automatiquement sur le champ Remise de chaque ligne. Avec deux raffinements qui le rendent utilisable :
- Exclusion produit par produit : certains articles ne suivent pas la remise globale.
- Remise par défaut au niveau du client : un client qui a toujours 5 % n'exige plus qu'on y pense.
À ne pas confondre avec account_invoice_triple_discount, qui travaille au niveau de la ligne de facture avec trois remises composées. Celui-ci agit en amont, sur le devis.
sale_commercial_partner : le reporting B2B
Le cas B2B classique : un client est une société mère avec plusieurs contacts, adresses de facturation et adresses de livraison. Le reporting des ventes les compte séparément, et personne ne sait ce que pèse réellement le groupe.
Le module ajoute sur la commande deux champs liés et stockés qui pointent vers l'entité commerciale du client et de l'adresse de facturation. Conséquences :
- Regroupement par « Customer Entity » dans les vues liste et le reporting des ventes.
- Deux options pour restreindre le choix des adresses de facturation et de livraison à la même entité commerciale que le client — ce qui évite de facturer la filiale A pour une livraison chez la filiale B.
Comment les combiner
Ces modules ne se choisissent pas isolément : ils forment deux combinaisons cohérentes.
| Situation | La combinaison |
|---|---|
| Plusieurs lignes de métier dans la même instance | sale_order_type seul suffit souvent |
| Flux à fort volume, peu d'intervention humaine | sale_automatic_workflow + sale_exception, jamais l'un sans l'autre |
| Clientèle B2B à groupes et filiales | sale_commercial_partner + sale_order_type (type par partenaire) |
| Négoce avec disponibilités échelonnées | sale_order_line_date |
| Politique de remise négociée par client | sale_order_general_discount |
La deuxième ligne est la plus importante de cette fiche. Automatiser un cycle de vente sans règles de blocage, c'est industrialiser la validation d'erreurs — et une facture automatique sur une commande aberrante coûte plus qu'elle ne fait gagner.
Identité technique
| Module | Dépôt OCA | Version | Dépend de |
|---|---|---|---|
sale_order_type | sale-workflow | 18.0.1.4.0 | account, sale_management, sale_stock |
sale_automatic_workflow | sale-workflow | 18.0.1.2.0 | sale |
sale_exception | sale-workflow | 18.0.2.3.2 | base_exception, sale |
sale_order_general_discount | sale-workflow | 18.0.1.0.2 | sale |
sale_commercial_partner | sale-workflow | 18.0.1.2.0 | sale |
sale_order_line_date | sale-workflow | 18.0.1.0.2 | sale_stock |
sale_commission_oca | commission | — | — |
Tous sous licence AGPL-3, branche 18.0. Le dépôt sale-workflow compte 157 modules documentés — le plus fourni de l'écosystème OCA, et une raison majeure de choisir Odoo Community pour une activité commerciale. Le dépôt commission en compte 9, dont sale_commission_oca pour les commissions commerciales.
Ces sept modules figurent dans nos packs services (81 modules), négoce (75) et retail (68), au-delà du socle commun.
Questions fréquentes
À quoi sert un type de commande de vente ?
À porter neuf valeurs par défaut appliquées dès qu'on le choisit : entrepôt, route, séquence de numérotation, journal de facturation, conditions de paiement, liste de prix, incoterm, commercial et équipe commerciale. Le dépôt les présente comme des « lignes de métier » — vente standard, export, comptoir — et un type par défaut peut être associé à chaque client.
Faut-il automatiser son cycle de vente ?
Seulement si le volume rend la relecture humaine impossible — une boutique en ligne, un flux EDI, un portail client. Sur un flux où un commercial relit chaque commande, sale_automatic_workflow n'apporte rien et retire un point de contrôle. Et jamais sans sale_exception : automatiser sans règles de blocage, c'est industrialiser la validation d'erreurs.
Quelle différence entre la remise globale et la triple remise ?
sale_order_general_discount agit sur le devis : une remise globale répercutée sur chaque ligne, avec exclusion par produit et remise par défaut par client. account_invoice_triple_discount agit sur la ligne de facture, avec trois remises composées affichées distinctement. Les deux répondent à des politiques commerciales différentes.
Peut-on avoir des dates de livraison différentes dans une même commande ?
Oui, avec sale_order_line_date : une date d'engagement propre à chaque ligne, propagée aux mouvements de stock et aux livraisons. C'est un module d'un seul champ, et il évite d'avoir à annoncer la date la plus tardive pour toute la commande ou à la scinder en deux.
Comment mesurer ce qu'un groupe client pèse réellement ?
Avec sale_commercial_partner, qui ajoute sur la commande l'entité commerciale du client et de l'adresse de facturation, et permet de regrouper par « Customer Entity » dans le reporting. Il offre aussi de restreindre le choix des adresses à la même entité — ce qui évite de facturer une filiale pour la livraison d'une autre.
Se faire accompagner
La combinaison qui compte dans cette fiche n'est pas un module mais une paire : automatisation et règles de blocage. Le premier sans le second valide et facture les commandes aberrantes à la chaîne ; le second seul laisse le travail manuel intact.
Nous posons les deux ensemble — les étapes à automatiser, puis les règles écrites en domaines plutôt qu'en code, avec les habilitations pour les ignorer. Et nous commençons toujours par les types de commande, qui règlent à eux seuls la plupart des incohérences. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- base_exception : des règles de blocage métier
- Grossiste, négoce et distribution avec Odoo
- Le socle commun : les 57 modules de chaque instance
En résumé
Sept modules d'un dépôt qui en compte 157 : un type de commande qui porte neuf valeurs par défaut, un workflow pour les flux à fort volume, des règles qui bloquent avant confirmation, et trois modules de détail dont un d'un seul champ. La règle à retenir : jamais d'automatisation sans règles de blocage. Parlons de votre cycle de vente.
