Odoo sait émettre une facture et constater son règlement. Entre les deux, il ne sait rien faire : pas de politique de relance à niveaux, pas d'encours autorisé, pas de blocage de commande pour un client qui doit déjà trop, et aucune alerte sur la fiche d'un mauvais payeur.
Quinze modules communautaires occupent cet espace — celui où une PME perd sa trésorerie. Ils terminent le dépôt credit-control.
Résumé
Trois modules traitent la relance structurée : des politiques de relance avec leurs niveaux, leurs lignes, leurs communications et un assistant de suivi manuel ; l'impression des factures jointes au récapitulatif de relance ; et l'exécution en travaux de fond par lots.
Trois modules traitent la relance simple : un mécanisme de rappel par courriel, courrier ou téléphone avec ses actions et ses résultats, un avertissement d'impayé sur la fiche client, et le même avertissement sur la commande de vente.
Sept modules traitent l'encours : le modèle d'encours client, son application aux commandes de vente et l'affichage de sa consommation, aux mouvements de stock, à la boutique en ligne, aux rejets de prélèvement et aux feuilles de règlement.
Deux modules enfin traitent l'assurance-crédit : les informations d'assurance par client avec son rapport d'analyse, et une vignette sur les factures couvertes.
L'essentiel
- Des politiques de relance à niveaux, avec communications tracées.
- Les factures jointes au récapitulatif de relance.
- Un rappel par courriel, courrier ou téléphone, avec son résultat.
- Un avertissement d'impayé sur la fiche client et sur la commande.
- Un encours client bloquant les commandes.
- L'encours appliqué aux livraisons et à la boutique en ligne.
- L'encours réduit par un rejet de prélèvement.
- L'assurance-crédit par client, avec vignette sur facture.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Relance structurée | account_credit_control, account_credit_control_attach_invoice, account_credit_control_queue_job | 3 |
| Relance simple | account_invoice_overdue_reminder, account_invoice_overdue_warn, account_invoice_overdue_warn_sale | 3 |
| Encours | account_financial_risk, sale_financial_risk, sale_financial_risk_info, stock_financial_risk, website_sale_financial_risk, account_payment_return_financial_risk, sale_payment_sheet_financial_risk | 7 |
| Assurance-crédit | partner_risk_insurance, partner_risk_insurance_product_sticker_invoice_report | 2 |
Les menus : Facturation ▸ Relances Clients et ses trois sous-menus, Facturation ▸ Configuration ▸ Relances Clients ▸ Politique de relance, Facturation ▸ Clients ▸ Relance client, Facturation ▸ Analyse ▸ Analyse des lignes de relance, Actions de relance et Invoice Risk Insurance Report.
Deux approches de la relance, à ne pas mélanger
Le dépôt contient deux mécanismes de relance concurrents, et c'est le premier choix à faire : une relance structurée par politiques et niveaux, ou une relance simple par rappels. Installer les deux produit deux files de travail et deux historiques pour le même client.
La relance structurée
account_credit_control (version 18.0.2.0.2) crée des politiques de relance avec leurs niveaux, un modèle de ligne de relance, des communications tracées, un assistant de suivi manuel et un rapport d'analyse. Son README est réduit à sa catégorie ; les menus en disent la portée.
C'est le mécanisme d'un service de recouvrement : chaque facture échue produit une ligne de relance, qui passe de niveau en niveau selon la politique, et chaque communication reste tracée.
account_credit_control_attach_invoicejoint les factures au récapitulatif de relance — ce qui évite le courriel où le client répond « de quelle facture parlez-vous ».account_credit_control_queue_jobfait exécuter les relances en travaux de fond par lots. Sur un portefeuille de plusieurs centaines de factures échues, c'est nécessaire.
La relance simple
account_invoice_overdue_reminder (version 18.0.1.6.0) fournit un mécanisme plus léger : un rappel par courriel, courrier ou téléphone, avec un référentiel d'actions de relance et de résultats.
La prise en compte du téléphone est ce qui le distingue : une relance téléphonique est l'action la plus efficace sur un impayé, et la seule que les outils de relance automatique ignorent.
account_invoice_overdue_warnaffiche un avertissement sur la fiche client quand il a des factures échues.account_invoice_overdue_warn_saleaffiche le même avertissement sur la commande de vente.
L'avertissement sur la commande est la mesure la plus rentable du lot : il arrête la vente avant la livraison, au moment où un commercial s'apprête à engager de la marchandise chez un client qui n'a pas payé les trois précédentes.
L'encours client, branché partout
account_financial_risk gère un encours client — le montant maximum que l'on accepte de laisser dû. Six modules le branchent sur les flux où il doit agir :
| Module | Où l'encours agit |
|---|---|
sale_financial_risk | Les commandes de vente (version 18.0.1.0.8, la plus travaillée) |
sale_financial_risk_info | La consommation d'encours affichée sur la commande |
stock_financial_risk | Les mouvements de stock — donc les livraisons |
website_sale_financial_risk | La boutique en ligne (README réduit à sa catégorie) |
account_payment_return_financial_risk | Les rejets de prélèvement (README réduit à sa catégorie) |
sale_payment_sheet_financial_risk | Les feuilles de règlement |
Bloquer la commande sans bloquer la livraison ne sert à rien : la commande passée avant le dépassement se livre quand même. C'est pourquoi le module sur les mouvements de stock compte autant que celui sur les ventes — et c'est celui qu'on oublie.
L'affichage de la consommation d'encours sur la commande est le pendant indispensable du blocage : un commercial qui voit « 8 400 € sur 10 000 € autorisés » adapte sa proposition ; un commercial qui découvre un blocage à la validation appelle la comptabilité.
Le module de rejet de prélèvement ferme une boucle : un prélèvement rejeté reconstitue de l'encours consommé, puisque l'argent n'est jamais arrivé.
Les rejets de prélèvement eux-mêmes sont traités dans échéances, balance âgée et rejets.
L'assurance-crédit
partner_risk_insurance enregistre les informations d'assurance-crédit par client, avec un rapport d'analyse sous Facturation ▸ Analyse ▸ Gestion ▸ Invoice Risk Insurance Report.
partner_risk_insurance_product_sticker_invoice_report affiche une vignette sur les rapports de facture couverts par l'assurance.
L'assurance-crédit transforme la gestion du risque : une créance assurée ne se relance pas comme une créance nue, et le plafond garanti par l'assureur est souvent l'encours réel — pas celui qu'on a fixé soi-même.
La vignette sur la facture a un usage interne : savoir d'un coup d'œil, sur une pièce imprimée, si la créance est couverte.
Limites connues
- Deux mécanismes de relance concurrents dans le même dépôt : choisir la relance structurée (politiques et niveaux) ou la relance simple (rappels), pas les deux.
- Quatre modules ont un README réduit à leur catégorie :
account_credit_control,account_credit_control_queue_job,website_sale_financial_risketaccount_payment_return_financial_risk. - L'encours sur les commandes sans l'encours sur les mouvements de stock est incomplet : la commande passée avant le dépassement se livre quand même.
- Un encours bloquant sans affichage de consommation génère des appels : installer les deux modules ensemble.
- Le calcul d'encours dépend de la définition retenue — factures échues seulement, ou commandes en cours comprises : à trancher avant de fixer des plafonds.
account_credit_control_queue_jobdépend des travaux par lots (queue_job_batch) : une infrastructure de travailleurs à surveiller.- L'assurance-crédit est un référentiel : aucun module ne dialogue avec l'assureur ni ne déclare un sinistre.
- La relance téléphonique se trace, elle ne s'automatise pas : le module enregistre l'action et son résultat, l'appel reste humain.
Identité technique
Les quinze modules viennent du dépôt OCA credit-control, branche 18.0 — dont tous les modules sont désormais documentés ici —, tous en licence AGPL-3. Les dépendances : account pour la base, sale, stock et website_sale pour les branchements d'encours, account_payment_return pour les rejets, sale_payment_sheet pour les feuilles de règlement, queue_job_batch pour les lots, account_invoice_report_product_sticker pour la vignette.
Voir aussi échéances, balance âgée et rejets de prélèvement.
Questions fréquentes
Odoo gère-t-il un encours client ?
Pas en standard. account_financial_risk le gère, et six modules le branchent là où il doit agir : commandes de vente, mouvements de stock, boutique en ligne, rejets de prélèvement, feuilles de règlement. Bloquer la commande sans bloquer la livraison ne sert à rien — la commande passée avant le dépassement se livre quand même.
Quel mécanisme de relance choisir dans ce dépôt ?
Il y en a deux, concurrents : account_credit_control (politiques, niveaux, communications tracées — un service de recouvrement) et account_invoice_overdue_reminder (rappels par courriel, courrier ou téléphone, plus léger). Installer les deux produit deux files de travail et deux historiques pour le même client.
Peut-on alerter un commercial qu'un client a des impayés ?
Oui : account_invoice_overdue_warn affiche un avertissement sur la fiche client, et account_invoice_overdue_warn_sale sur la commande de vente. C'est la mesure la plus rentable du lot — elle arrête la vente avant qu'on engage de la marchandise chez un client qui n'a pas payé les trois précédentes.
Un commercial peut-il voir l'encours restant avant de proposer ?
Oui, avec sale_financial_risk_info, qui affiche la consommation d'encours sur la commande. C'est le pendant indispensable du blocage : « 8 400 € sur 10 000 € autorisés » permet d'adapter la proposition ; un blocage découvert à la validation génère un appel à la comptabilité.
Peut-on suivre l'assurance-crédit dans Odoo ?
Oui : partner_risk_insurance enregistre les informations par client avec un rapport d'analyse, et un second module affiche une vignette sur les factures couvertes. C'est un référentiel — aucun module ne dialogue avec l'assureur ni ne déclare un sinistre. Le plafond garanti est souvent l'encours réel.
Se faire accompagner
Le recouvrement est le domaine où l'ERP change le plus directement la trésorerie, et celui qu'on paramètre en dernier. Trois modules suffisent pour l'essentiel : l'avertissement d'impayé sur la commande, l'encours sur les ventes, et l'encours sur les livraisons — le troisième étant celui qu'on oublie et qui rend les deux premiers inopérants.
Nous tranchons donc d'abord la définition de votre encours — factures échues seulement, ou commandes en cours comprises — parce que le plafond n'a aucun sens avant. Puis nous choisissons un seul mécanisme de relance. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
Odoo sait émettre une facture et constater son règlement. Entre les deux, rien : ni politique de relance, ni encours autorisé, ni blocage de commande pour un client qui doit déjà trop. Quinze modules occupent cet espace — celui où une PME perd sa trésorerie. Parlons de votre recouvrement.
