目录
4.2 同级别订单，按比例分配（对应 - 7.2 使用‘可用性检查’+‘供应分配’的 BOP 执行结果）
4.4 同时响应不同客户们的需求（对应 - 7.1 使用‘可用性检查’的 BOP 执行结果）
5.3 使用‘可用性检查’+‘供应分配’的 BOP 后台配置
5.4 使用‘可用性检查’+‘供应分配’的 BOP 权限配置
6.2 使用‘可用性检查’+‘供应分配’的 BOP 主数据配置
7.2 使用‘可用性检查’+‘供应分配’的 BOP 执行结果
1 用途
1.1 aATP
1. 写‘aATP – BOP（延期交货订单处理）’之前，先搞清楚什么是‘aATP’。
2. ‘aATP’即‘高级可承诺量’。
3. 附上SAP Help Portal上的说明。
总结下来有几点：
1. ‘aATP’是 SAP S/4 HANA中的一项业务功能，可响应销售和生产计划中的订单履行查询。
2. 订单履行查询包括所需的 1）产品 2）工厂 3）需求数量 4）可用产品日期。
3. 对于需求的响应，‘aATP’是基于 1） 当前库存情况 2）未来预期或计划的库存收货 3）考虑并发订单，此外也可以增加限制条件如区域和客户。
4. 对于需求产品的数量、日期和对应的工厂，‘aATP’生成确认的建议。
1.2 aATP – BOP（延期交货订单处理）
1. aATP – BOP（延期交货订单处理）以下简称：BOP
2. 同理，先附上SAP Help Portal上的说明。
总结下来有几点：
1. 订单履行过程中，发生需求变化或供应变化时，利用 SAP S/4 HANA 的 BOP 功能来检查产品可用性。
2. 利用 SAP S/4 HANA的 BOP 功能，可以检查之前确认过的订单或之前发生过的业务需求是否依然符合现实业务情况。举例：1）取消销售订单，从而释放库存数量 2）重要客户临时增加了订单，取消其他客户已经确认过的订单，满足重要客户临时增加的需求 3）生产订单提供的计划供应周期的延期。
3. 不对更改的可用性情况做出反应，会导致确认过的订单数量大于可用数量，从而可用性检查失败，最后无法创建外向交货单。
2 需要用到的 BOP FIORI 应用和它们的主要功能
注意：以下功能只能在FIORI上实现，SAP GUI 没有相关的T-code可以实现。
| 序号 | FIORI 应用 | 主要功能 |
| 1 | 配置 BOP 细分 | 1. 增删改查‘细分对象’ 2. 选择条件，如‘售达方’ 3. 优先排序，如‘记录创建日期’、‘交货优先级’、‘交货日期’ 4. 模拟需求 5. 显示（查）‘细分对象’相关的延期交货订单处理变式 |
| 2 | 配置 BOP 变式 | 1. 增删改查‘变式’ 2. 选择‘回退变式’来处理异常行为 3. 选择业务场景，如‘销售订单’和‘交货单’ 4. 选择执行方法，如‘可用性检查’或‘供应分配’或‘可用性检查 + 供应分配’ 5. 选择‘BOP 确认策略’ 6. 选择‘全局细分’ 7. 模拟 BOP 运行或只运行 BOP 一次 |
| 3 | BOP job（作业） | 1. 定期跑 BOP job（作业），实现自动化 |
| 4 | 监控 BOP | 1. 监控 BOP 执行结果 |
3 BOP 确认策略
1. S/4 HANA 2022 最新版本 BOP 确认策略如下
| 确认策略 | 评估顺序 | 检查顺序 | 系统行为 |
| 赢得 | 2 | 1 | 1. 按时完全确认订单 2. 没有按时完全确认订单，系统会报错 |
| 收益 | 3 | 2 | 1. 保持已经确认过的订单 2. 不能保持已经确认过的订单，系统会报错 |
| 提高 | 4 | 3 | 1. 保持已经确认过的订单 2. 不能保持已经确认过的订单，系统不会报错，并且减少确认订单的数量 |
| 重新分配 | 5 | 4 | 1. 确认过的订单数量重新分配给更高级别的策略 2. 订单确认数量不能满足订单数量，系统不会报错 |
| 填充 | 6 | 5 | 1. 确认过的订单数量重新分配给更高级别的策略 2. 订单确认数量不能满足订单数量，系统不会报错 |
| 损失 | 1 | 6 | 1. 所有确认过的订单数量都释放掉 2. 订单确认数量不能满足订单数量，系统不会报错 |
| 略 | 不适用 | 不适用 | 不会参与’可用性检查’ |
2. 根据实际测试结果画了个ppt，但由于受限于笔者使用的系统版本，缺少 BOP 确认策略‘提高’和‘略’😒
4 使用 BOP 的主要业务场景
4.1 先到先得
根据销售订单排序定期跑 BOP job（作业）， 实现‘先到先得’。但是不使用 BOP 也可以实现‘先到先得’😄，利用 BOP 实现‘先到先得’有点大材小用了。
4.2 同级别订单，按比例分配（对应 - 7.2 使用‘可用性检查’+‘供应分配’的 BOP 执行结果）
按照比例分配给同级别下单的客户，供货给多个客户方，避免如何分配供应的烦恼 😄
4.3 一个订单项，多个计划行
1. 使用 BOP 之前：
一个订单项，多个计划行都会根据交货日期排序确认订单。举个例子2月份的计划行订单，必须是1月份的计划行订单确认完之后才可以确认。
2. 使用 BOP 之后：
根据‘交货日期’或‘产品可用性日期’等等筛选条件，一个订单项里分成几种类别的计划行确认订单。
4.4 同时响应不同客户们的需求（对应 - 7.1 使用‘可用性检查’的 BOP 执行结果）
1. 使用 BOP 之前：
基于不同客户们的促销活动、特殊客户协议、开票冻结等等，需要同时处理大量的不同业务情况。
2. 使用 BOP 之后：
结合 BOP 确认策略，有序的确认不同客户们的订单。
5 BOP 系统配置
5.1 使用‘可用性检查’的 BOP 后台配置
1. 设定可用性检查组使用aATP功能：跨应用组件 > 高级可承诺量（aATP）> 产品可用性检查（PAC）> 定义可用性检查
2. 可用性检查和物料主数据对应关系
3. 设定工厂级别延期交货订单处理：跨应用组件 > 高级可承诺量（aATP）> 延期交货订单处理（BOP）> 配置用于更新延期交货订单的业务场景
5.2 使用‘可用性检查’的 BOP 权限配置
1. FIORI Launchpad Designer上找到‘延期交货订单处理’应用对应的‘组’和‘目录’。
2. 把‘组’和‘目录’的标识信息都加在新创建的角色‘YJ_PAL’。
5.3 使用‘可用性检查’+‘供应分配’的 BOP 后台配置
1. 激活业务功能‘SUPPLY_ASSIGNMENT_01’。
2. 使用供应分配优先级功能：跨应用组件 > 高级可承诺量（aATP）> 供应分配（分配运行）> 供应分配中的常规设置 > 启用基于确认的细分和优先级划分
5.4 使用‘可用性检查’+‘供应分配’的 BOP 权限配置
1. FIORI Launchpad Designer上找到‘供应分配’应用对应的‘组’和‘目录’。
2. 把‘组’和‘目录’的标识信息都加在新创建的角色‘YJ_PAL’。
6 BOP FIORI 主数据配置
6.1 使用‘可用性检查’的 BOP 主数据配置
1. 创建5个‘BOP 细分’，凭证类型 = ‘销售订单’，选择条件 = ‘售达方’，排序条件 = ‘记录创建日期’升序。
2. 创建 BOP 变式。基于5个 BOP 确认策略，分配 BOP 细分，执行方法：可承诺量。
6.2 使用‘可用性检查’+‘供应分配’的 BOP 主数据配置
1. 创建‘供给排序规则’。
2. 创建‘供给分配原则’。分配策略：成比例的。
3. 创建‘BOP 细分’，凭证类型 = ‘销售订单’，选择条件 = ‘交货优先级’和‘物料号’，排序条件 = ‘记录创建时间’升序
4. 创建 BOP 变式。分配 BOP 细分，执行方法：可承诺量和供应分配。
7 系统准备工作完毕，查看系统执行结果
7.1 使用‘可用性检查’的 BOP 执行结果
1. 使用 BOP 之前，客户确认订单信息：
| 销售订单 | 客户 | 产品 | 订单数量 | 确认订单数量 | 确认订单日期 | BOP 确认策略 | 可用性检查数量 |
| 4166 | 5000000006 | SSD_BOP | 50 | 0 | - | 赢得 | 50 |
| 4167 | 5000000003 | SSD_BOP | 50 | 0 | - | 收益 | |
| 4168 | 5000000007 | SSD_BOP | 25 | 25 | 2023/7/3 | 重新分配 | |
| 4169 | 5000000008 | SSD_BOP | 15 | 15 | 2023/7/3 | 填充 | |
| 4170 | 5000000009 | SSD_BOP | 10 | 10 | 2023/7/3 | 损失 |
2. 使用 BOP 之后，客户确认订单信息：
1）‘赢得’确认订单数量 = ‘重新分配’确认订单数量 +‘填充’确认订单数量 + ‘损失’确认订单数量。‘损失’不会往后确认订单，只管损失订单。
2）‘收益’，‘重新分配’和‘填充’确认订单日期根据补货时间往后延，这里举的例子是7天。
3）‘损失’不会往后确认订单，只管损失订单。
| 销售订单 | 客户 | 产品 | 订单数量 | 确认订单数量 | 确认订单日期 | BOP 确认策略 | 可用性检查数量 |
| 4166 | 5000000006 | SSD_BOP | 50 | 50（+50） | 2023/7/3 | 赢得 | 50 |
| 4167 | 5000000003 | SSD_BOP | 50 | 0 | 2023/7/10 | 收益 | |
| 4168 | 5000000007 | SSD_BOP | 25 | 0（-25） | 2023/7/10 | 重新分配 | |
| 4169 | 5000000008 | SSD_BOP | 15 | 0（-15） | 2023/7/10 | 填充 | |
| 4170 | 5000000009 | SSD_BOP | 10 | 0（-10） | - | 损失 |
4）以上截图是根据不同客户和不同销售订单，确认订单或更改确认订单。‘BOP 细分’里不一定非要用客户区分，你也可以选择用‘客户组’、‘分销渠道’、‘产品组’等多个维护灵活安排 BOP 执行。
7.2 使用‘可用性检查’+‘供应分配’的 BOP 执行结果
1. 使用 BOP 之前，客户确认订单信息：
| 销售订单 | 交货优先级 | 客户 | 产品 | 确认订单数量 | BOP 确认策略 | 可用性检查数量 |
| 4171 | 1 | 5000000010 | SSD_PAL | 35 | 赢得 | 85 |
| 4174 | 2 | 5000000011 | SSD_PAL | 50 | 重新分配 | |
| 4175 | 2 | 5000000012 | SSD_PAL | 50 | 重新分配 |
2. 使用 BOP 之后，客户确认订单和供应分配信息：
按照均匀比例供应分配。
| 销售订单 | 交货优先级 | 客户 | 产品 | 确认订单数量 | 供应分配数量 | 供应分配百分比 | BOP 确认策略 | 可用性检查数量 |
| 4171 | 1 | 5000000010 | SSD_PAL | 35 | 23 | 66% | 赢得 | 85 |
| 4174 | 2 | 5000000011 | SSD_PAL | 50 | 31 | 62% | 重新分配 | |
| 4175 | 2 | 5000000012 | SSD_PAL | 50 | 31 | 62% | 重新分配 |
7.3 执行 BOP job（作业）
使用 BOP job（作业），实现自动化。创建 job（作业）的具体方法就不提了，感兴趣的小伙伴可以自己研究研究（简单😄）。但是值得一提的是，既然有 job（作业），就得考虑归档的问题。使用系统标准的数据销毁对象‘ATP_CHECK_LOG_DESTRUCTION’归档。
1. T-code: ILM_DESTRUCTION，直接跑数据销毁对象‘ATP_CHECK_LOG_DESTRUCTION’。
2. T-code: DOBJ，找到数据销毁对象对应的程序，后台创建 job（作业）定期归档。
2568
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
