Modifications de commandes d'abonnement

Pour ajuster ou annuler partiellement une commande activée en milieu de cycle, vous devez utiliser une modification de commande pour ajout. Le connecteur met à jour la planification d’abonnement dans Stripe avec les nouveaux produits et la quantité de la modification de commande dans Salesforce. Le connecteur utilise le même mappage que l’intégration de la commande initiale.

Dates de début et de fin

Les modifications de commande ne doivent pas comporter d’intervalle entre les dates de début et de fin. Pour éviter toute erreur, la date de début de la modification de commande doit être située :

• Au plus tard à la date de fin de la commande précédente ou de la modification de commande précédente, ou
• La même date de début que la commande initiale ou que la modification de commande précédente

Toutes les modifications de commande doivent prendre fin en même temps que la commande initiale. Salesforce CPQ combine la date de début d’un contrat à la durée de l’abonnement pour déterminer la date de fin. Cela signifie que toutes les modifications de commande doivent avoir la même date de fin (date de début et durée de l’abonnement).

Deltas de commande

Une modification de commande n’inclut que le delta de la commande précédente. Le connecteur extrait toutes les commandes précédentes et agrège tous les postes de facture « précédents » pour déterminer les postes d’abonnement à inclure dans la nouvelle phase de planification d’abonnement. Les postes de chaque phase d’abonnement dans Stripe ne sont pas réutilisés ni associés aux postes précédents.

Contrats de commande

Pour modifier un abonnement dans Stripe, vous devez associer une commande et une modification de commande au même contrat. Salesforce CPQ le fait automatiquement pour chaque commande et modification de commande ayant fait l’objet d’un contrat.

Nous vous recommandons de procéder à cette opération à partir de la commande dans Salesforce CPQ. L’objet Contract de Salesforce n’est pas représenté directement dans Stripe.

Tarifs des postes

À moins que le tarif du poste de commande ne change, Stripe utilise le même objet Price pour toutes les phases de planification d’abonnement.

Vérifier et résilier des lignes de commande

Lorsque vous résiliez partiellement ou totalement une ligne de commande précédente, cette action crée une ligne de commande de quantité négative dans Salesforce. Stripe n’autorise pas les postes négatifs. Si une modification de commande supprime un produit ou une certaine quantité d’un produit d’un abonnement, les lignes de commande dont la quantité est négative sont ajoutées aux lignes de commande précédentes qu’elles révisent.

Prenons l’exemple d’une commande initiale comportant un poste dont la quantité est de 2. La modification de commande réduit la quantité de 1. Par conséquent, la nouvelle phase de planification d’abonnement dans Stripe a un poste d’abonnement unique avec une quantité de 1.

Pour les lignes de commande dont la quantité est positive, le connecteur crée un poste de phase de planification d’abonnement unique dans Stripe.

Tous les postes de commande qui modifient une ligne de commande dans une modification de commande précédente doivent apparaître dans la phase d’abonnement précédente. En d’autres termes, si vous ignorez le poste d’une commande, vous devez ignorer ce poste dans la modification de commande si vous modifiez le poste.

Plusieurs lignes de commande avec le même produit et le même tarif

Stripe n’autorise pas que plusieurs postes de phase de planification d’abonnement possèdent le même ID de tarif. Salesforce n’est pas soumis à cette limitation.

Si vous utilisez le même tarif sur plusieurs lignes de commande, le connecteur :

• Duplique le tarif dans Stripe
• Ajoute le tarif à la phase de planification d’abonnement
• Archive le tarif une fois utilisé (active = false)

Les tarifs dupliqués dans Stripe contiennent les métadonnées suivantes :

• salesforce_duplicate = true : indique que le tarif est un doublon d’un autre tarif
• salesforce_auto_archive = true : archive automatiquement le tarif après utilisation
• salesforce_original_stripe_price_id = price_xyz : inclut l’ID du tarif utilisé pour le tarif dupliqué

Modifications en cours de mois

Le connecteur exige que toutes les modifications de commande présentent la même date de fin que la commande initiale. Si la commande modifiée commence un jour du mois différent de celui de la commande initiale, vous devez appliquer la procédure suivante :

• Définir la date de fin de la commande modifiée.
• Définir la durée de l’abonnement sur le nombre de mois entiers dans la commande modifiée.

Exemple de modification de commande en cours de mois :

Modifications antidatées

Le connecteur traite les modifications rétroactives en temps réel. Une modification de commande antidatée commence dans le passé, ce qui signifie que la dernière phase de la planification d’abonnement ne correspondra pas à la date de début de la modification de commande.

Par exemple, un client souhaite modifier un abonnement existant et transmet la commande modifiée via le connecteur à une date ultérieure à celle d’entrée en vigueur de l’abonnement.

Modifications le jour même

Le connecteur peut traiter les modifications le jour même, notamment dans les scénarios suivants :

