第47篇-「行业总结篇-9」SAP物料自然切换&断点业务深度分析及完整实施方案

视频详解

无

                                                           

声明：本文仅代表原作者观点，仅用于SAP软件的应用和学习，不代表SAP公司。注：文中所示截图来源于SAP软件或PA官方教材，相应著作版权归SAP所有。本文档内容绝大部分内容由笔者原创编写，也可能有部分摘自在线网络资料，供同行顾问查阅及交流。若有需完善、优化、或引用需表明出处的地方，欢迎大家指出，笔者进行修改。

重点提醒：本公众号阅读是完全免费的，大家理性付费下载文末的PDF文档。若有读者进行了付费支持，笔者会以发红包福利的方式回赠于“咨询顾问进阶-讨论群”等群的群友们、促进大家更加良性的探讨、学习、交流、分享。

点击上方蓝字关注我们吧

今日分享-目录

  

Today's share

01

背景介绍

工程变更业务一直是SAP实施的过程中比较常见的业务。不止是汽配行业，其他行业只要对研发要求较高、较规范的企业都会涉及到工程变更的业务及应用。

常见的工程变更主要包含两种：立即切换（强制切换）和自然切换（消耗库存类切换）。

立即切换（强制切换），顾名思义就是研发对某些零件需要升版，对旧件要进行淘汰，并且旧件即使有再多的库存也不能再进行使用，一旦切换后旧件将形成呆滞库存。这类的业务对应的系统实现，相对而言也是比较简单的，研发在BOM释放的时候基本上不需要与采购、物控等部门多轮沟通设定零件的切换日期，主要是在研发和质量部门的考虑下，应该在哪个日期切换，现场根据切换日期进行执行。

自然切换（消耗库存），该类就是一般业务部门比较头疼的业务了。一般研发会与采购、物控、生产计划开多轮切换会议，评估初始切换日期和最终切换日期。比如某零件要升版，研发会提前如3到6个月召集各相关部门查询旧件目前的库存情况、在途情况以及未来的生产计划需求数量，进行评估出初版计划切换日期，然后进行发布工程变更切换日期，并作用至BOM中进行有效日期切换。当临近切换时间，两周到一个月内会再次查询旧件目前的库存情况、在途情况以及详细的生产计划需求数量，得出更精准的切换日期。由于是自然切换，之前定义好的初始切换日期不一定精准且已经生效在BOM中，并形成了计划订单或者甚至有的企业转单的提前期非常长已经转为了生产订单，那么企业应该如何比较平滑的作消耗库存类切换？项目组应当如何设计较优的可应用的、能辅助业务部门调整的解决方案？

02

上期回顾

上期文章：「行业总结篇-2」工程变更-消耗库存切换解决方案

SAP的标准功能，工程变更号日期切换+BOM展开号的应用

（1）场景一、二、三的验证及应用；

（2）标准功能的优缺点

（3）自开发-自然切换平台处理功能简介

本期就对自然切换平台功能进行详细的介绍

03

呆滞库存处理平台功能-价值

笔者之前的优化项目根据客户的需求进行了实施。

因为当时优化项目的特点，客户一期和业务现状是只要有计划订单就转成了生产订单，本方案考虑点和优点就是系统能通过BOM工程变更号切换日期、切换日期、物料的供需情况，自动计算出新旧件的替换，业务人员只用对结果进行抽查，确定系统替换的逻辑是否准确。

客户的痛点和需求也非常明确：

1.之前全靠人工记录工程变更的切换类型、查询库存、在途在制情况，人为判断哪些订单当前使用的新的件，因为旧料还有库存需要替换订单组件为旧的件；或者哪些旧的件因为质量问题、过期问题需要立即替换成新的件；

2.标准功能的局限性：SAP后继物料标准功能无法实现物料多轮替换，如a->b->c->d.且无法按照一些特定的规则、排序、排除逻辑进行替换

3.物料查询的工作量大，每个物料都要查询其库存、在途在制情况，再去查询被应用到哪些订单里面，这些订单是下达状态、还是在制状态，已经上线是否允许修改等等问题；

4.既然是人为查询零件使用到的订单，那就可能有查询遗漏、或者修改时修改错误的情况等等；

5.业务有一些特殊规则：同一个零部件，可能在不同产品下切换模式不同。也有开始为消耗库存类切换，后续变更为强制切换的情况。

