Une commande qui arrive d'un site e-commerce n'a pas besoin d'un humain pour être confirmée, facturée et livrée : elle est payée, les prix sont ceux du catalogue, et personne ne va négocier.
Le module de workflow automatique d'Odoo Community fait cela. Onze modules satellites le rendent exploitable à l'échelle d'un flux réel — et traitent ce qui se passe en amont et en aval de la vente.
Résumé
Le socle, traité dans une fiche voisine, applique à des commandes correspondant à un filtre une série d'actions : confirmation, envoi du courriel, création et validation de la facture, enregistrement du paiement, verrouillage. Ses satellites ajoutent l'essentiel : l'attribution automatique du workflow à la création d'une vente, l'exécution en tâches de fond, la prise en charge des opérations de stock, une périodicité minimale entre deux passages, le mode de paiement comme critère, et le forçage du statut facturé comme action automatisable.
Trois modules traitent la liaison avec l'approvisionnement : sale_order_carrier_auto_assign attribue le transporteur à la création ou à la confirmation, sale_purchase_stock_auto_confirm confirme automatiquement les achats générés par une vente en flux tendu ou en livraison directe, et sale_purchase_stock_auto_cancel les annule quand la vente est annulée.
Deux modules enfin sont des fondations invisibles : sale_procurement_group_by_line crée un groupe d'approvisionnement par ligne au lieu d'un par commande — c'est lui qui permet aux livraisons de se découper — et sale_sourced_by_line autorise une ligne à partir d'un entrepôt source différent.
L'essentiel
- Le workflow attribué automatiquement à la création d'une commande, au lieu d'être choisi à la main.
- L'exécution en tâches de fond : indispensable au-delà de quelques dizaines de commandes par passage.
- Les opérations de stock pilotées par le workflow — module à installation automatique.
- Une périodicité minimale entre deux exécutions, pour espacer les traitements lourds.
- Le transporteur assigné seul, à la création du devis ou à sa confirmation.
- Les achats liés confirmés ou annulés avec la vente — le flux tendu et la livraison directe enfin cohérents.
- Un groupe d'approvisionnement par ligne : la fondation technique de presque toutes les finesses logistiques.
- Un entrepôt source par ligne : expédier une commande depuis deux dépôts.
Ce que ces modules ajoutent à l'instance
| Module | Rôle | Version |
|---|---|---|
sale_automatic_workflow_auto_assign | Attribue un workflow à la création de la vente | 18.0.1.1.0 |
sale_automatic_workflow_job | Exécution en tâches de fond | 18.0.1.0.2 |
sale_automatic_workflow_stock | Pilote aussi les transferts de stock | 18.0.1.0.1 |
sale_automatic_workflow_stock_job | Colle : les transferts en tâches de fond | 18.0.1.0.0 |
sale_automatic_workflow_periodicity | Intervalle minimal entre deux exécutions | 18.0.1.0.0 |
sale_automatic_workflow_payment_mode | Le mode de paiement comme critère | 18.0.1.0.0 |
sale_automatic_workflow_force_invoiced | Forcer « facturée » comme action automatique | 18.0.1.0.0 |
sale_order_carrier_auto_assign | Transporteur attribué automatiquement | 18.0.1.0.2 |
sale_purchase_stock_auto_confirm | Confirme les achats liés à la vente | 18.0.1.0.0 |
sale_purchase_stock_auto_cancel | Annule les achats liés quand la vente est annulée | 18.0.1.0.0 |
sale_procurement_group_by_line | Un groupe d'approvisionnement par ligne | 18.0.1.0.2 |
sale_sourced_by_line | Un entrepôt source par ligne | 18.0.1.0.1 |
Aucun n'ajoute de menu : ils enrichissent l'écran des workflows automatiques, les paramètres de société, ou la mécanique interne d'approvisionnement. Le socle lui-même est traité dans ventes : types, workflows et blocages.
Rendre le workflow automatique utilisable en production
Le module de base fonctionne : il applique une série d'actions à des commandes qui correspondent à un filtre. Trois limites apparaissent dès qu'on le met sous charge réelle.
Qui choisit le workflow ?
Sans module, c'est à la main. sale_automatic_workflow_auto_assign attribue le workflow à la création de la commande, ce qui est la seule façon de traiter des commandes créées par une interface — site web, échange de données, connecteur.
Tout en série, ou en tâches de fond ?
sale_automatic_workflow_jobfait exécuter chaque action — confirmation, courriel, facture, validation, verrouillage — comme une tâche de fond plutôt qu'en série pendant le passage du planificateur. Sans lui, deux cents commandes du jour bloquent un processus pendant plusieurs minutes, et une seule erreur interrompt le lot.
Avec les tâches de fond, chaque commande est traitée indépendamment : une qui échoue n'empêche pas les autres, et l'échec est visible dans la file. C'est la différence entre une automatisation de démonstration et une automatisation exploitable.
Son module jumeau, sale_automatic_workflow_stock_job, fait passer la validation automatique des transferts par le même mécanisme.
Et les livraisons ?
sale_automatic_workflow_stock étend le workflow aux opérations de stock : les bons de livraison liés aux commandes traitées sont également pilotés. Il s'installe automatiquement dès que le socle et sale_stock sont présents — encore un module dont l'absence ne se remarque pas, et dont la présence change le comportement.
Trois réglages de finesse
| Module | Ce qu'il ajoute |
|---|---|
sale_automatic_workflow_periodicity | Un intervalle minimal entre deux exécutions, pour espacer un traitement lourd au lieu de le rejouer à chaque passage |
sale_automatic_workflow_payment_mode | Le mode de paiement comme critère de sélection des commandes |
sale_automatic_workflow_force_invoiced | Le forçage du statut facturé comme action automatisable, pour les flux où la facture est émise ailleurs |
Le dernier mérite une mise en garde : automatiser un forçage de statut est puissant et irréversible dans les faits. Il se justifie quand la facture vient d'un autre système — une place de marché, par exemple — et jamais « pour nettoyer les listes ».
Le transporteur, attribué sans y penser
sale_order_carrier_auto_assign attribue le mode de livraison automatiquement, soit dès la création ou la modification du devis, soit au moment de la confirmation — le comportement s'active et se choisit en configuration.
- À la création : le devis porte le transporteur dès le départ, donc les frais de port sont calculés avant l'envoi au client.
- À la confirmation : on laisse le commercial libre jusqu'au bout, et l'automatisme ne joue qu'en l'absence de choix.
Le gain n'est pas le clic économisé : c'est la cohérence. Un transporteur choisi au hasard des habitudes de chaque vendeur rend inexploitable toute négociation tarifaire avec les transporteurs — on ne sait plus quel volume on leur confie.
La vente qui pilote l'achat
En flux tendu et en livraison directe, une commande de vente génère une commande d'achat. Odoo la crée, puis cesse de s'en occuper : si la vente est annulée, l'achat reste.
| Module | Déclencheur | Effet |
|---|---|---|
sale_purchase_stock_auto_confirm | Confirmation de la vente | Confirme automatiquement les achats générés |
sale_purchase_stock_auto_cancel | Annulation de la vente | Annule automatiquement les achats générés |
Les deux s'activent par une option au niveau de la société, et concernent les achats issus des règles de flux tendu ou de livraison directe.
Le second est celui qui évite l'incident coûteux : une vente annulée dont l'achat part quand même chez le fournisseur, et de la marchandise qui arrive pour un client qui n'existe plus. C'est rare, et c'est toujours cher.
Le premier accélère : dans un flux de livraison directe, chaque heure gagnée entre la commande client et la commande fournisseur est une heure de délai en moins pour le client final.
Côté achats, la mécanique symétrique — types, blocages, exceptions — est traitée dans la fiche des achats.
Les deux fondations invisibles
Ces deux modules n'ont aucune interface, et presque toutes les finesses logistiques des ventes en dépendent.
Un groupe d'approvisionnement par ligne
Odoo crée un groupe d'approvisionnement par commande : c'est ce groupe qui regroupe les mouvements, donc qui décide qu'une commande produit un seul bon de livraison. sale_procurement_group_by_line en crée un par ligne.
- C'est la dépendance de
sale_delivery_split_date(un bon de livraison par date demandée). - C'est la dépendance de
sale_stock_delivery_address(une adresse par ligne, avec éclatement). - C'est la dépendance de
sale_sourced_by_line(un entrepôt source par ligne).
Autrement dit : dès qu'on veut qu'une commande se comporte comme plusieurs, ce module est en dessous. Il ne modifie aucune interface et change pourtant la façon dont Odoo regroupe les mouvements — à tester sur une copie avant de l'installer sur une base chargée.
Un entrepôt source par ligne
sale_sourced_by_line permet de choisir, ligne par ligne, un entrepôt source différent de celui de la commande. Pour une entreprise à plusieurs dépôts, c'est ce qui permet d'expédier une commande depuis deux endroits sans la découper commercialement.
Le pendant côté client — un entrepôt par défaut sur sa fiche — est traité dans ventes et stock.
Limites connues
- Automatiser sans tâches de fond ne tient pas la charge : au-delà de quelques dizaines de commandes par passage, il faut
queue_jobet son exploitation. queue_jobest un composant d'infrastructure : il demande des processus dédiés et une surveillance des files en échec.sale_automatic_workflow_stocks'installe tout seul : son effet apparaît sans qu'on l'ait demandé explicitement.- Le forçage automatique du statut facturé est irréversible dans les faits : à réserver aux flux où la facture est émise par un autre système.
sale_procurement_group_by_linechange le regroupement des mouvements : à éprouver sur une copie avant une base en production.- Deux modules sont peu documentés dans le relevé (
sale_automatic_workflow_payment_mode,sale_automatic_workflow_auto_assign) : leur comportement exact se vérifie sur le dépôt.
Identité technique
Les douze modules viennent du dépôt OCA sale-workflow, branche 18.0, tous en licence AGPL-3. Deux dépendent de queue_job (dépôt queue), deux de sale_purchase_stock, et sale_order_carrier_auto_assign du module de livraison standard.
Les familles voisines du dépôt : facturation des ventes, ventes et stock, remises et tarifs.
Questions fréquentes
Faut-il exécuter les workflows automatiques en tâches de fond ?
Dès que le volume dépasse quelques dizaines de commandes par passage, oui. sale_automatic_workflow_job traite chaque action comme une tâche indépendante : une commande en échec n'interrompt plus le lot, et l'erreur reste visible dans la file. Sans lui, tout s'exécute en série pendant le passage du planificateur.
Comment attribuer un workflow à une commande créée par un site e-commerce ?
Avec sale_automatic_workflow_auto_assign, qui attribue le workflow à la création de la commande. C'est la seule façon de traiter des ventes créées par une interface — site web, connecteur, échange de données — puisque personne n'ouvrira la commande pour choisir un workflow.
Les achats générés par une vente suivent-ils son annulation ?
Pas en standard : la commande d'achat créée par une règle de flux tendu ou de livraison directe survit à l'annulation de la vente. sale_purchase_stock_auto_cancel les annule automatiquement, et sale_purchase_stock_auto_confirm fait l'inverse en confirmant les achats dès la confirmation de la vente. Les deux s'activent au niveau de la société.
À quoi sert un groupe d'approvisionnement par ligne ?
À permettre qu'une commande se comporte comme plusieurs. C'est la fondation technique du découpage des livraisons par date, de l'adresse de livraison par ligne et de l'entrepôt source par ligne. sale_procurement_group_by_line n'a aucune interface mais change la façon dont Odoo regroupe les mouvements : à tester sur une copie.
Peut-on expédier une commande depuis deux entrepôts ?
Oui, avec sale_sourced_by_line : chaque ligne peut porter un entrepôt source différent de celui de la commande. La commande reste unique côté client — une seule confirmation, une seule facture — mais la logistique part de deux endroits. Le module dépend du groupe d'approvisionnement par ligne.
Se faire accompagner
L'automatisation des ventes est le chantier où l'on gagne le plus de temps et où l'on crée le plus de dégâts invisibles : une facture validée sur une commande fausse, un achat confirmé pour une vente annulée, deux cents commandes bloquées parce que la première a échoué.
Nous appliquons donc une règle simple : on automatise un flux dont les règles sont écrites et stables, jamais un flux qu'on espère stabiliser par l'automatisation. Et on commence par les tâches de fond, pas par les actions. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- Ventes : types de commande, workflows et blocages
- Ventes et stock : livraisons, blocages et retours
- Automatiser les tâches répétitives d'une PME
En résumé
Le workflow automatique devient exploitable : attribué à la création, exécuté en tâches de fond, étendu aux livraisons et espacé dans le temps. Autour, la vente pilote enfin l'achat qu'elle a généré, et deux fondations sans interface permettent à une commande de se comporter comme plusieurs. Parlons de vos flux automatisables.