• Un abonnement débute aujourd’hui et le client souhaite modifier son contrat le jour même de son entrée en vigueur.
• Un abonnement débute à une date ultérieure et le client souhaite modifier la commande avec des dates de début et de fin identiques à celles de la commande d’origine.

Modifications le jour même pour un abonnement existant

Dans ce cas, le connecteur traite la modification comme une modification de commande pour calcul au prorata, à quelques différences près :

• La date de fin de la phase précédente utilise la valeurnow, au lieu de minuit de la journée en cours (qui, dans cet exemple, est déjà passée).
• La date de début de la phase suivante (par exemple, la modification de commande) utilise également la valeur now.
• Les montants des postes calculés au prorata sont égaux au montant total à facturer pour la durée du contrat.

Modifications futures le jour même

Si un abonnement n’a pas encore commencé, vous ne pouvez pas utiliser la valeur now dans la modification du jour de début de l’abonnement. Dans ce cas, le connecteur :

• Collecte tous les postes ponctuels de la commande (qu’il s’agisse de la commande initiale ou de la modification) qui partagent la même période de commande (par exemple, les dates de début et de fin)
• Ajoute ces postes à la nouvelle phase
• Supprime la phase correspondant à la commande précédente

Stripe supprime complètement les métadonnées de la phase de planification d’abonnement associées à la commande précédente.

Exemple de modification de commande pour ajout

Voici un exemple de modification de commande et de mappage avec Stripe Billing.

Commande initiale : la commande initiale combine le client et la planification d’abonnement en une seule phase d’abonnement dans Stripe.

Modification de commande : le 15 janvier 2022, vous créez une modification de commande dans Salesforce pour la commande initiale.

La commande initiale et la modification de commande présentent les valeurs suivantes :

Dans Salesforce CPQ, la modification de commande représente le produit A sous la forme d’une ligne de commande dont la quantité est -4 (diminution de la quantité 4). Étant donné que le tarif unitaire est identique, Stripe utilise le même objet Price sur le poste de la phase de planification d’abonnement.

Après l’activation de la modification de commande, la planification d’abonnement est mise à jour afin d’inclure les phases suivantes :

Pour résilier un contrat dans son intégralité, vous devez utiliser une modification de commande pour résiliation. La modification de la commande définit la quantité de tous les postes de la commande à 0.

Une fois cette opération effectuée, le connecteur met à jour la date de fin de la dernière phase de planification d’abonnement de manière à refléter la date de début de la modification de commande pour résiliation.

Pour résilier définitivement une commande le jour même de son début, vous devez annuler la planification d’abonnement au lieu de modifier la phase précédente.

La date de début d’une modification de commande pour calcul au prorata doit être située en dehors des limites du cycle de facturation, et sa date de fin doit être différente de la fréquence de facturation.

Prenons l’exemple d’une commande d’une durée d’un an et demi à compter du 6e mois qui modifie un contrat de 2 ans, facturé annuellement. Cette commande est une modification de commande pour calcul au prorata. Vous facturez le client au prorata à la date de début de la modification pour la partie de la commande qui ne relève pas du cycle de facturation standard.

Lorsque vous créez une modification de commande pour calcul au prorata dans Salesforce, le connecteur effectue les actions suivantes dans Stripe pour chaque ligne de commande à calculer au prorata :

• Crée un nouvel objet Price pour représenter le montant calculé au prorata.
• Ajoute un poste de facture avec le nouveau tarif à la nouvelle phase pour représenter le montant au prorata.
• Met à jour la quantité du poste d’abonnement pour intégrer la modification au moment de son entrée en vigueur, sans rien facturer au-delà du montant calculé au prorata.

Stripe Billing envoie une facture pour le montant total du produit et la quantité à la fin du cycle de facturation. Dans l’exemple ci-dessus, le cycle de facturation se termine le 12e mois et la facture s’élève à 120 USD x 2 = 240 USD.

Vous ne pouvez pas calculer au prorata les tarifs suivants :

• Tarifs configurés pour la facturation à la consommation : le montant dû est calculé au terme du cycle de facturation.
• Tarifs ponctuels et non récurrents : ils sont facturés immédiatement sans être associés à un cycle de facturation.
• Tarification basée sur une grille tarifaire créée à partir de planifications de consommation.

Exemple de modification de commande pour calcul au prorata

Voici un exemple de modification de commande et la façon dont elle est représentée dans Stripe.

Un poste au prorata dans Stripe représente le montant au prorata du poste de commande. Cela signifie un débit pour la période calculée au prorata jusqu’à la fin du cycle de facturation.

Le calcul au prorata de Stripe Billing crée deux postes au prorata :

• Un crédit pour la période non consommée de l’ancienne offre
• Un débit pour la durée d’utilisation calculée au prorata jusqu’à la fin de la période de facturation

Vous ne voyez pas le poste correspondant au crédit dans Stripe lorsque vous utilisez les données de proratisation calculées par Salesforce CPQ.

Utiliser les calculs au prorata de CPQ

