Pattern·Avancé··Mis à jour le 05/10/2026
Pattern · Facturation
Router les lignes de facture vers la comptabilité
Amener les lignes de facture sur le bon compte comptable quand la facture ne porte presque aucune des informations dont vous avez besoin pour router.
Le problème
La comptabilité veut chaque ligne de facture sur le bon compte, par famille de produit et par zone fiscale. Les règles d’affectation existent. L’information dont elles ont besoin, non.
Le contexte
Un plan comptable avec plusieurs familles de produits, et une dimension fiscale par-dessus. Des dizaines de règles, maintenues par un comptable plutôt que par un administrateur.
L’architecture recommandée
La contrainte qui pilote toute la conception : une ligne de facture ne peut être routée que sur ce que la facture porte. Et la facture porte étonnamment peu : aucun champ pays, une référence au profil de facturation nulle, et un TaxCode sur la ligne qui reste vide même après postage.
Redescendez donc les deux dimensions de routage sur la ligne par des champs formule : la zone fiscale depuis le compte, la famille comptable depuis le produit. Les règles matchent ensuite sur famille × code, avec une seule source de vérité.
Mise en œuvre
- Ajouter les deux dimensions là où elles sont maintenues : la zone sur le compte, la famille sur le produit.
- Les redescendre sur la ligne de facture en champs formule.
- Désactiver la règle avant d’ajouter le moindre critère.
- Prouver chaque règle avec une vraie facture postée. Rien d’autre ne la prouve.
Ce que ça coûte
Des champs formule, c’est un routage qui suit la valeur courante de la source, pas celle au moment de la facture. Pour une zone fiscale c’est en général ce que veut la comptabilité ; pour tout ce qui doit être figé au postage, utilisez un champ texte écrit une fois.
Attention
- Les critères sont insert-only. Ni update, ni delete, ni en Apex ni par API. Une erreur est définitive, et une règle qui porte un critère ne peut plus être supprimée — seulement désactivée. La sortie consiste à ajouter un critère de séquence supérieure et à changer la logique de filtre.
- Aucune validation du nom de champ à l’insert. N’importe quelle chaîne passe, y compris un champ inexistant. L’erreur ne sort qu’au postage.
Invoice.BillingAccountIdpointe vers Account, pas vers l’objet BillingAccount. Un piège de nommage qui envoie les règles chercher au mauvais endroit.- Un champ custom déployé est invisible à SOQL et à Apex tant que la FLS n’est pas accordée — SOQL répond « No such column », ce qui se lit exactement comme un échec de déploiement.