quote → cash
FR/EN Contact

Architecture·Référence·6 min·Mis à jour le 05/10/2026

Cas d’usage · Taxe

Plusieurs entités juridiques

Une org, plusieurs entités qui vendent, et des règles fiscales qui ne doivent pas fuir de l’une à l’autre.

Salesforce docs documenté par SalesforceTerrain constaté sur une vraie orgRecommandé ce que nous recommandonsÀ vérifier non vérifié

Le besoin métier

Un groupe vend via plusieurs entités juridiques dans des juridictions différentes. Chacune a ses règles fiscales, ses périodes comptables, et ne doit jamais appliquer le taux d’une autre.

Pourquoi ce n’est pas trivial

Avec plusieurs entités, le traitement peut être sélectionné par entité. Avec une seule, ce mécanisme de sélection n’a rien pour discriminer et ne fait silencieusement rien — une architecture qui marche en multi-entité n’est donc pas transposable en mono-entité, ni l’inverse.

L’architecture recommandée

Traitements et taux portés par entité, avec une policy qui sélectionne par entité juridique. Les périodes comptables sont également par entité.

Composants Salesforce

Sélectionnez-en un pour ouvrir son détail.

Le flux

Architecture fiscale transaction → code → taux
QUI QUELLE RÈGLE COMBIEN RÉSULTAT country selection looks up LegalEntity qui vend BillingAccount qui est facturé TaxPolicy comment choisir TaxTreatment produit × code TaxEngine le calculateur TaxRate code × pays × période InvoiceLineTax le seul endroit où le code atterrit

Scroll the diagram sideways

Deux choses décident de tout ici. D’abord, c’est le pays du profil de facturation qui commande le taux, pas l’adresse de la commande — vérifié dans les deux sens sur deux commandes aux adresses différentes et au même profil. Ensuite, aucun mécanisme natif ne fait varier le code de TVA par pays : TaxTreatmentItem n’a aucun champ géographique, et la decision table standard prend un code en entrée et rend un taux, donc elle ne peut jamais produire un code.

Mise en œuvre

  1. Un traitement par entité, la policy sélectionnant sur l’entité.
  2. Des taux rattachés à l’entité, pour qu’un taux ne puisse pas fuir.
  3. Des périodes par entité — en se rappelant qu’une période ne peut pas dépasser un an.

Attention

  • Avec une seule entité, la sélection par entité est inopérante. Résolvez au niveau du taux, ou posez le traitement sur la ligne.
  • Une période comptable ne peut pas dépasser un an : « une période ouverte » veut donc dire une par exercice.

Alternatives

Des orgs séparées donnent une isolation absolue et vous coûtent le reporting inter-entités et un second exemplaire de tout. Ça n’en vaut la peine que si les entités ne partagent réellement aucun client.

Ressources Salesforce