返利管理的注意事项和限制
在开始使用返利管理之前,请查看这些注意事项和限制。
所需的 Edition
| 适用于:启用了返利管理的 Enterprise、Unlimited 和 Developer Edition。 |
返利管理的注意事项
- 只有桌面和移动设备支持返利管理。
- 在使用数据处理引擎操作元素计划流时,按顺序运行数据处理引擎作业。如果您复制预定义的运行返利 DPE 作业流,它会自动实施。
- 预定义的数据处理引擎作业旨在为所有有效返利计划成员的所有有效计划、支付期和返利类型运行。要为特定计划、期间、返利类型或成员运行数据处理引擎作业,请将特定记录作为“运行返利 DPE 作业”流的输入进行传输。
- 建议不要将超过 10,000 个返利类型与超过 100 个唯一返利类型筛选器与一个数据处理引擎定义相关联。检查数据处理引擎限制。将返利类型与多个定义相关联,或修改输入,以便在一次运行中仅处理计划返利类型或支出期间的子集。
- 您可以为返利类型配置最多 100,000 个福利。在使用 Data Loader 上传大量数据时,建议使用串行并发模式,以确保结果一致。批量 API 作业的串行并发模式确保批次按照接收的顺序一个接一个地处理,而不是并行处理。内部验证已执行,每种返利类型最多 10 个福利。使用明显更多的金额可能会影响处理效率,并使得在分析期间更难跟踪支付金额计算逻辑。
- 您不能为 Experience Cloud 用户创建交易日记帐记录的报表。
- 如果给定返利类型存在多种好处,请在使用 Data Loader 上传基础数据之前按返利类型对其进行排序。
- 在多币种设置中,为集成用户和数据处理引擎写回用户简档设置相同的默认币种。如果您没有使用数据处理引擎写回用户,请为分配给数据漏斗基本用户权限集的系统管理员简档使用相同的默认币种。返利管理对象以这种方式使用多币种结构。
- 交易日记帐:交易可以用所需的交易币种记录。
- 返利会员产品聚合:在数据处理引擎作业运行以计算聚合时,交易日记帐中的币种会转换为集成用户简档的币种。然后,金额以写回用户简档的币种存储在聚合对象中。
- 计划返利类型支付金额来源:在福利计算后,在聚合行的货币代码中创建支出来源。
- 计划返利类型福利:在福利设置中,提供的最大值和最小值被视为聚合行的币种,并相应地进行评估。
- 在同时启用返利管理和渠道合作伙伴库存管理的组织中创建交易日记帐时:
- 为渠道合作伙伴库存管理指定日记帐类型。日记帐类型决定了如何在渠道合作伙伴库存管理流程中使用交易日记帐。如果在创建期间将日记帐类型留空,系统会将使用类型默认设置为返利。
- 在返利交易日记帐的状态上配置 DPE 筛选。返利 DPE 不会根据交易日记帐状态字段自动排除记录。如果客户打算使用状态字段(例如,已批准、已拒绝或待处理)来控制哪些记录生成聚合或支出,他们必须在返利 DPE 定义中明确配置筛选器。例如,为确保仅处理符合条件的记录,并排除“已批准”之外的任何状态(例如“待处理”或“已拒绝”),请包含筛选器逻辑,例如:TransactionJournal.Status = '已批准'。
- 查看原有记录以了解兼容性。如果现有返利交易日记帐记录默认为“待处理”状态,请注意,DPE 默认不按状态筛选,而是会处理所有 PoS 交易。请确保配置适当的 DPE 筛选器逻辑,以便处理正确的记录,并且不包括或排除不必要的记录。
返利管理护栏
通过计算返利金额并为返利计划成员生成支出的流程,设置和维护返利计划。这些流程通常处理跨计划、期间和成员的大量返利交易。
- 通过计算返利金额并为返利计划成员生成支出的流程,设置和维护返利计划。这些流程通常处理跨计划、期间和成员的大量返利交易。
- 返利管理通过使用数据处理引擎 (DPE) 和批次管理进行批处理来支持高数据量。对于根据定义的返利类型和相关福利向计划成员发放返利的情况,推荐的数据量防护装置已经过测试和设计。这些防护栏支持有效的规划,并帮助确保实施期间的可靠性能。它们不是严格的技术限制,实际结果可能因数据大小、复杂性和配置而异。要查看返利管理许可和包装详细信息,请参阅此处。
备注 用于处理特定交易日记帐量的防护系统在行业之间保持一致。在不同行业应用这些防护时,使用在该上下文中生成交易日记帐和分类帐的对象替换订单对象及其相关注意事项和假设。护栏可能因客户需求的复杂性而异。
使用 DPE 进行端到端编排的护栏
以下场景概述了内部测试的编排流,其中交易日记帐通过数据处理引擎处理。
- 场景 1
组织数据汇总:各种数据对象的活动计数
对象 计数 详细信息 返利计划 5,000 返利计划会员 15,000 每个计划 3 个成员(带有父级的两级层次结构) 返利期间 60,000 每个计划 12 个月 返利类型 30,000 每个计划 6 个返利类型 计划返利类型收益 180,000 每种返利类型 6 个福利 返利筛选器 90,000 每个返利类型 3 个资格条件 交易日记帐 2500 万 每个成员每个期间 140 个日记帐
备注 这些限制已在内部测试。有关更高的用量,请联系您的 Salesforce 管理员。
执行摘要
- 使用的 DPE:按成员聚合
- 处理的返利类型:30,000
- 已处理筛选器:90,000
- 模式大小:799.1 KB
- 唯一筛选器:200
处理汇总:下表显示了此模式中处理的行数。
| 联接类型 | 总行数(30K 返利类型) | 节点描述 |
|---|---|---|
| 返利计划和返利类型 | 30,000 | 提供有效返利计划的有效计划返利类型。 |
| 返利计划、返利类型和返利支付期 | 180,000 | 为选定的有效返利类型提供有效的支付期。 |
| 返利计划成员、返利支付期、返利计划和返利类型 | 360,000 | 为选定的有效返利类型和支付期提供有效的计划成员。 |
| 交易日记帐、返利计划成员、返利支付期、返利计划和返利类型 | 1,166,400,000 | 将返利类型和付款期信息添加到交易日记帐数据。 |
| 筛选数据有效交易日记帐 | 97,200,000 | 根据活动日期,这些 TJ 数量对进一步处理有效。资格标准评估发生在该集上。 |
| 最终数据有效日记帐 | 97,200,000 | 资格标准的评估后 - 这些是最终汇总的行数。 |
计算:10,000 个返利类型 × 90 个交易日记帐/成员 × 3 个成员/计划 × 12 个期间/计划
备注 这些限制已在内部测试。如果您的数据超过这些数量或维度,请复制并拆分 DPE 作业。例如,将 10,000 个返利类型拆分为两个作业,每个作业 5,000 个。如需帮助,请联系您的 Salesforce 管理员。
用于返利支付金额计算的护栏
组织汇总
- 聚合记录:18,000,000
- 付款期间:180,000
执行摘要
| 进程 | 场景 1 |
| 批次大小 | 2.000 |
| 处理者 | 聚合记录 |
| 有效返利计划 | 1 |
| 聚合记录计数 | 1,800,000 |
| 有效返利计划成员 | 15,000 |
| 有效支付期 | 12 |
| 返利会员支付金额中的记录总数 | 180,000 |
备注
以上数字反映了内部测试。实际性能可能因客户的环境、配置和自定义而异。有关更高的用量,请联系您的 Salesforce 管理员。
返利支出的默认批次大小是 2,000 条记录。您可以根据数据量和自定义逻辑在 200 和 2000 之间调整。如果达到 Apex 限制,请减小大小,并仅在评估系统需求后调整。有关选择批次大小的帮助,请联系您的 Salesforce 代表。
选择返利处理方法时需要考虑的事项
在决定如何处理返利时,请评估以下内容:
最佳实践
使用以下实践来避免性能瓶颈:
- 归档或清除您不再需要的交易日记帐、返利支付金额、返利聚合和返利支付金额来源记录。
- 使用返利计划或计划返利类型筛选器处理批次。
- 在 Data Loader 中使用串行模式进行高用量福利上传。
- 处理返利付款的默认批处理大小是 2,000 条记录。根据您的自定义和数据量,您可以在 200 到 2000 条记录之间调整此值。如果由于自定义而遇到 Apex 调控器限制,请考虑减小批处理大小。仅在评估数据和处理要求后调整值。
本文章是否解决您的问题?
请与我们共享您的想法,以便我们进行改进!

