Documentation11 min de lecture

Quand et comment facturer : modes par client, regroupement et dates

Seize modules OCA du dépôt `account-invoicing` décident **quand et comment** une facture est émise dans Odoo 18 Community : `partner_invoicing_mode` introduit un **mode de facturation par client**, décliné en **facturation à l'expédition** et en **facturation mensuelle** par deux modules dédiés. Les treize autres, de la facture créée depuis un bon de livraison aux critères de regroupement personnalisés.

Contrat et échéancier de facturation sur un bureau

Deux clients, deux attentes : l'un veut une facture à chaque livraison, l'autre un relevé mensuel. Odoo facture à partir de la commande, selon une logique unique, et c'est au service comptable de s'adapter — client par client, tous les mois.

Seize modules communautaires rendent cette décision paramétrable : le mode est porté par le client, et la facture peut naître du bon de livraison plutôt que de la commande.

Résumé

Trois modules installent le mode de facturation par client : un socle qui porte la notion, une facturation à l'expédition — la facture est créée à la validation du bon de livraison —, et une facturation mensuelle qui agrège la période.

Trois permettent de facturer depuis le bon de livraison : un mécanisme générique indépendant de toute commande, sa liaison au flux de vente standard, et la reprise de la date choisie sur les factures ainsi générées.

Quatre pilotent le regroupement et la date : des critères de regroupement personnalisés pour la facturation groupée, le choix de la date de facture dans l'assistant, la facturation d'un pourcentage de la quantité, et la facturation autorisée dès qu'une transaction de paiement couvre le montant.

Le reste rend la facture lisible : des sections par commande d'origine quand une facture en regroupe plusieurs, un numéro de ligne, une colonne de référence produit dans le PDF, le détail des feuilles de temps en description, les étiquettes CRM reportées, et des destinataires supplémentaires par contact.

L'essentiel

  • Un mode de facturation porté par le client : standard, à l'expédition, mensuel.
  • La facture créée à la validation du bon de livraison, sans passer par la commande.
  • Des critères de regroupement personnalisés pour la facturation groupée.
  • La date de facture choisie dans l'assistant, au lieu de la date du jour.
  • La facturation d'un pourcentage de la quantité commandée.
  • Des sections par commande d'origine dans une facture regroupée.
  • Le détail des feuilles de temps en description de ligne.
  • Des destinataires supplémentaires notifiés en plus du contact principal.

Ce que ces modules ajoutent à l'instance

FamilleModulesNombre
Mode par clientpartner_invoicing_mode, partner_invoicing_mode_at_shipping, partner_invoicing_mode_monthly3
Facturer depuis la livraisonstock_picking_invoicing, sale_stock_picking_invoicing, sale_invoicing_date_from_picking3
Regroupement et datesale_order_invoicing_grouping_criteria, sale_invoicing_date_selection, sale_order_invoicing_qty_percentage, sale_invoiceability_on_payment_transaction4
Lisibilité de la factureaccount_invoice_section_sale_order, account_invoice_line_sequence, account_invoice_default_code_column, sale_timesheet_invoice_description, account_invoice_crm_tag, account_invoice_subscription_per_contact6

Un menu ajouté : Facturation ▸ Configuration ▸ Gestion ▸ Critère de groupement de facturation.

Le mode de facturation, porté par le client

Dans la plupart des PME, la règle de facturation de chaque client vit dans la tête du comptable : « lui, c'est à la livraison », « eux, c'est un relevé le 30 ». Cette connaissance ne se partage pas, ne se vérifie pas, et disparaît avec la personne.

  1. partner_invoicing_mode ajoute un champ mode de facturation sur le client et le socle technique qui le fait respecter.
  2. partner_invoicing_mode_at_shipping ajoute le mode à l'expédition : la facture est créée à la validation du bon de livraison.
  3. partner_invoicing_mode_monthly ajoute le mode mensuel : les livraisons de la période sont agrégées en une facture.

L'ensemble s'appuie sur une file de travaux de fond, ce qui est le bon choix : facturer deux cents expéditions de la journée ne doit pas bloquer l'interface, et une facture en échec ne doit pas interrompre les autres.

Ce dispositif complète la fréquence de facturation décrite dans facturer une vente : la fréquence dit à quel rythme, le mode dit sur quel événement.

Facturer depuis le bon de livraison

stock_picking_invoicing fournit un mécanisme générique : créer une facture directement depuis un ou plusieurs bons de livraison, indépendamment de toute commande de vente. sale_stock_picking_invoicing relie ce mécanisme au flux de vente standard, et sale_invoicing_date_from_picking fait reprendre la date choisie sur les factures ainsi produites.

