Une facture de contrat n'a d'intérêt que si elle se paie. Or le mandat de prélèvement est sur le client, le mode de paiement sur la commande, et la méthode d'envoi nulle part — si bien que la facture générée automatiquement part en brouillon, sans mandat, par un canal au hasard.
Treize modules communautaires raccordent le contrat à sa chaîne d'encaissement — et terminent le dépôt contract.
Résumé
Quatre modules traitent le moyen de paiement : un mandat de prélèvement rattaché au contrat, un mode de paiement sur le contrat, et deux modules de propagation depuis le bon de commande vers le contrat généré — l'un pour le mandat, l'autre pour le mode de paiement, avec la possibilité d'un mode différent par société pour les contrats.
Deux modules traitent la transmission : une méthode de transmission — courriel, courrier postal, portail client — sur le contrat et sur le modèle de contrat, et sa propagation depuis le bon de commande.
Trois modules traitent le déclenchement de la facturation : la validation automatique des factures générées, un marqueur de facturation manuelle excluant un contrat de la facturation automatique avec ses deux assistants, et le basculement de la génération vers des travaux asynchrones.
Quatre modules enfin complètent : l'inclusion des commandes en attente partageant le même compte analytique que le contrat, les dates de début et de fin de période sur les lignes de facture, les étiquettes analytiques sur les lignes de contrat, et l'extension des accords de remise à un groupe d'entreprises.
L'essentiel
- Un mandat de prélèvement porté par le contrat, repris sur chaque facture.
- Un mode de paiement sur le contrat, propagé depuis la commande.
- Une méthode de transmission : courriel, courrier postal, portail.
- La validation automatique des factures générées — sinon elles restent en brouillon.
- Un marqueur de facturation manuelle, avec ses assistants dédiés.
- La facturation en travaux asynchrones, pour les gros portefeuilles.
- Les commandes en attente incluses dans la facturation du contrat.
- Les dates de période sur les lignes de facture.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Moyen de paiement | contract_mandate, contract_payment_mode, contract_sale_mandate, contract_sale_payment_mode | 4 |
| Transmission | contract_transmit_method, contract_sale_transmit_method | 2 |
| Déclenchement | contract_invoice_auto_validate, contract_invoice_manually, contract_queue_job | 3 |
| Compléments | contract_sale_invoicing, contract_invoice_start_end_dates, contract_analytic_tag, agreement_rebate_partner_company_group | 4 |
Deux de ces modules s'installent automatiquement quand leurs dépendances sont présentes : le mandat sur contrat et sa propagation depuis la commande. Les deux assistants de facturation manuelle sont placés sous la comptabilité.
Le moyen de paiement, propagé de bout en bout
La chaîne est longue et chaque maillon manque par défaut : le mandat SEPA est signé sur le client, choisi sur la commande, et la facture de contrat générée trois mois plus tard ne le connaît pas. Résultat, un prélèvement qui ne part pas et une relance pour un client qui avait signé.
contract_mandaterattache un mandat de prélèvement — SEPA ou autre — au contrat, repris sur les factures générées. Il s'installe automatiquement dès que le module de mandats bancaires et le module de mode de paiement sur contrat sont présents.contract_payment_modeajoute un mode de paiement sur le contrat, pour que les factures le reprennent. Il s'appuie sur le module de mode de paiement par partenaire.contract_sale_mandatepropage le mandat du bon de commande vers le contrat généré automatiquement depuis cette commande. Module de propagation sans interface propre, également en installation automatique.contract_sale_payment_modepropage le mode de paiement de la commande vers le contrat, avec une subtilité utile : la possibilité de définir, par société, un mode de paiement différent spécifiquement pour les contrats.
Cette dernière option correspond à un cas réel : les ventes ponctuelles se règlent par virement, les contrats par prélèvement. Sans elle, il faudrait corriger chaque contrat généré.
Les mandats et les prélèvements eux-mêmes sont traités dans SEPA : virements et prélèvements.
La méthode de transmission
contract_transmit_method relie le contrat à la notion de méthode de transmission — courriel, courrier postal, portail client — apportée par le module de transmission des factures. Le champ apparaît sur le contrat et sur le modèle de contrat.
contract_sale_transmit_method la propage depuis le bon de commande vers le contrat généré. Module de propagation sans interface propre.
La méthode de transmission est l'information qui décide si une facture arrive. Un client qui n'accepte que le courrier postal, ou qui exige le dépôt sur son portail fournisseur, ne paiera jamais une facture envoyée par courriel — et personne ne saura pourquoi.
Le champ sur le modèle de contrat compte autant que celui sur le contrat : il permet de poser la règle une fois pour une famille d'engagements.
Quand et comment la facturation se déclenche
contract_invoice_auto_validate ajoute une option de comptabilité qui valide automatiquement les factures générées depuis les contrats, juste après leur création. Sans ce module, elles restent en brouillon et attendent une validation manuelle.
C'est le premier module à installer sur un portefeuille de contrats : des centaines de brouillons qui s'accumulent chaque mois ne sont pas une facturation, c'est une tâche.
contract_invoice_manuallyajoute à l'inverse une option facturation manuelle excluant un contrat de la facturation automatique, avec deux écrans d'assistant pour le facturer à la demande. Le cas du client qui veut valider son décompte avant émission.contract_queue_jobfait basculer la génération des factures et le renouvellement des lignes vers des travaux asynchrones, au lieu de tout traiter dans une seule transaction. Objectif : fiabiliser et paralléliser.
Une facturation récurrente de plusieurs centaines de contrats dans une transaction unique est une bombe à retardement : une seule ligne en erreur annule tout le lot, et l'on découvre le 5 du mois que rien n'est parti.
Quatre compléments
contract_sale_invoicinginclut dans la facturation récurrente les commandes de vente en attente de facturation qui partagent le même compte analytique que le contrat. Le client reçoit une facture unique au lieu d'un abonnement et de trois commandes ponctuelles.contract_invoice_start_end_datesrenseigne automatiquement les dates de début et de fin de période sur les lignes de facture générées, quand le produit facturé le demande. C'est une colle entre le contrat et le module de dates de période sur facture.contract_analytic_tagréintroduit les étiquettes analytiques sur les lignes de contrat, pour qu'elles se retrouvent sur les lignes de facture générées.agreement_rebate_partner_company_groupétend les accords de remise pour qu'ils s'appliquent à tous les membres d'un groupe d'entreprises, et non au seul partenaire signataire.
Le dernier répond à une situation de négoce : un accord-cadre est signé par la maison mère, et les remises doivent s'appliquer aux commandes des filiales.
Les dates de période sur facture ne sont pas un détail de présentation : sur une facture d'abonnement, elles sont la seule indication de ce qui est facturé — et leur absence génère des appels.
Limites connues
- Deux modules s'installent automatiquement : le mandat sur contrat et sa propagation. Leur apparition peut surprendre lors de l'installation d'un module voisin.
- La validation automatique des factures retire le filet de sécurité : une erreur de paramétrage produit des factures comptabilisées, à extourner.
- La facturation en travaux asynchrones exige une infrastructure de travailleurs surveillée : un travailleur arrêté, et rien ne part sans message d'erreur visible.
- La propagation depuis la commande ne vaut que pour les contrats générés depuis une commande : un contrat créé à la main ne reçoit rien.
contract_sale_invoicingregroupe par compte analytique : un compte analytique mal attribué mélange des facturations qui ne devaient pas l'être.- Les étiquettes analytiques dépendent du module
account_analytic_tag, lui-même une réintroduction d'un mécanisme retiré du standard. - Quatre de ces modules sont des colles sans interface : leur effet n'est visible que par ce qu'ils évitent de ressaisir.
Identité technique
Les treize modules viennent du dépôt OCA contract, branche 18.0 — dont les 31 modules sont désormais tous documentés ici —, tous en licence AGPL-3. Les dépendances externes au dépôt : account_banking_mandate et account_banking_mandate_sale, account_payment_partner et account_payment_sale, account_invoice_transmit_method et sale_order_transmit_method, account_invoice_start_end_dates, account_analytic_tag, queue_job, agreement_rebate, base_partner_company_group.
L'autre fiche du dépôt : contrats récurrents, prévisions et quantités variables.
Questions fréquentes
Comment faire reprendre le mandat SEPA sur les factures d'un contrat ?
contract_mandate rattache le mandat de prélèvement au contrat ; les factures générées le reprennent sans ressaisie. Il s'installe automatiquement dès que le module de mandats bancaires et celui de mode de paiement sur contrat sont présents. Sans lui, un prélèvement ne part pas et le client signataire reçoit une relance.
Pourquoi les factures de contrat restent-elles en brouillon ?
C'est le comportement standard. contract_invoice_auto_validate ajoute une option de comptabilité qui les valide automatiquement juste après leur création. C'est le premier module à installer sur un portefeuille : des centaines de brouillons par mois ne sont pas une facturation, c'est une tâche.
Peut-on utiliser un mode de paiement différent pour les contrats et pour les ventes ponctuelles ?
Oui : contract_sale_payment_mode propage le mode de paiement de la commande vers le contrat, avec la possibilité de définir par société un mode différent spécifiquement pour les contrats. Le cas réel : virement pour les ventes, prélèvement pour les abonnements.
Comment facturer un client qui exige le dépôt sur son portail fournisseur ?
contract_transmit_method ajoute une méthode de transmission — courriel, courrier postal, portail — sur le contrat et sur le modèle de contrat, et contract_sale_transmit_method la propage depuis la commande. Une facture envoyée par le mauvais canal ne sera jamais payée, et personne ne saura pourquoi.
La facturation récurrente peut-elle traiter plusieurs centaines de contrats ?
Avec contract_queue_job, oui : la génération des factures et le renouvellement des lignes basculent en travaux asynchrones au lieu d'une transaction unique. Sans lui, une seule ligne en erreur annule tout le lot — et l'on découvre le 5 du mois que rien n'est parti. En contrepartie, l'infrastructure de travailleurs doit être surveillée.
Se faire accompagner
La facturation récurrente échoue rarement sur le calcul et presque toujours sur la chaîne d'encaissement : mandat absent, mode de paiement par défaut, facture en brouillon, canal d'envoi inadapté. Chacun de ces défauts est invisible sur une facture et fatal sur un règlement.
Nous raccordons donc le contrat à sa chaîne complète — mandat, mode, canal, validation — et nous vérifions le résultat sur une première échéance réelle avant d'ouvrir le portefeuille. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
La facturation récurrente échoue rarement sur le calcul et presque toujours sur la chaîne d'encaissement : mandat absent, facture restée en brouillon, canal d'envoi inadapté. Treize modules raccordent le contrat à son mandat, son mode de paiement et sa méthode de transmission. Parlons de vos encaissements récurrents.
