定价架构更改

CPQ 中的定价

Salesforce CPQ 中的定价围绕规则引擎构建。价格规则评估条件，并按照定义的顺序应用调整。执行顺序很重要，更改顺序会更改结果。

常见的 CPQ 定价结构包含这些组件。

• 价格规则基于条件，按顺序运行，以计算标价、净价和特殊定价。
• 折扣计划是基于数量和基于期限的折扣表，适用于报价行。
• 批量定价是基于数量范围的分层定价。
• 合同价格是存储为 CPQ 自定义记录的特定于客户的定价覆盖。
• 报价计算插件 (QCP) 是规则引擎无法本地处理的自定义代码。这些插件支持边距防护、跨行计算、动态可见性和规则引擎无法表达的任何逻辑。虽然 QCP 提供了灵活性，但随着时间的推移，当规则累积、规则之间的依赖性变得隐蔽以及缺乏全面的文档时，它们会变得难以维护。

收入管理中的定价

收入管理使用结构化定价程序模型替换顺序规则引擎。定价程序是定价元素的命名有序顺序。每个元素执行特定的定价操作，例如应用价格手册价格、应用折扣、添加附加费或计算保证金下限。

• 定价程序比 CPQ 价格规则集具有更大的灵活性和能力。它们定义了给定上下文的定价计算瀑布图，例如直接销售、合作伙伴渠道或电子商务。它们定义了给定上下文的定价计算瀑布图，例如直接销售、合作伙伴渠道或电子商务。
• 定价元素是程序中的单个步骤。每个元素都有手动调整、折扣计划、价格列表、基于属性的定价等类型。请参阅在定价程序中使用定价元素。
• 程序计划根据上下文定义应用哪个定价程序。这些计划为每个渠道、客户群或产品类别启用不同的定价逻辑，而不会重复规则。
• 基于属性的定价会根据配置属性以不同方式定价产品，而无需为每个变体提供单独的 SKU 或价格规则条件。
• 使用或消耗定价是基于消耗和分层使用模型的本地评级引擎。不需要自定义代码。
• 合同项目定价通过使用标准收入管理对象提供特定于客户或特定于合同的价格覆盖，并替换 CPQ 的 ContractedPrices 自定义记录。

与 CPQ 价格瀑布图相比，收入管理中的定价非常灵活，也更容易维护。以下是收入管理中报价行项目的价格瀑布图示例。

通过将这些折扣按顺序应用于标价 15000 来计算净单价 10260。

定价流程的重新设计和迁移

CPQ 定价逻辑很少在不更改的情况下迁移。这两个系统以不同的方式定义定价。规则到规则的直接转换通常会产生不正确的结果，因为 CPQ 规则取决于执行订单，而执行订单在收入管理的定价程序中没有直接的等效物。

因此，从 CPQ 的顺序规则引擎迁移到收入管理的定价程序模型是简化贵公司定价流程的机会。关键问题不是如何复制现有的 CPQ 规则，而是企业实际需要什么样的定价结果，以及最清晰的表达方式。

• 在任何迁移工作开始前，审核所有有效价格规则和 QCP 逻辑。使用 AI 支持的工具，例如 Forsys 或 IdeaHelix，生成所有 CPQ 价格规则和 QCP 逻辑的解释性报表。在尝试任何重新设计之前，请了解每个规则的意图和业务目的，无论是标价、折扣、利润保护还是渠道调整。
• 将每个 CPQ 规则分类为收入管理等效项。直接价格调整成为定价元素，复杂的跨行逻辑成为程序中的自定义流或 Apex。
• 将长期积累的没有明确所有权的定价规则合理化。迁移是淘汰不再具有商业相关性的逻辑的适当时机。
• 将直接、合作伙伴和自助渠道的特定于渠道的定价要求映射到收入管理中的程序计划。此映射支持具有上下文适当定价的单个产品目录，而不是每个渠道的单独定价结构。
• 如果您的企业正在转向混合货币化，请在收入管理中配置基于消耗和使用情况的定价。评级程序通过使用在基本、等级或属性等级卡中定义的特定规则和等级来确定最终的净消费率。
• 根据策划的报价包验证重新设计的定价，这是一组有代表性的历史报价，其输出价格是已知的。如果收入管理程序产生相同的结果，则重新设计正确。
• 对于多币种组织，一次迁移并验证一个币种，以避免价格手册条目值之间的舍入偏差。

在承诺迁移策略之前，请花时间进行定价逻辑审计。定价自定义的数量和复杂性是整体迁移工作的最强预测因素之一。

所有渠道的单一定价引擎

收入管理的 API 优先架构解决了定价逻辑跨渠道扩散带来的集成挑战。许多公司最终为直销、合作伙伴入口网站和自助渠道维护了单独的定价规则，造成了同一真理的三个版本，它们随着时间的推移而有所不同，并导致客户的不一致。

收入管理中的每个收入操作都公开为 API。因此，支持 Salesforce UI 的相同产品、定价和配置逻辑可以由合作伙伴入口网站、自助电子商务体验或产品内购买流使用，而不会重复规则。您可以拥有适用于每个渠道的单个目录和单个定价引擎。

您可以集成第三方可视化工具，例如 ThreeKit 和 RenderDraw，以实现可视化产品配置。