Le cas d'usage est celui du négoce qui livre d'abord et facture ensuite, parfois des semaines plus tard, en regroupant plusieurs livraisons. Partir de la commande oblige alors à des manipulations ; partir de la livraison correspond au métier.

Ces modules s'appuient sur le lien transfert-facture dont nous avons signalé ailleurs qu'il reste vide sans module de remplissage : ici, ils sont ce module.

Voir préparations : lots, retours et liens facture pour le lien lui-même.

Regrouper, dater, facturer partiellement

ModuleCe qu'il permet
sale_order_invoicing_grouping_criteriaDes critères de regroupement personnalisés pour la facturation groupée, en plus des critères standards
sale_invoicing_date_selectionLe choix de la date de facture dans l'assistant de facturation
sale_order_invoicing_qty_percentageLa facturation d'un pourcentage de la quantité commandée
sale_invoiceability_on_payment_transactionLa facturation autorisée dès qu'une transaction de paiement couvre le montant total

Le premier répond à une contrainte fréquente : regrouper par client est insuffisant, il faut regrouper par chantier, par service, par référence d'engagement. Les critères standards ne le permettent pas.

Le deuxième traite un besoin de clôture : facturer le 2 du mois avec la date du 31 précédent. Sans ce choix, il faut modifier la date après coup, document par document.

Le troisième sert les acomptes en pourcentage sur quantité — fréquent en fabrication sur mesure et en prestation longue.

Le quatrième change la condition de facturation : non plus la livraison, mais le paiement effectif d'une transaction. C'est le modèle du commerce en ligne, où la facture suit l'encaissement.

Rendre la facture lisible pour le client

  • account_invoice_section_sale_order insère des sections par commande d'origine quand une facture regroupe plusieurs commandes : le client retrouve ses propres commandes dans le document.
  • account_invoice_line_sequence ajoute un numéro de ligne visible.
  • account_invoice_default_code_column ajoute, dans le PDF, une colonne dédiée à la référence produit, séparée de la description.
  • sale_timesheet_invoice_description reporte le détail des feuilles de temps dans la description des lignes de facture.
  • account_invoice_crm_tag reporte les étiquettes de la commande sur les factures et avoirs qui en découlent.
  • account_invoice_subscription_per_contact permet de notifier des destinataires supplémentaires en plus de l'adresse principale du contact.

Le premier est le plus utile en facturation groupée : sans sections, le client reçoit une facture de soixante lignes mélangeant trois chantiers, et il la met de côté le temps de comprendre. Une facture qu'on ne comprend pas est une facture qu'on ne paie pas.

Le détail des feuilles de temps joue le même rôle en prestation de services : justifier le montant par le travail réellement effectué évite la demande de détail — et le délai qu'elle provoque.

Les feuilles de temps elles-mêmes sont traitées dans projets, rôles et feuilles de temps.

Sept compléments : portail, codes client et reprise en brouillon

Ces modules ne forment pas une famille, et chacun ferme un trou précis.

ModuleCe qu'il résout
portal_account_personal_data_onlyCôté portail, restreint la visibilité des factures aux documents de l'utilisateur connecté — sans lui, un utilisateur portail voit toute facture dont il est suiveur
account_portal_invoice_searchUne barre de recherche sur la page « Factures » du portail, par numéro ou référence de paiement
product_customerinfo_invoiceLe code produit du client affiché sur les lignes de facture, à côté de votre référence
product_form_account_move_line_linkUn bouton Écritures sur la fiche produit, ouvrant toutes les lignes comptables où il a été facturé
account_invoice_supplierinfo_updateUn assistant qui détecte les écarts entre la facture fournisseur et le tarif enregistré, et propose de mettre à jour la fiche
account_invoice_transmit_method_substitution_ruleDes règles de substitution du mode de transmission, selon des critères définis par l'administrateur
stock_account_move_reset_to_draftLa remise en brouillon d'une facture fournisseur malgré une couche de valorisation générée par un écart de prix, tant que le stock n'est pas consommé

Le premier est le pendant, côté factures, du défaut de confidentialité déjà signalé sur les commandes : par défaut, un utilisateur du portail voit les documents dont un membre de son organisation est suiveur. Sur des factures, l'exposition est plus sensible encore.

Le cinquième mérite d'être retenu par les acheteurs : plutôt que de constater un écart de prix à la facture et de corriger le tarif plus tard — c'est-à-dire jamais —, l'assistant propose la mise à jour au moment où l'écart est constaté.

Le dernier lève une limitation qui bloque régulièrement les comptables : un écart entre le prix de réception et le prix facturé génère une écriture de valorisation, qui empêche ensuite de remettre la facture en brouillon pour la corriger.