业务及系统流程：

业务流：

一般研发会与采购、物控、生产计划开多轮切换会议，评估初始切换日期和最终切换日期。比如某零件要升版，研发会提前如3到6个月召集各相关部门查询旧件目前的库存情况、在途情况以及未来的生产计划需求数量，进行评估出初版计划切换日期，然后进行发布工程变更切换日期，并作用至BOM中进行有效日期切换。当临近切换时间，两周到一个月内会再次查询旧件目前的库存情况、在途情况以及详细的生产计划需求数量，得出更精准的切换日期。

但实际切换时，一定会跟预计有偏差，就会产生一些呆滞库存。

系统流：

1.PLM系统传输工程变更号、工程变更的切换类型；

2.SAP会对变更的数据进行存储、同时调工程变更函数创建、BOM函数进行创建修改数据；

3.通过呆滞库存处理平台，进行计算，可前台执行、可后台JOB执行；

4.新旧物料跟进关系、切换日期、供给情况拉通ZMRP运算，并记录修改日志便于业务用户对数据疑问时查询；

5.同时开发一下替换物料状态的报表、与OA打通接口、物料库存预警报表、BOM变更未清单价预警报表、物料替换关系报表、单据打印时显示。

方案主体逻辑：

1.基础数据：父项物料、组件物料、切换日期、切换类型等等；

2.物料需求来源：委外需求，生产需求；

3. 数据排序：

a.按照组件需求日期排序；

b.同一日期下面先满足生产预留，后满足委外采购预留；

c.同一日期下按订单号排序;

d.按照接口自建表表物料替换顺序进行排序（例：a->b->c）

4. 排除逻辑

排除锁定的订单的数据

a.已下达生产订单

b.已审批委外采购订单

c.排除组件父项不在ZCUTBOM里面的数据

5. 可配置性

a.MRP函数抓取数据

b.根据MRP元素，配置可用量增减

c.根据订单类型，配置可用量增减

6. 数据修改

a.计划订单组件增删改函数

b.生产订单组件增删改函数

c.委外订单组件增删改函数

方案价值：

1.启用本方案前，业务人员手工计算上百种物料替换、上千单的订单组件替换；

2.根据物料的历史替换关系，系统自动计算所有的需求供给，避免人工少算、错算；

3.可便捷查询，物料历史替换关系、物料需求供给情况、呆滞库存平台处理历史记录等；

4.端到端的解决方案，打通研发端、采购端、生产端的消耗库存变更业务流程，系统自动化流程；

5.消耗库存变更切换日期不精确，造成企业大量呆滞库存；

通过该平台功能可提前预警物控人员，让已存在的呆滞库存物尽其用，提高库存利用率。

04

方案的实现周期及其他需求说明

1.周期及计划表：

2.业务的一些需求梳理、输入（后续跟进实现，可能有调整，未更新）

05

系统功能实现注意点

（1）通过接口（ ZFM_PLM002 ）记录BOM变更关系并记录于自建表（zcutobom）。

（2）呆滞库存处理平台

选择屏幕

处理逻辑：

(1)抓取zcutobom中切换类型为1 的自然切换数据。

(2)从RESB表抓取自然切换类型物料的预留信息（需求类型为委外订单需求BB 和 生产订单需求AR ）。

(3)数据排序：

a.按照组件需求日期排序；

b.同一日期下面先满足生产预留，后满足委外采购预留；

c. 同一日期下按订单号排序;

d.按照zcutobom表物料替换顺序进行排序（例：a->b->c）。

补充说明：a->b->c 关系时通过zcutobom分组号进行日期和时间升序排序得到的结果；分组号为一组物料变更时的关键值；分组号的形成逻辑：在zcutobom存储时，若同一个父项物料存在组件物料A->B变更关系时候，新增b->c的组件变更关系则使用同一个分组号，其他时候则使用新的分组号。

(4)排除不参与计算的订单

a.已下达生产订单

b.已审批委外采购订单

c.排除组件父项不在CUTBOM里面的数据

(5)组件物料替换：

a. 根据函数 ：MD_STOCK_REQUIREMENTS_LIST_API抓取变更切换日期可用数量；

b.可在配置表（zppt028）中设置MRP元素的数量在切换日期对应可用数量的增加或减少；

