Documentation11 min de lecture

Facturation fournisseur : échéanciers, acomptes, commandes cadres et devises

Quatorze modules OCA du dépôt `purchase-workflow` traitent ce qui se passe entre la commande d'achat et la facture fournisseur dans Odoo 18 Community : `purchase_blanket_order` (version 18.0.1.0.2) introduit la **commande cadre** — un pré-accord fixant quantités et prix négociés sur une période, dont on tire ensuite des commandes successives. Les treize autres, de l'échéancier d'acomptes au taux de change négocié avec le fournisseur.

Factures fournisseurs et ordre de paiement sur un bureau

Côté fournisseur, la facturation n'est pas un sujet de confort : c'est là que se logent les acomptes versés et jamais soldés, les commandes éternellement « à facturer », et les écarts de change qu'on découvre à la clôture.

Quatorze modules communautaires traitent ce segment, de l'accord-cadre au taux de change négocié.

Résumé

purchase_blanket_order installe la commande cadre : un pré-accord avec un fournisseur, portant quantités et prix sur une période, à partir duquel on génère des commandes successives. purchase_invoice_plan planifie à l'inverse un échéancier de facturation sur une commande donnée, au lieu de laisser les factures arriver au fil de l'eau.

Deux modules enregistrent des acomptes : l'un avant même la confirmation, avec suivi de l'état de paiement de la commande ; l'autre après confirmation, en générant directement une facture fournisseur d'acompte en pourcentage ou en montant. Trois autres permettent de solder ce qui ne sera jamais facturé : forçage du statut au niveau de la commande, réduction de la quantité restant à facturer au niveau de la ligne, et statut de facturation calculé par ligne.

Le reste rend visible et juste : le montant non facturé affiché en colonne de liste puis par ligne, la méthode de facturation forcée commande par commande, une répartition analytique d'en-tête propagée aux lignes, et un taux de change forcé quand il a été négocié avec le fournisseur plutôt que subi.

L'essentiel

  • La commande cadre : prix et quantités négociés sur une période, commandes tirées au fil des besoins.
  • Un échéancier de facturation sur la commande d'achat, planifié à l'avance.
  • Deux façons d'enregistrer un acompte : avant confirmation, ou en facture d'acompte après.
  • Un statut de facturation par ligne, et pas seulement au niveau de la commande.
  • Le forçage du statut facturé, commande entière ou quantité par ligne.
  • Le montant non facturé en colonne : la part restant à facturer, visible dans la liste.
  • La méthode de facturation forcée par commande — sur commandé ou sur reçu.
  • Un taux de change manuel quand il est négocié, propagé jusqu'à la valorisation du stock.

Ce que ces modules ajoutent à l'instance

ModuleRôleVersion
purchase_blanket_orderCommandes cadres18.0.1.0.2
purchase_invoice_planÉchéancier de facturation18.0.1.0.2
purchase_advance_paymentAcomptes avant confirmation18.0.1.2.0
purchase_depositFacture fournisseur d'acompte18.0.1.1.1
purchase_invoice_methodMéthode de facturation forcée18.0.1.0.0
purchase_invoice_status_lineStatut de facturation par ligne18.0.2.0.1
purchase_force_invoicedForcer le statut « facturé »18.0.1.0.3
purchase_force_invoiced_quantityForcer une quantité par ligne18.0.1.1.1
purchase_order_uninvoiced_amountMontant non facturé en colonne18.0.1.0.0
purchase_order_uninvoiced_amount_lineMontant non facturé par ligne18.0.1.0.0
purchase_uninvoiced_amount_force_invoiced_lineColle entre les deux précédents18.0.1.0.0
purchase_analytic_globalAnalytique d'en-tête propagée18.0.1.0.0
purchase_manual_currencyTaux de change forcé18.0.3.0.0
purchase_stock_manual_currencyColle : le taux jusqu'au stock18.0.2.0.0

Quatre menus sont ajoutés : Achats ▸ Commandes ▸ Blanket Orders et ses lignes, Achats ▸ Commandes ▸ Purchase Invoice Plan, et Facturation ▸ Fournisseurs ▸ Paiements anticipés.

La commande cadre : négocier une fois, commander souvent

