quote → cash
FR/EN Contact

Architecture de référence·Référence·8 min·Mis à jour le 05/10/2026

Cas d’usage · Devis

Activité par abonnement

Abonnements à terme, avenants, renouvellements — et l’échéancier de facturation qui doit tenir le tout.

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

Le besoin métier

Vendre un abonnement à terme, laisser le client le modifier en cours de période, le renouveler à l’échéance, et facturer tout ça correctement sans que personne ne rapproche à la main.

Pourquoi ce n’est pas trivial

Le difficile n’est pas la première commande. C’est le deuxième changement. Un avenant doit être pricé contre ce que le client détient actuellement, produire un delta plutôt qu’un remplacement, et faire parvenir ce delta à la facturation — ce qui suppose que l’état de l’actif, le pricing et la facturation soient d’accord sur les mêmes dates.

L’architecture recommandée

Un selling model à terme sur le produit, un cycle de vie d’actif qui enregistre l’état dans le temps, et des échéanciers générés depuis la commande. Les avenants sont de nouvelles transactions lues contre l’état courant de l’actif, pas des modifications de l’originale.

Composants Salesforce

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

Le flux

Cycle de vie des avenants actif → delta → facturation
ÉTAT COURANT CHANGEMENT EFFET read delta Contrat les conditions Actif ce qui est détenu AssetStatePeriod l’état dans le temps Avenant une nouvelle transaction Ligne de devis la nouvelle forme Commande le delta Échéancier ajusté

Scroll the diagram sideways

Un avenant est une nouvelle transaction lue contre l’état courant de l’actif, pas une modification de l’ancienne. C’est pour ça que les périodes d’état comptent : elles sont ce qui permet de dire ce que le client détenait le jour où le changement prend effet, et donc quel doit être le delta de facturation.

Mise en œuvre

  1. Poser le selling model avant qu’un prix n’existe. Il est obligatoire sur le PricebookEntry et non modifiable ensuite.
  2. Remplir les champs de période sur la ligne de commande — period boundary, mois et jour de début de période, fréquence de facturation. Le moteur les exige et ne les signale pas comme obligatoires.
  3. Utiliser StartDate, pas ServiceDate. C’est la première que le moteur lit.
  4. Prouver tôt le chemin de l’avenant, avec un vrai changement sur un vrai actif, avant que le catalogue ne grossisse.

Attention

  • Un produit one-time refuse une fréquence de facturation et une date de fin. Mélanger du one-time et du récurrent dans un bundle suppose des selling models justes composant par composant.
  • Les dates de segment de ramp sont verrouillées sur un segment annuel et éditables sur un segment custom — ce qui ressemble à un bug de date est un type de segment.

Alternatives

Quand le modèle commercial est réellement simple et jamais amendé, un prix récurrent fixe sur le PricebookEntry sans cycle de vie d’actif est plus léger. Dès que le changement en cours de période devient réel, ce raccourci doit être défait.

Ressources Salesforce

Guide