例：在7月1号时候A物料被替换成B物料；7月5号时候存在A物料的MRP类型为BA（采购申请）的供给；这里就应该配置BA 为变更日期可用量的的增加，在程序计算A物料切换日期可用量时候加上MRP类型BA的供给数量。

c. 可在配置表（zppt029）中设置订单类型的数量在切换日期对应可用数量的增加或减少；

例：在7月1号时候A物料被替换成B物料；7月5号时候存在A父项物料的订单类型为ZP04（返工订单）的需求；计算替换需求时需排除ZP04（返工订单）类型的数据。这里就应该配置ZP04 为变更日期可量的的减少，在程序计算A物料切换日期可用量时候减少订单类型ZP04（返工订单）的数量。

d.以a->b->c为例，得到adc切换日期的期初可用量，以及abc需求日期需求数量拉通计算（以变更分组内ZMRP拉通计算）。

e.注意：切换日期下可用余量大于0才参与运算（表示该物料在切换日期下有呆滞库存）

（5）调用BAPI，修改数据：

修改生产订单组件(由于数据变化情况过于复杂，最后确定：采取先删除，后创建的模式进行修改数据)

删除BAPI:CO_XT_COMPONENTS_DELETE。

创建BAPI: CO_XT_COMPONENT_ADD.

注意：

a.两个BAPI属于特定函数，需要先用CO_XT_ORDER_PREPARE_COMMIT做提交动作；

b.在创建时，对RESB表做数据写入时候注意与原预留的的一致性，不然会导致创建预留之后工单读取组件失败（RESB表存在数据，前台查询空白），或者前台查看组件时候程序DUMP。

c.配合函数 CALL FUNCTION'CO_XT_ORDER_INITIALIZE 一起使用。

(2) 修改外协委外采购订单组件(由于数据变化情况过于复杂，采取先删除，后创建的模式修改数据)

BAPI:BAPI_PO_GETDETAIL1

BAPI_PO_CHANGE.

注意：

a.删除和创建都根据读取的组件信息构建入参，一次提交至BAPI_PO_CHANGE 函数(入参信息构造时候：创建时候 ct_pocomponents-change_id = 'I'.删除时候ct_pocomponents-change_id = 'D'.) 。

06

复杂的测试场景

如笔者所述，该方案相当于针对一些逻辑让系统识别到是切换的物料，将其视为一组物料的分组。让MRP对这些分组的物料在组内进行ZMRP运算。既然是

在MRP的基础上做平台程序进行运算，复杂的测试是必须的。

其中包含在开发时，顾问与开发顾问的一个月左右的测试；

内部顾问对公司业务更加熟悉，与内部顾问组织的生产相关的20来种场景测试、委外采购相关的20来种测试。

每一个测试场景都需要针对“呆滞库存处理平台”与MD04的几个切换物料进行对比分析，平台功能处理的数据是否准确。

至于最后维护选择的方式是自开发平台功能处理该业务，而不是在MRP增强中实现：

（1）笔者认为自开发平台功能，在运算的界面便于顾问与开发、内部顾问对运算的数据进行跟踪、判断数据是否准确，逻辑是否考虑全面、便于断点分析；

（2）待上线运行稳定后，或通过顾问与内部顾问几十种场景测试稳定后，可设每天的定时JOB，针对这类物料的处理不需要实时，修改运算的频率那么高；

（3）如果在平台功能，每次用户可以手工触发、也可以定时跑，写了响应修改日志逻辑，便于未来若发现数据异常进行追踪；

（4）若增强在MRP中，如全工厂运行MRP运行的时候，这些物料都会拉通起来运算，影响MRP运行效率。而且MRP live的增强目前不好实现，会导致运行MRP live时增强失效，且不易监控数据运行后是否准确无误。

以上为笔者实施各行各业项目自然切换工程变更业务后，与业务深入探讨的过程和理解他们的关注点，得到一些浅显的理解，欢迎更多的同行进行沟通、探讨、交流。笔者不推荐自开发，能尽量发挥标准功能到极致是原则，但是对于自然切换工程变更要减少业务的操作工作量，目前来看， SAP的标准功能不太能完全满足业务的需求，需要开发相关的功能进行辅助。以上不代表权威，仅供大家作为思路参考，感谢大家支持。

感谢支持

07‍

文档下载链接

下载链接：