Billing·Avancé·12 min·Mis à jour le 05/10/2026
Guide · Facturation
De la commande à la facture : où commence vraiment la facturation, et pourquoi elle ne commence pas
Entre une commande activée et une facture postée, il y a un orchestrateur, une définition de contexte, quatre réglages d’org et des champs de ligne de commande que personne ne vous dit obligatoires. Chacun échoue sans erreur.
La forme de la chaîne
Une commande activée ne devient pas directement une facture. Elle est décomposée en exécution, elle produit des échéanciers de facturation, ces échéanciers sont ramassés par un batch de facturation, et la facture brouillon qui en sort est postée dans une période comptable. Cinq passages de relais, et les modes d’échec se concentrent sur le premier et le dernier.
La couche d’orchestration de Salesforce côté exécution est le Dynamic Revenue Orchestrator, qui décompose une transaction commerciale en lignes d’exécution et maintient les actifs d’exécution et leurs périodes d’état. Il a sa propre famille d’objets et ses propres actions invocables : lisez l’aperçu officiel avant de concevoir autour.
Quatre prérequis, dont aucun ne signale quoi que ce soit
C’est la section qui vaut tout l’article. Sur une implémentation, les commandes s’activaient proprement et aucun échéancier n’était jamais créé. Pas d’erreur, pas d’e-mail d’échec de flow, et rien à regarder dans le batch de facturation — le batch ne trouvait simplement rien à facturer.
Ce qui devait être vrai, et qui est invisible jusqu’à ce que la première facture échoue :
- La release update sur le comportement de sauvegarde des commandes. Rangée sous l’onglet archivé, là où personne ne va chercher quelque chose d’encore requis.
- La définition de contexte billing étendue et activée, puis déclarée dans les réglages de facturation comme context service mapping. L’étendre ne suffit pas ; l’activer ne suffit pas ; il faut la déclarer.
- Le bon intra-context mapping. Celui du groupe d’échéanciers, pas celui de la commande. Les deux sont voisins dans la liste et l’un des deux ne produit aucun échéancier et aucune erreur.
- Les billing defaults — entité juridique, billing treatment, tax treatment. Des valeurs par défaut manquantes ne bloquent pas l’activation ; elles bloquent la sortie.
Les champs de ligne obligatoires sans l’être
Une fois l’org configurée, la donnée a sa propre version du même piège. Un profil de
facturation ne produit rien sans contact de facturation, sans payment term et sans adresse de
livraison. Et la ligne de commande exige PeriodBoundary,
PeriodBoundaryStartMonth, PeriodBoundaryDay et
BillingFrequency2.
Aucun des quatre n’est signalé comme obligatoire. L’enregistrement se sauve. La commande s’active. Rien ne se facture.
À l’échelle d’une commande de test, c’est un après-midi. À l’échelle d’une reprise de données, c’est tout le projet : un import de milliers de comptes passera toutes les validations et ne facturera rien du tout. Prouvez la chaîne sur un seul enregistrement avant de charger le reste — jusqu’à la facture postée, pas seulement jusqu’à la commande activée.
Le payment term est sur la commande
Le payment term qui détermine la date d’échéance vit sur la commande, pas sur le profil de facturation. Nous l’avons d’abord cherché sur le profil, parce que c’est là que la documentation le suggérait, et le champ n’était tout simplement pas sur l’objet au describe.
La leçon générale dépasse largement ce champ. Sur ces objets récents, la documentation publique est en retard sur le schéma. Vérifiez par un describe avant de conclure qu’il faut du custom — et tout autant avant de conclure qu’un champ documenté existe.
Le critère de flow qui n’est jamais parti
Sur une org, le passage de la commande à l’échéancier passait par un flow. Le flow filtrait
sur Status = "Activated". L’org tourne en français, où cette valeur s’affiche
Activé. Le critère n’a jamais matché. Le flow n’est jamais parti. Aucun échéancier n’a
jamais été créé.
Rien n’a échoué — et c’est tout le problème. Un flow qui n’agit pas est indiscernable d’un flow qui a agi et n’a rien trouvé à faire. Il n’y a aucune erreur à trouver.
Généralisons : tout critère de flow qui compare à une valeur affichée est suspect sur une org localisée. Comparez aux noms d’API.
Ce que la facture ne porte pas
Une fois les factures produites, la surprise suivante est de voir à quel point elles
portent peu. La facture n’a aucun champ pays. Sa référence au profil de
facturation est nulle. Et Invoice.BillingAccountId pointe vers
Account, pas vers l’objet BillingAccount — un piège de nommage qui envoie les
règles comptables chercher au mauvais endroit.
Sur la ligne, InvoiceLine.TaxCode est toujours vide, postée ou
non. Le vrai code de TVA vit sur InvoiceLineTax, ou doit être redescendu par un
champ formule depuis le traitement.
Conséquence de conception : tout ce sur quoi vous comptez router, reporter ou rapprocher doit être redescendu sur la ligne délibérément, en général par un champ formule. Le découvrir après avoir écrit quarante règles d’affectation comptable coûte cher, parce que ces règles ne sont plus modifiables une fois leurs critères insérés.
Le postage
Invoice.Status n’est pas writeable. Le postage passe par l’action standard
plutôt que par une mise à jour, et la période comptable doit être ouverte — en se rappelant
qu’une période ne peut pas dépasser un an, donc « une période ouverte » veut
dire une par exercice, pas une par mois.
À quoi ressemble une chaîne qui marche
Sur une implémentation, la chaîne de bout en bout a été prouvée par une seule facture portant la bonne TVA : un montant HT, vingt pour cent de taxe, un TTC juste au centime, et des écritures comptables attribuées par une règle d’affectation nommée. Cette unique facture a validé simultanément le context mapping, les billing defaults, les champs de ligne, la chaîne fiscale et le routage comptable.
Ça vaut la peine de construire cette preuve unique, délibérément et tôt. C’est le seul artefact qui teste les cinq relais d’un coup.
Composants Salesforce
Sélectionnez-en un pour ouvrir son détail.
Sur quoi ça repose
- Tous les prérequis listés ici ont été découverts par l’échec sur une implémentation réelle, en API 67, puis corrigés. Les comportements sont rapportés comme constatés, pas comme documentés.
- La couche d’orchestration est documentée par Salesforce ; les modes d’échec autour ne le sont pas.