一、开始使用 Salesforce CPQ 价格规则（Get Started with Salesforce CPQ Price Rules）
为你的特定业务定价（Pricing for Your Specific Business）
很多企业需要比「每件固定价格」更复杂的定价，例如与特定客户谈好合同后按优惠价买打印机。Salesforce CPQ 有很多开箱即用的定价调整工具，但它们有局限，无法满足所有定价需求。这时就需要 Price Rules（价格规则）。
价格规则非常强大，允许管理员有条件地更新报价行、报价行组或报价记录上几乎任何字段的值。它遵循 if/then 格式：IF 条件为真，THEN 做某事。IF 部分可以评估报价或相关记录上的大量数据，关键是足够精确，让价格只在想要时改变；THEN 部分告诉 CPQ 改哪个字段、怎么改。
价格规则的基本结构（Basic Price Rule Structure）
一条价格规则通常涉及三条相关记录：
- Price Rule（价格规则）：容器，包含规则如何运作的基本信息。
- Price Condition（价格条件）：if/then 的 IF 部分，查看报价及其相关记录来决定是否运行，像只能通过或不通过的测试。
- Price Action（价格动作）：if/then 的 THEN 部分，告诉 CPQ 改哪个字段、怎么改。
注册一个带 Salesforce CPQ 的 Developer Edition 组织（Sign Up for a Developer Edition Org with Salesforce CPQ）
要完成本模块，需要一个包含 Salesforce CPQ 和示例数据的特殊 Developer Edition 组织。注册免费的 Developer Edition、填写表单、验证邮箱、设置密码，然后连接到 Trailhead（在 Challenge 区点击 playground 名称 → Connect Org → 输入用户名密码 → Allow → Yes! Save it）。
二、用简单的价格规则替换列表价格（Replace List Price Using a Simple Price Rule）
列表价格调整的场景（The Case for List Price Adjustment）
AW Computing 目前以 $500 卖上网本（netbook），但想给学校 $400 的优惠价。这是数百个产品中唯一需要独特价格的。选项一：建一个新的价目表，包含一条独特条目和数百条重复条目，还要维护、培训代表选择正确的价目表。听起来工作量大、易出错。选项二：创建一个价格规则，在销售代表为教育客户报价时自动改上网本价格。这同时帮了管理员和销售代表，所以选它。
构建容器（Construct the Container）
每条价格规则都从价格规则记录开始。创建步骤：App Launcher → Salesforce CPQ → Price Rules → New，Price Rule Name 填 Educational Netbook List Price，Evaluation Scope 选 Calculator，勾选 Active，Save。
条件的化学（The Chemistry of Conditions）
价格规则只在某些时候生效。价格条件就像石蕊试纸：比较两段信息，判断真或假。创建两个价格条件：
- Object Quote、Field AccountIndustry__c、Operator equals、Filter Type Value、Filter Value
Education。 - Object Quote Line、Field Product Code、Operator equals、Filter Value
NETBOOK。
默认情况下，价格规则要求所有条件都满足才运行（AND 逻辑）。
预期结果（The Expected Result）
价格规则的目的就是改变报价/报价行/报价行组上的某个字段。创建价格动作：Target Object Quote Line、Target Field SBQQ__ListPrice__c、Value 400。
规则总结：IF 行业 = Education 且 产品代码 = NETBOOK，THEN 把列表价格设为 400。测试：给教育客户 Kevco 的 Q-00048 报价添加上网本，应看到列表单价变成 $400。还要做负面测试（其他产品、非教育客户不该改价）。记住：如果报价行编辑器在另一个标签页打开，改了规则后必须刷新页面。
三、制定你的条件和动作（Formulate Your Conditions and Actions）
向上查找你的亲属（Looking Up to Your Relatives）
Object/Field 组合只能识别报价、报价行或产品选项对象上的字段，所以 Team Trailhead 才要在报价上建 AccountIndustry__c 公式字段。另一个方法是测试公式（Tested Formula）直接引用相关对象的数据，例如 SBQQ__Opportunity2__r.Type（跨对象公式用查找字段引用相关对象数据）。
引用相关数据很好，但有个大限制：只能引用与报价、报价行或报价行组直接相关的对象上的数据。即 SBQQ__Opportunity2__r.Type 可以（报价上有到商机的查找），但 SBQQ__Opportunity2__r.CampaignId.Type 不行（没有到 Campaign 的查找）。
带计算器的价格动作（A Price Action with a Pocket Calculator）
AW Computing 想给新客户的 SD 卡减 $25，用 Formula 字段做数学运算：Target Field SBQQ__ListPrice__c，Formula 填 SBQQ__OriginalPrice__c - 25（Original Price 代表价目表价）。测试：Q-00049 加 ROUTER 和 SDCARD256GB，SD 卡的 Original Price $85，List Unit Price 应变成 $60，路由器不受影响。
谨慎编写公式（Write Formulas with Care）
价格规则里没有 Check Syntax 按钮，甚至允许保存语法错误的公式，导致报价行编辑器报错、无法添加报价行。
有个技巧：借用核心 Salesforce 的 Check Syntax 按钮——假装新建一个公式字段（Setup → Object Manager → 对应对象 → Fields & Relationships → New → Formula），把公式写进去检查语法，通过后复制公式，再粘贴到价格动作的 Formula 字段。
注意对象要选对（与条件/动作的 Object/Target Object 一致）。这个技巧多数时候有效，但有些核心 Salesforce 函数和全局变量 CPQ 不支持（如 ADDMONTH()），所以务必彻底测试。
四、学习何时使用特殊价格字段（Learn When to Use the Special Price Field）
两个可目标的价格（Two Prices to Target）
CPQ 用一系列中间字段追踪最终价格：Original、List、Special、Regular、Customer、Partner、Net Price。我们建议只目标 List Price 和 Special Price 两个字段。把 Original Price 留作参考点（用于触发审批/验证或正确计算利润率）。至于 Regular、Customer、Partner、Net Price 都是按比例摊派（prorated）的价格，容易出现舍入误差，应避免。
避免递归计算（Avoid Recursive Calculations）
千万不要在一条规则的来源和目标里用同一个价格字段，否则会导致递归计算。例如规则目标是 List Price，来源公式又含 List Price（SBQQ__ListPrice__c * 0.9）：$100 → 点一次计算变 $90 → 再点变 $81 → 再点变 $72.90。价格取决于点了多少次计算，这绝不该发生。要么目标 List Price，要么把它当来源，不能两者兼用。
最特殊的价格（The Most Special of Prices）
当产品在捆绑包中销售时，List Price 可能代表捆绑选项价。若需要调整捆绑价，就用 Special Price——它是价格瀑布中下一个价格，基于 List Price 计算，且不按比例摊派。例：AW Computing 给小型企业所有 SSD 硬盘打 8 折（SBQQ__ListPrice__c * 0.8），目标 SBQQ__SpecialPrice__c。
但有个独特怪癖：用价格规则更新 Special Price 时，必须同时把 Special Price Type 设为 Custom，否则规则不生效。所以这条规则需要两个价格动作。价格规则还能更新非价格字段（如 Quantity、Partner Discount、Non-discountable、Discount Schedule），但绝不要目标公式字段。
五、用汇总变量汇总数据（Summarize Data with Summary Variables）
摘一篮腌辣椒（Pick a Peck of Pickled Peppers）
就像你可以用计数、求和、平均、最小值、最大值来汇总一篮蔬菜的重量，汇总变量（Summary Variables）也用来汇总 CPQ 相关记录——报价行、产品选项、订阅和资产（asset）。例如「客户现在有多少活跃订阅」，可以做一个汇总变量来表示这个值，然后在价格规则的条件或动作里引用它。
种下汇总变量的种子（Plant a Summary Variable Seed）
AW Computing 想促进客户留存：如果客户过去买了超过 10 台笔记本，就把笔记本降价 $100。资产记录里知道客户以前买了什么。创建一个汇总变量来表示笔记本资产数量的总和：Summary Variables → New，Variable Name Laptop Asset Sum、Target Object Asset、Aggregate Function Sum、Aggregate Field Quantity、Filter Field ProductCode、Operator starts with、Filter Value LAPTOP1。
加一点汇总变量的条件（A Condition with a Dash of Summary Variable）
创建价格规则 Repeated Laptop List Price（Calculator、Active）。第一个价格条件用汇总变量：Object Summary Variable、Tested Variable Laptop Asset Sum、Operator greater or equals、Filter Value 10。第二个条件：Object Quote Line、Field Product Code、starts with LAPTOP1。价格动作：Target SBQQ__ListPrice__c，Formula SBQQ__OriginalPrice__c - 100。测试 GenePoint 账户（有 10 台笔记本资产）加 LAPTOP13，列表价应减 $100。
复合汇总变量（Composite Summary Variables）
Composite Information（复合信息）区可以对 CPQ 汇总出的值做最后一次计算。例如把克转盎司（1 盎司 ≈ 28.3495 克），Composite Operator 选 Divide，Value Element 填 28.3495。复合运算符支持加减乘除，还可以用 Variable Element 查找字段引用另一个汇总变量。
用约束字段限制记录（Limiting Records with the Constraint Field）
有时需要加第二个筛选器，可用汇总变量的 Constraint Field 字段。步骤：在资产上建一个字段、在报价上建一个同 API 名的字段，通过公式/自动化/手动让两字段值相同，再把汇总变量的 Constraint Field 设为这两个字段的 API 名。这是一次性的「设完就忘」过程。（注：有个已知问题会让填充 Constraint Field 的汇总变量失效，详见帮助文章。）
六、用查找查询合并价格规则（Consolidate Price Rules by Using Lookup Queries）
规则激增的问题（The Problem of Rule Proliferation）
相似的规则会成倍增长：2 个产品 × 2 个行业 × 4 种 SLA = 需要 16 条规则。与其建 4、8、16 条几乎一样的规则，不如建一条规则处理所有变体：把变体目录放在自定义对象里，再查询该对象找出当前报价对应的那个特定变体的价格。Team Trailhead 已把行业/产品/SLA/价格数据预填进 IndustryPrice__c 自定义对象（字段以 IP 前缀开头）。
挖掘自定义数据（Tap Into Custom Data）
创建价格规则 Lookup Netbook Price（Calculator、Active），Lookup Object 选 IndustryPrice__c。然后用 Lookup Queries 把数据过滤到单行：
- Match Type Field Value、Tested Object Quote、Tested Field
AccountIndustry__c、Lookup FieldIPIndustry__c。 - Tested Object Quote Line、Tested Field
SBQQ__Product__c、Lookup FieldIPProduct__c。 - Tested Object Quote、Tested Field
AccountSLA__c、Lookup FieldIPSLA__c。
价格动作：Target SBQQ__ListPrice__c，Source Lookup Field 选 IPPrice__c。关键要求：查找查询组合绝不能返回多行，否则报价行编辑器报错、计算失败；返回零行则 OK（CPQ 不更新价格）。测试 Milwaukee Distributed Health（Healthcare + Gold SLA）加 NetbookPro，价格应为 $535。
七、为正确计算排序价格规则（Sequence Price Rules for Correct Calculations）
知道何时会有计算（Know When to Expect Calculations）
CPQ 在以下情况运行定价计算：添加或移除报价行；在报价行编辑器点 Calculate/Quick Save/Save；在报价记录点 Calculate；保存对报价行的任何更改；保存对计算字段（Calculating Field）的更改。计算字段是 CPQ 认为可能影响价格、应触发重算的字段（如订阅期限）。你可以把自定义字段加入 Calculating Fields 字段集（Setup → Object Manager → Quote → Field Sets → Calculating Fields），这样该字段变化时 CPQ 就知道要重算。
价格规则与报价计算顺序（Price Rules and the Quote Calculation Sequence）
CPQ 计算报价时按特定顺序执行步骤，并在四个评估事件（Evaluation Event）运行价格规则：
- On Initialization（初始化时）
- Before Calculate（计算前）
- On Calculate（计算时，报价行数量计算之后）
- After Calculate（计算后）
大多数规则用 On Calculate，每次计算只运行一次。但有时要调整规则在序列中的位置才能得到预期结果。例如午餐捆绑包每份三明治配两个饼干，若规则要给特殊客户每份三明治配三个饼干，就必须把 Evaluation Event 设为 Before Calculate，否则数量计算已完成、改晚了。Evaluation Event 是多选，但建议每条规则只用一个事件以最大化性能。
并发条件（Concurrent Conditions）
在给定事件中，CPQ 会先评估所有条件、再执行任何动作。这导致一个问题：当一条规则的动作目标字段被另一条规则的条件使用时，第二条规则不会运行。例如：规则 1「IF 交付日期在 2 周内 THEN 勾选 Expedited」，规则 2「IF Expedited 勾选 THEN 运费加 $20」。若两者在同一事件，规则 2 不会运行（因为评估条件时 Expedited 还没被勾选）。
解决办法：把规则 1 移到更早的事件，或把规则 2 移到更晚的事件。绝不能依赖多次点击 Calculate 来得到正确价格——你无法保证销售代表会点足够多次。
围绕动作排序（Order Around Your Actions）
有时两个价格动作要协同产生级联结果（例如先设 List Price，再基于它算 Max Discount）。可以用价格动作记录上的 Order 字段强制动作按数字顺序计算。
排序有三个优先级：
- 价格规则的 Evaluation Event
- 价格规则的 Evaluation Order
- 价格动作的 Order
规则级 Evaluation Order 优先于动作级 Order。善用这些控制，确保价格在 CPQ 第一次运行计算序列时就正确。