Lorsque des informations de facturation figurent dans CPQ, elles sont considérées comme la source de vérité par le connecteur. Cela permet à d’autres systèmes financiers (comme Stripe) et outils de reporting financier (comme NetSuite ou QuickBooks) de rapprocher la proratisation et les autres données financières. Par défaut, le connecteur utilise la CPQ Subscription Prorate Precision égale à Month. Le connecteur prend également en charge la CPQ Subscription Prorate Precision égale à Monthly and Daily.

Dans certains cas, les montants ne correspondent pas exactement sur Stripe et Salesforce, car certains calculs sont uniquement effectués par Stripe et n’existent pas dans CPQ. Par exemple, les données relatives aux taxes et à la facturation à la consommation n’existent que dans Stripe.

Calculer des tarifs au prorata

Dans Salesforce, un poste au prorata contient les informations suivantes :

• Durée de l’abonnement
• Montant unitaire (mappé à unit_decimal_amount dans Stripe)
• Quantité
• Fréquence de facturation (mappée dans recurring.interval et recurring.interval_count sur Stripe)
• Date de début

Précision de calcul au prorata Salesforce CPQ mensuel

Pour déterminer quelle partie du poste de commande doit être calculée au prorata lorsque CPQ Subscription Prorate Precision est défini sur Month :

1. Calculez la durée (en mois) de l’abonnement à exclure du cycle de facturation. Pour cela, utilisez la date de début, la durée de l’abonnement et la fréquence de facturation du poste.
2. Calculez le coût mensuel du poste. Divisez la valeur mappée dans unit_amount_decimal par la durée de l’abonnement.
3. Multipliez le coût mensuel (valeur de l’étape 2) par le nombre de mois exclus du cycle de facturation (valeur de l’étape 1).

Prenons l’exemple d’un abonnement pour lequel six mois sont exclus du cycle de facturation. Le coût mensuel du poste est de 10 USD, calculé en divisant un montant unitaire de 180 USD par une durée d’abonnement de 18 mois. En multipliant le coût mensuel de 10 USD par six mois, vous obtenez 60 USD.

Précision de calcul au prorata Salesforce CPQ mensuelle et quotidienne

Pour déterminer quelle partie du poste de commande doit être calculée au prorata lorsque CPQ Subscription Prorate Precision est défini sur Monthly and Daily :

1. Calculez le mois partiel (à la fin de la durée de l’abonnement) qui n’est pas inclus dans le cycle de facturation. Le mois partiel est égal au nombre de jours non compris dans le cycle de facturation.
2. Calculez le coût quotidien du poste. Divisez la valeur mappée dans unit_amount_decimal par le nombre de jours dans un mois. CPQ obtient ce nombre en divisant le nombre de jours dans une année par le nombre de mois dans une année (365 divisé par 12).
3. Multipliez le coût quotidien (valeur de l’étape 2) par le nombre de jours exclus du cycle de facturation (valeur de l’étape 1).

Le connecteur effectue les calculs au prorata en fonction du paramètre CPQ Subscription Prorate Precision.

Calculer des tarifs au prorata à l’aide de champs de tarif personnalisés

En règle générale, UnitPrice correspond à unit_price_decimal dans Stripe. Vous pouvez également utiliser un champ personnalisé pour le tarif. Le connecteur part du principe que le champ personnalisé spécifié correspond au tarif du produit pour l’ensemble du cycle de facturation.

Imaginons par exemple que vous spécifiez un champ tarifaire personnalisé de 120 USD plutôt que d’utiliser la valeur de 180 USD pour le UnitPrice. Pour un cycle de facturation trimestriel, le coût par trimestre est de 30 USD, soit 120 USD divisés par quatre trimestres.

Pour une ligne de commande calculée au prorata, le connecteur considère que la valeur du champ de tarif personnalisé correspond au montant total du cycle de facturation. Le connecteur calcule le montant au prorata à partir de cette valeur.

Représenter des calculs au prorata avec des tarifs uniques

Cette approche a pour particularité de générer un objet Price sur Stripe pour représenter le montant calculé au prorata. Chaque montant calculé au prorata crée dans Stripe un objet Price associé au même produit que le tarif initial entièrement facturé. En d’autres termes, deux objets Price distincts sont créés pour représenter le poste de facturation au prorata et le poste d’abonnement non facturé au prorata.

Les métadonnées de l’objet Price indiquent qu’il a été créé à cette fin : salesforce_proration => true.

Ces tarifs sont automatiquement archivés (active=false) après avoir été utilisés pour un abonnement.

Facturation des postes de facture au prorata

Lorsque la phase de modification de commande pour calcul au prorata débute, un poste de facture en attente est ajouté à l’abonnement du client.

Le connecteur écoute les nouveaux postes de facture pour déterminer s’ils sont calculés au prorata. Si tel est le cas, le connecteur crée et finalise une facture pour l’abonnement. Le client est facturé au prorata de son abonnement.

Vous ne pouvez pas spécifier les postes à facturer pour un abonnement. Tous les postes de facture en attente associés à l’abonnement sont facturés.