Pricing·Avancé·8 min·Mis à jour le 05/10/2026
Note de terrain · Pricing
Pourquoi une pricing procedure qui marche dans une org ne rend rien dans la suivante
Le pricing n’est pas un artefact mais cinq, et n’en déplacer qu’une partie produit une procédure qui s’exécute et ne price rien.
Une pricing procedure est la partie visible. Dessous vivent la définition de contexte qu’elle lit, les decision tables qu’elle appelle, les barèmes d’ajustement qu’elle applique et les PricebookEntry dont elle part. Déplacez la procédure seule : elle s’exécute proprement, ne rend rien, et ressemble à un bug de pricing.
Deux détails rendent la chose pire qu’un problème de dépendances ordinaire.
D’abord, les steps de procédure peuvent porter des identifiants d’enregistrement en dur. Les identifiants ne survivent pas à un changement d’org. Un step qui applique un barème par identifiant n’applique silencieusement rien dans l’org cible, et la configuration paraît identique des deux côtés.
Ensuite, la procédure qui s’exécute est la version compilée, pas la source que vous éditez. Sur une org, la source portait 81 steps standard et la version compilée en portait 128. Inspecter la source pour vérifier une migration ne prouve absolument rien.
La seule vérification qui veut dire quelque chose, c’est de repricer un vrai devis dans l’org cible et de lire les totaux de ligne.