Configurer un catalogue produits dans Revenue Cloud

Le Product Catalog Management (PCM) est le socle sur lequel repose tout le reste de Revenue Cloud : tarification, devis, commandes et facturation viennent tous lire les définitions posées ici. Une erreur de modélisation à ce niveau se répercute sur l'ensemble de la chaîne. Ce guide détaille les étapes concrètes pour construire un catalogue propre et évolutif.

Les objets clés du catalogue

Contrairement à CPQ où Product2 suffisait pour presque tout, Revenue Cloud répartit l'information sur plusieurs objets :

• Product2 : la fiche produit de base, inchangée dans son principe.
• ProductSellingModel : définit comment le produit est vendu (One-time, Evergreen subscription, Term subscription, Usage-based).
• ProductSellingModelOption : relie un produit à ses modèles de vente disponibles.
• ProductCategory et ProductCatalog : organisent la hiérarchie du catalogue, utile pour le filtrage dans le configurateur.
• ProductAttributeDefinition et AttributePicklist : décrivent les caractéristiques configurables (couleur, capacité, niveau de service).
• ProductRelatedComponent : remplace les anciens Product Options pour construire des bundles.

Créer un produit simple avec plusieurs modèles de vente

Prenons l'exemple d'une licence logicielle vendue soit en achat unique, soit en abonnement annuel. Étapes dans Setup :

1. Créer le Product2 classique (nom, code, famille).
2. Depuis l'app Revenue Cloud, ouvrir l'onglet Product Selling Models et créer un enregistrement de type One Time puis un second de type Term Subscription avec une durée par défaut (12 mois).
3. Lier chaque Selling Model au produit via ProductSellingModelOption.
4. Associer un Price Book Entry distinct pour chaque combinaison produit/selling model, car le prix peut différer entre achat et abonnement.

C'est cette séparation entre le produit et son modèle de vente qui permet, plus tard, de piloter des règles de tarification et de facturation différentes pour un même article sans dupliquer la fiche produit.

Construire un bundle avec des composants configurables

Pour un bundle (par exemple une offre « Suite Collaboration » composée d'un produit principal et de modules optionnels), la logique est proche de CPQ mais les objets changent :

• Le produit parent est marqué comme bundle via le champ Type sur Product2.
• Chaque composant est ajouté via ProductRelatedComponent, avec un ProductRelationshipType qui définit s'il est obligatoire, optionnel ou par défaut.
• Les quantités min/max, la sélection unique ou multiple se paramètrent au niveau du composant, pas via des Product Rules séparées comme en CPQ.

Pour des configurations plus fines (par exemple : « si le module A est sélectionné, le module B devient obligatoire »), on utilise les Configuration Rules, un moteur déclaratif qui remplace les anciens Product Rules avec des conditions Boolean.

Utiliser les attributs pour la configuration dynamique

L'Attribute-Based Configuration permet de définir des caractéristiques comme la capacité de stockage ou le nombre d'utilisateurs sans créer une fiche produit par variante. On définit un ProductAttributeDefinition (par exemple « Nombre de licences »), on l'attache au produit via ProductAttributeCategory, puis on peut faire varier le prix en fonction de la valeur choisie grâce à une Attribute-Based Pricing (traitée en détail dans notre article sur la tarification).

Piège fréquent : vouloir recréer l'intégralité de la logique de bundle CPQ à l'identique dans Revenue Cloud. Le modèle par composants et attributs est plus puissant mais demande de repenser la structure du catalogue plutôt que de la transposer telle quelle.

Bonnes pratiques de gouvernance

• Nommer les ProductSellingModel de façon cohérente dans toute l'org (éviter les doublons « Monthly » vs « Mensuel »).
• Centraliser la hiérarchie des ProductCategory avant de commencer la saisie en masse.
• Utiliser le Data Loader ou l'API Bulk pour l'import initial : la saisie manuelle produit par produit n'est pas viable au-delà de quelques dizaines de références.
• Documenter chaque Configuration Rule dans un tableau de correspondance métier, car leur logique n'est pas toujours lisible directement dans l'interface.

Une fois le catalogue posé, l'étape suivante consiste à brancher les règles de prix et de remise, qui viennent s'appuyer directement sur cette structure de produits, modèles de vente et attributs.