Entre la facture et l'argent, il y a une chaîne : un mode de paiement qui décide du journal, un mandat qui autorise le prélèvement, un ordre qui regroupe les échéances, un fichier bancaire qui part. Odoo ne modélise aucun de ces quatre maillons.
Quinze modules communautaires les posent, et terminent le dépôt bank-payment.
Résumé
Deux modules forment le socle : le mode de paiement qui route vers le bon journal bancaire, avec ses méthodes de règlement, et une colle résolvant un conflit d'héritage de vues avec le référentiel des méthodes techniques.
Trois modules propagent le mode de paiement au cycle commercial : sur les devis et commandes de vente avec report sur la facture, sur les bons de commande d'achat avec le compte bancaire du fournisseur, et une colle côté achat-stock.
Quatre modules traitent les ordres de paiement : une écriture groupée supplémentaire au passage à l'état fichier, une notification par courriel du détail à chaque partenaire concerné, le lien aux retours bancaires, et un visa par paliers sur les ordres.
Trois modules traitent les mandats : le mandat sur la commande de vente, le mandat choisi au niveau du contact, et la combinaison des deux.
Trois modules enfin traitent la sélection et les comptes : le marquage de factures à payer depuis la liste, un compte bancaire fournisseur par défaut sur la fiche, et sa reprise sur les commandes d'achat.
L'essentiel
- Un mode de paiement qui route vers le bon journal bancaire.
- Le mode de paiement propagé du devis à la facture.
- Le compte bancaire du fournisseur sur la commande d'achat.
- Un visa par paliers sur les ordres de paiement.
- Une notification au partenaire du détail de l'ordre le concernant.
- Le mandat de prélèvement sur la commande et par contact.
- Les factures marquées « à payer » depuis la liste.
- Un compte bancaire fournisseur par défaut.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Socle | account_payment_mode, account_payment_method_base_mode | 2 |
| Cycle commercial | account_payment_sale, account_payment_purchase, account_payment_purchase_stock | 3 |
| Ordres de paiement | account_payment_order_grouped_output, account_payment_order_notification, account_payment_order_return, account_payment_order_tier_validation | 4 |
| Mandats | account_banking_mandate_sale, account_banking_mandate_contact, account_banking_mandate_sale_contact | 3 |
| Sélection et comptes | account_invoice_select_for_payment, account_vendor_bank_account_default, account_vendor_bank_account_default_purchase | 3 |
Les menus : Facturation ▸ Configuration ▸ Gestion ▸ Mode de paiement et Méthodes de règlement.
Le mode de paiement, pièce centrale
Le mode de paiement n'est pas une étiquette : c'est ce qui décide par quel journal bancaire une somme entre ou sort. Un prélèvement SEPA, un virement, un chèque et une carte n'atterrissent pas sur le même compte — et sans objet qui le dise, le rapprochement devient manuel.
account_payment_mode crée le mode de paiement, qui classe et route les ordres entrants et sortants vers le bon journal, avec un référentiel de méthodes de règlement sous Facturation ▸ Configuration ▸ Gestion.
account_payment_method_base_mode est une colle résolvant un conflit d'héritage de vues avec le référentiel des méthodes de paiement techniques — les deux modules modifiant la même vue.
C'est un cas intéressant : le dépôt contient un module dont le seul objet est de faire cohabiter deux autres modules du catalogue. Signe que l'écosystème se construit par couches, et qu'il faut lire les dépendances.
Le référentiel des méthodes techniques est traité dans méthodes de paiement, chèques et visas.
Propager le mode dès la commande
account_payment_sale ajoute le mode de paiement sur les devis et commandes de vente, et le propage à la facture générée.
Décider du mode de paiement au devis plutôt qu'à la facture change l'exécution : le client qui accepte un devis « prélèvement à 30 jours » a accepté le mode, et la facture part prélevée sans qu'on y pense. Décider à la facture, c'est décider cent fois par mois.
account_payment_purchase fait de même côté achat : le mode de paiement et le compte bancaire du fournisseur sur le bon de commande, reportés sur la facture fournisseur.
account_payment_purchase_stock est la colle faisant fonctionner ce module avec les achats liés au stock.
account_invoice_select_for_payment permet de marquer des factures « à payer » depuis la liste, par une case en tête de ligne, pour constituer une sélection avant de générer un ordre.
Les ordres de paiement
account_payment_order_tier_validation ajoute un visa par paliers sur les ordres de paiement et de prélèvement, selon des règles configurables.
C'est le contrôle qui compte le plus dans ce dépôt : un ordre de paiement est un fichier qui sort de l'entreprise et déclenche des virements. Sans visa, la personne qui le génère est celle qui l'autorise.
account_payment_order_notificationajoute un bouton envoyant par courriel à chaque partenaire concerné le détail des transactions le concernant dans l'ordre.account_payment_order_grouped_outputajoute, sur le mode de paiement, une option générant une écriture comptable groupée supplémentaire au passage de l'ordre à l'état fichier.account_payment_order_returnest la colle entre les retours bancaires et les ordres de paiement.
La notification au partenaire est une pratique attendue en prélèvement : prévenir le débiteur du montant et de la date avant que la somme quitte son compte évite une contestation sur deux.
Les visas par paliers et leurs extensions sont traités dans visas, séquences et assistants.
Les mandats et les comptes bancaires
account_banking_mandate_saleajoute le mandat de prélèvement sur la commande de vente, en sélection ou en proposition automatique.account_banking_mandate_contact(version 18.0.1.2.0) permet de choisir un mandat — donc un compte bancaire — au niveau d'un contact, pour qu'il soit utilisé en priorité.account_banking_mandate_sale_contactcombine les deux.
Le mandat par contact répond à un cas fréquent en B2B : la société mère signe le mandat, mais chaque établissement a son compte. Le mandat utilisé dépend alors de l'établissement facturé, non du siège.
account_vendor_bank_account_defaultdéfinit un compte bancaire par défaut sur la fiche d'un fournisseur, utilisé automatiquement.account_vendor_bank_account_default_purchasefait reprendre ce compte par défaut sur les commandes d'achat.
Le compte fournisseur par défaut n'est pas un confort : un fournisseur avec trois comptes en base produit, tôt ou tard, un virement sur un compte clôturé — et un rejet à retraiter.
Les mandats SEPA et les fichiers de prélèvement sont traités dans SEPA : virements et prélèvements.
Limites connues
- Dix modules sur quinze dépendent de
account_payment_orderouaccount_payment_partner: ces briques du même dépôt sont le préalable, et sont traitées ailleurs. - Deux modules sont des colles pures : la résolution du conflit d'héritage de vues et le lien achat-stock. Leur absence produit un conflit ou un comportement incomplet, pas une erreur explicite.
- Le visa sur les ordres dépend de
base_tier_validation: installer le moteur avec ses extensions de transfert, sinon un congé bloque les décaissements. - La notification au partenaire envoie des données bancaires par courriel : vérifier ce que le gabarit contient avant d'activer.
- L'écriture groupée supplémentaire change la forme de la comptabilisation : à valider avec l'expert-comptable.
- Le mandat par contact doit être cohérent avec le mandat signé : un prélèvement sur un compte non couvert par le mandat est rejeté.
- Le compte bancaire fournisseur par défaut ne dispense pas de vérifier un changement de coordonnées : la fraude au changement d'IBAN passe précisément par là.
Identité technique
Les quinze modules viennent du dépôt OCA bank-payment, branche 18.0 — dont tous les modules sont désormais documentés ici —, tous en licence AGPL-3. Les dépendances internes : account_payment_order, account_payment_partner, account_banking_mandate et account_payment_method_base. Les dépendances externes : sale et purchase pour le cycle commercial, purchase_stock pour la colle, account_payment_return pour les retours, base_tier_validation pour le visa.
Voir aussi SEPA : virements et prélèvements et méthodes de paiement, chèques et visas.
Questions fréquentes
À quoi sert un mode de paiement dans Odoo ?
À router les ordres vers le bon journal bancaire. Ce n'est pas une étiquette : un prélèvement SEPA, un virement, un chèque et une carte n'atterrissent pas sur le même compte, et sans objet qui le dise, le rapprochement devient manuel. account_payment_mode le crée, avec ses méthodes de règlement.
Faut-il choisir le mode de paiement au devis ou à la facture ?
Au devis, avec account_payment_sale, qui le propage à la facture générée. Un client qui accepte un devis « prélèvement à 30 jours » a accepté le mode, et la facture part prélevée sans qu'on y pense. Décider à la facture revient à décider cent fois par mois.
Peut-on exiger un visa avant qu'un ordre de prélèvement parte ?
Oui, avec account_payment_order_tier_validation : un visa par paliers selon des règles configurables. C'est le contrôle qui compte le plus de ce dépôt — un ordre de paiement est un fichier qui sort de l'entreprise et déclenche des virements. Sans visa, la personne qui le génère est celle qui l'autorise.
Peut-on prévenir un client avant de le prélever ?
Oui : account_payment_order_notification envoie par courriel à chaque partenaire le détail des transactions le concernant. Prévenir le débiteur du montant et de la date avant le prélèvement évite une contestation sur deux. Vérifiez ce que le gabarit contient : il transmet des données bancaires.
Peut-on utiliser un mandat différent selon l'établissement facturé ?
Oui : account_banking_mandate_contact permet de choisir un mandat — donc un compte — au niveau du contact, et account_banking_mandate_sale_contact le combine avec le mandat sur commande. Cas fréquent en B2B : la société mère signe, chaque établissement a son compte. Attention à la cohérence avec le mandat réellement signé.
Se faire accompagner
La chaîne bancaire est le domaine où un ERP permissif coûte le plus en une seule fois : un ordre de paiement non visé, un compte fournisseur périmé, un mandat qui ne couvre pas le compte prélevé. Chacun de ces trois défauts se corrige par un module et une procédure.
Nous posons donc le visa sur les ordres avant d'ouvrir les virements, et le compte bancaire fournisseur par défaut avec une procédure de vérification de tout changement d'IBAN — parce que c'est exactement par là que passe la fraude. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
Entre la facture et l'argent il y a une chaîne : un mode de paiement qui décide du journal, un mandat qui autorise, un ordre qui regroupe, un fichier qui part. Odoo ne modélise aucun de ces quatre maillons — quinze modules les posent. Parlons de votre chaîne bancaire.
