À propos

Nathan Altmann

Je suis architecte Salesforce Revenue Cloud chez Meir IT. J’implémente Revenue Cloud Advanced et Revenue Cloud Billing — catalogues, pricing, devis, facturation, taxe, routage comptable et génération documentaire — sur six implémentations, en production, en préproduction et sur des orgs de démonstration.

Ce site existe à cause d’un manque que je rencontrais sans arrêt. La documentation officielle décrit ce que sont les objets, et le fait bien. Ce qui manque partout, c’est la couche en dessous : ce qui échoue en silence, là où la documentation est en retard sur le schéma, et quelles décisions de conception coûtent cher à défaire. Cette couche-là, je l’écris ici au fur et à mesure que je la rencontre.

Ce que j’ai réellement construit

Chaque ligne renvoie à la page qu’elle a produite. C’est la seule forme de preuve qui vaille.

ProductCatalogues avec bundles, classifications, selling models et picklists dépendantes — dont un bundle portant vingt et une variantes matérielles en trois rôles.Lire ce que ça a produit →
PricingPricing procedures, decision tables et barèmes d’ajustement — et le plafond d’éléments, atteint à 128 sur 130 et traité par procedure plans.Lire ce que ça a produit →
TaxUne chaîne fiscale complète : entités juridiques, policies, traitements, taux et un adaptateur Apex écrit de bout en bout — plus un code de TVA par pays résolu sans une ligne d’Apex.Lire ce que ça a produit →
BillingDe la commande à la facture postée avec la bonne TVA, et les règles d’affectation comptable dessous — dont les critères ne sont plus modifiables une fois insérés.Lire ce que ça a produit →
DocumentsDocuments de devis générés sur la définition de contexte du pricing, ce qui supprime entièrement la couche d’extraction.Lire ce que ça a produit →
MigrationConfiguration de pricing déplacée entre orgs, et les raisons pour lesquelles une procédure qui marche ici ne rend rien ailleurs.Lire ce que ça a produit →

Les questions sont les bienvenues

Si vous évaluez Revenue Cloud, si vous l’implémentez, ou si vous bloquez sur un point précis, demandez. Je préfère répondre à une question précise que publier une page vague — et ce sont généralement les questions qui me disent quoi écrire ensuite.

Les corrections surtout. Si quelque chose ici est faux sur votre org, ça vaut la peine de le savoir : chaque affirmation porte son registre, et ce qui s’avère faux est corrigé ou retiré, pas atténué.

Comment les affirmations sont étiquetées

Chaque affirmation de fond porte l’un de ces registres, pour que vous sachiez toujours ce que vous lisez :

Salesforce docs documenté par Salesforce, avec le lien vers la page.
Terrain constaté sur une vraie org, à une version d’API précisée.
Recommandé une architecture que nous recommandons, avec ses contreparties énoncées.
À vérifier cru, pas prouvé. À traiter comme une hypothèse.

Ce que ce site n’est pas

Sans lien avec Salesforce. Ni approuvé, ni sponsorisé, sans accès privilégié. Salesforce, Revenue Cloud, Agentforce et les marques associées appartiennent à salesforce.com, inc.
Pas une vitrine client. Aucun client n’est nommé, et aucune donnée, capture ou livrable client n’est publié. Les contextes ne sont décrits que par leur forme, et la génération refuse de publier si un nom identifiant s’y glisse.
Pas un substitut à votre org. Ce qui est décrit comme constaté l’a été sur une org donnée à une version d’API donnée. Le comportement de la plateforme change d’une release à l’autre. Vérifiez avant de construire.
Pas exhaustif. Ça couvre ce que j’ai réellement fait. Les trous sont réels, et je préfère des trous à du contenu inventé.

Sur les liens Salesforce

Aucune URL Salesforce de ce site n’est tapée à la main. La génération télécharge les sommaires officiels et résout chaque référence contre eux ; un lien non résolu casse la génération au lieu de vous atteindre. La version du guide au dernier build était Winter ’27 (API 68.0).