Limites connues

  • Les modes de facturation supposent une file de travaux de fond (queue_job) et sa surveillance.
  • Facturer depuis la livraison change l'origine du document : les analyses par commande doivent être revues.
  • Les critères de regroupement personnalisés s'ajoutent aux critères standards : ils affinent, ils ne remplacent pas.
  • La date de facture choisie doit rester dans une période ouverte : la clôture comptable prime.
  • La facturation sur transaction de paiement convient au commerce en ligne : elle est discutable en vente B2B à crédit.
  • Les sections par commande allongent la facture : à activer quand le regroupement est réellement multi-commandes.

Identité technique

Les seize modules viennent du dépôt OCA account-invoicing, branche 18.0, tous en licence AGPL-3. Les modes de facturation dépendent de la file de travaux de fond et de sale ou stock ; la facturation depuis les livraisons s'appuie sur le lien transfert-facture du dépôt stock-logistics-workflow.

Les familles voisines : contrôler une facture, avoirs et compensations et remises, devises et taxes.

Questions fréquentes

Peut-on facturer certains clients à la livraison et d'autres mensuellement ?

Oui : partner_invoicing_mode porte un mode de facturation sur le client, décliné en à l'expédition (facture créée à la validation du bon de livraison) et en mensuel (livraisons agrégées sur la période). La règle sort de la tête du comptable et devient vérifiable.

Peut-on créer une facture depuis un bon de livraison ?

Oui, avec stock_picking_invoicing, qui fournit un mécanisme générique, indépendant de toute commande, et sale_stock_picking_invoicing qui le relie au flux de vente. C'est le modèle du négoce qui livre d'abord et facture ensuite, en regroupant plusieurs livraisons.

Peut-on regrouper les factures autrement que par client ?

sale_order_invoicing_grouping_criteria permet de définir des critères de regroupement personnalisés, en plus des critères standards toujours appliqués : par chantier, par service, par référence d'engagement. Les critères standards ne permettent que le regroupement par client.

Peut-on dater une facture du mois précédent ?

Oui : sale_invoicing_date_selection permet de choisir la date de facture dans l'assistant de facturation — facturer le 2 avec la date du 31. Sans ce choix, il faut corriger la date document par document après coup, et la période comptable doit rester ouverte.

Comment rendre lisible une facture qui regroupe plusieurs commandes ?

account_invoice_section_sale_order insère des sections par commande d'origine : le client retrouve ses propres commandes dans le document. Sans elles, une facture de soixante lignes mélangeant trois chantiers est mise de côté le temps d'être comprise — et une facture qu'on ne comprend pas est une facture qu'on ne paie pas.

Se faire accompagner

La règle de facturation d'un client est une information commerciale que la comptabilité applique. Tant qu'elle n'est pas dans l'outil, elle produit chaque mois des échanges, des oublis et des factures refaites.

Nous commençons donc par un relevé : pour vos vingt premiers clients, à quel événement et à quel rythme facturez-vous. Le paramétrage suit, et la facturation mensuelle cesse d'être une semaine de travail. Voir les prestations d'Atalios Consulting, notre méthode ou demander un rappel.

Pour aller plus loin

En résumé

Le mode de facturation devient une donnée du client — à l'expédition, mensuel, standard — au lieu d'une règle mémorisée. La facture peut naître du bon de livraison, se regrouper selon vos critères, se dater à la clôture, et porter les sections qui la rendent compréhensible. Parlons de votre cycle de facturation.

Documentation OCAComptabilitéFacturation

Partager

Fiches connexes

Équipe au travail sur des ordinateurs portables autour d'une table
Le module OCA `account_invoice_en16931` (dépôt `fr-einvoicing`, version 18.0.1.0.0, licence AGPL-3) est le socle qui fabrique le fichier de facture électronique conforme à la norme européenne **EN 16931** : Factur-X (PDF/A-3 avec XML CII embarqué), XML UBL, XML CII ou PDF accompagné d'un UBL — et il ajoute des **contrôles bloquants à la validation** d'une facture client. Les quatre modules qui s'y greffent pour la France, et ce que le socle ne fait pas.
Lire la suite
Documentation OCA, Facturation électronique
Réunion d'approbation autour d'un document de travail
Relevé sur une instance Odoo 18 Community, le module OCA `base_tier_validation` (dépôt `server-ux`, version 18.0.3.5.1, licence AGPL-3) ajoute 1 modèle, 101 champs et 3 menus, mais ne s'active sur aucun document métier par lui-même : il lui faut un module d'implémentation. C'est le point qui surprend le plus — voici ce qu'il fait réellement, et comment le mettre en service.
Lire la suite
Documentation OCA, Odoo