C'est la pratique normale d'un acheteur professionnel : on négocie un prix et un volume annuel, puis on commande au fil des besoins. Odoo Community ne connaît pas cette notion.

  1. Créer une commande cadre : un fournisseur, des produits, des quantités et des prix négociés, une période de validité.
  2. La confirmer : elle devient la référence contractuelle.
  3. Générer au fil des besoins des commandes d'achat qui en découlent, aux conditions convenues.
  4. Suivre la consommation du cadre : ce qui a été commandé, ce qui reste à commander.

Sans accord-cadre dans l'outil, le prix négocié vit dans un courriel et se perd au premier remplacement d'acheteur. Avec, il devient une donnée opposable — et la consommation du volume engagé devient mesurable, ce qui est l'argument de la prochaine négociation.

À distinguer des accords d'achat standards d'Odoo (appels d'offres), traités en amont dans les demandes d'achat : l'appel d'offres sert à choisir un fournisseur, le cadre à exploiter un accord déjà conclu.

Acomptes et échéanciers

Deux acomptes, deux moments

ModuleQuandCe qu'il produit
purchase_advance_paymentAvant confirmation et avant toute factureUn paiement anticipé suivi sur la commande (non payé / partiel / payé)
purchase_depositAprès confirmationUne facture fournisseur d'acompte, en pourcentage ou en montant, via un assistant

Le premier répond au fournisseur qui exige un paiement avant de lancer la production — fréquent à l'import et sur le matériel sur mesure. Le second reproduit côté achat le mécanisme d'acompte que les ventes connaissent déjà.

Les deux évitent le même piège : l'acompte réglé par virement, comptabilisé dans un compte d'attente, et retrouvé six mois plus tard sans savoir à quelle commande le rattacher.

L'échéancier

purchase_invoice_plan planifie à l'avance un échéancier de facturation : un nombre d'échéances, des dates, et la répartition du montant. Les factures fournisseur attendues sont alors connues — donc prévisibles en trésorerie.

C'est le symétrique du plan de facturation côté ventes, avec une différence de finalité : côté vente il sert à encaisser, côté achat à prévoir les décaissements.

Savoir ce qui reste à facturer, ligne par ligne

La question « que nous reste-t-il à recevoir comme factures ? » est celle de toute clôture. Odoo y répond au niveau de la commande ; ces modules descendent à la ligne.

  • purchase_order_uninvoiced_amount ajoute le montant non facturé en colonne dans les listes de commandes.
  • purchase_order_uninvoiced_amount_line fait de même par ligne, dans l'écran dédié aux lignes de commande.
  • purchase_invoice_status_line calcule un statut de facturation par ligne, et permet de forcer individuellement une ligne à « entièrement facturée ».
  • Un module de colle relie les deux derniers, pour que le montant non facturé tienne compte des lignes forcées.

Le gain n'est pas cosmétique : une commande de vingt lignes dont dix-neuf sont facturées apparaît comme « partiellement facturée » — information inutile. Le détail par ligne dit laquelle manque, et c'est ce qu'on envoie au fournisseur.

Solder ce qui ne viendra jamais

purchase_force_invoiced force le statut d'une commande verrouillée à « facturé », quand l'entreprise décide sciemment de ne plus attendre. purchase_force_invoiced_quantity descend au niveau de la ligne, pour réduire la quantité restant à facturer sans forcer toute la commande.

Ces deux modules sont, comme leurs équivalents côté vente, indispensables après une migration : sans eux, des commandes anciennes restent indéfiniment dans les écrans de suivi, et le chiffre du « non facturé » devient faux — donc ignoré.

Choisir la méthode de facturation

purchase_invoice_method force, commande par commande, la politique de contrôle de facturation : sur quantités commandées ou sur quantités reçues, indépendamment du réglage par produit.

Le cas d'usage : un fournisseur qui facture à l'expédition alors que vos produits sont réglés d'ordinaire à la réception. Sans ce module, il faut changer le réglage du produit — et l'oublier ensuite.

Analytique et devises

L'analytique d'en-tête

purchase_analytic_global ajoute une répartition analytique au niveau de l'en-tête de la commande et la propage à toutes ses lignes.

C'est le cas de la très grande majorité des achats : toute la commande concerne le même projet, le même chantier, le même centre de coût. Saisir l'imputation sur chaque ligne est une perte de temps et une source d'oubli — un oubli qui se paie en analytique faussée et en reventilation manuelle à la clôture.

Le taux de change négocié

purchase_manual_currency permet de forcer le taux de change d'une commande en devise étrangère, au lieu d'appliquer le taux du jour. Un module de colle garantit que ce taux est repris jusqu'à la valorisation du stock à la réception.

Le besoin est réel à l'import : le taux a été négocié avec le fournisseur, ou couvert par un contrat de change. Appliquer le taux du jour produit un écart qui se retrouve en différence de change — et une valorisation de stock fausse.

La présence du module de colle est ce qui rend le dispositif complet : un taux forcé qui ne descend pas jusqu'au stock donne une marge calculée sur une base erronée.

La valorisation du stock et ses écarts sont un sujet connexe, abordé côté comptable dans les états financiers.

Limites connues

  • La commande cadre n'est pas un engagement juridique : elle structure l'exploitation d'un accord, elle ne remplace pas le contrat signé.
  • Deux modules d'acompte coexistent : choisir selon le moment — avant ou après confirmation — et ne pas installer les deux sans règle d'usage.
  • Le forçage du statut facturé est définitif en pratique : à réserver à un rôle identifié, comme côté ventes.
  • Le statut par ligne suppose l'écran des lignes de commande (purchase_order_line_menu), qui est une dépendance.
  • Le taux manuel sans son module de colle laisse la valorisation du stock au taux du jour : installer les deux.
  • L'analytique d'en-tête écrase la saisie par ligne : à éviter quand une commande couvre réellement plusieurs axes.

Identité technique

Les quatorze modules viennent du dépôt OCA purchase-workflow, branche 18.0, tous en licence AGPL-3. Deux dépendent de modules d'autres dépôts : le taux de change manuel (account-financial-tools) et une extension d'héritage de vues (server-ux).

Les familles voisines : les demandes d'achat, l'approbation des achats et achats : types, remises et blocages.

Questions fréquentes

Odoo Community gère-t-il les accords-cadres fournisseurs ?

Pas en standard. purchase_blanket_order introduit la commande cadre : quantités et prix négociés sur une période, à partir desquels on génère des commandes successives, avec suivi de la consommation du volume engagé. Sans elle, le prix négocié vit dans un courriel et disparaît au premier changement d'acheteur.

Comment enregistrer un acompte versé à un fournisseur ?

Deux modules, selon le moment. purchase_advance_payment enregistre un paiement avant confirmation et suit l'état de paiement de la commande. purchase_deposit génère, après confirmation, une facture fournisseur d'acompte en pourcentage ou en montant. Les deux évitent l'acompte perdu dans un compte d'attente.

Peut-on savoir quelle ligne reste à facturer ?

Oui : purchase_invoice_status_line calcule un statut de facturation par ligne et permet de forcer individuellement une ligne à « entièrement facturée » ; purchase_order_uninvoiced_amount_line affiche le montant non facturé par ligne. Une commande « partiellement facturée » devient enfin exploitable : on sait laquelle des vingt lignes manque.

Comment solder des commandes d'achat qui ne seront jamais facturées ?

Avec purchase_force_invoiced (commande entière) ou purchase_force_invoiced_quantity (quantité par ligne). C'est indispensable après une migration : sans ces modules, des commandes anciennes restent dans les écrans de suivi et faussent le montant « non facturé », qui finit par être ignoré.

Peut-on appliquer un taux de change négocié avec un fournisseur ?

Oui, avec purchase_manual_currency, qui force le taux au lieu d'appliquer celui du jour. Installez aussi purchase_stock_manual_currency : sans ce module de colle, le taux forcé ne descend pas jusqu'à la valorisation du stock à la réception, et la marge se calcule sur une base erronée.

Se faire accompagner

Le segment commande-facture côté fournisseur est celui où les PME perdent le plus d'argent sans le savoir : des acomptes jamais soldés, des avoirs jamais réclamés, et un « reste à facturer » faux depuis si longtemps que personne ne le regarde.

Nous commençons donc par l'assainissement — solder les commandes mortes, rattacher les acomptes — avant d'installer quoi que ce soit. Un indicateur juste vaut mieux que trois modules sur une base fausse. Voir les prestations d'Atalios Consulting ou demander un rappel.

Pour aller plus loin

En résumé

L'accord-cadre qui survit au départ de l'acheteur, l'acompte qui ne se perd plus, le reste à facturer enfin juste parce qu'on peut solder ce qui ne viendra jamais, et le taux de change négocié qui descend jusqu'à la valorisation du stock. Parlons de vos engagements fournisseurs.

Documentation OCAAchatsFacturation

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