PPDS

作者: SAP江湖 | 来源:发表于2022-03-02 08:26 被阅读0次

    举例来讲,一个基本常用的PPDS的Production Planning步骤如下:

    1. 运行Stage Numbering Heuristic 计算物料的低层码(Low-level code,LLC),LLC是物料计划运行的最基本数据,其保证物料计划按照正确的次序运行。在ECC中LLC是自动并实时更新在数据表中的。

    但在APO PPDS中每个物料的LLC不是实时更新在系统中的。在上一次运算之后可能存在PDS/PPM的新增,修改或者删除,通过一次运算将刷新系统物料的LLC,从而做为下一步计划运行的次序索引。

    1. 运行多层次物料计划,无限产能。基于第一步中得到的低层码,运行物料计划。这个步骤与传统ECC MRP遵循一样的逻辑,不赘述。所用的Heuristic 为 SAP_MRP_001 。换一个角度思考,也就是说ECC的MRP运行其实只是PPDS 众多Heuristic中的其中一个程序而已。
    2. 从下至上的反向重计划(Bottom-up Reschedule)

    MRP是从上而下的计划且是无限产能,因为某些原料供应提前期造成实质上有些物料无法按照满足交期,那么成品的需求实际上是无法满足的。这时使用bottom-up reschedule Heuristic,可以将各个层次的各组件延迟情况逐层回溯滚算到成品层次。从而在物料供应角度保持一个可执行的计划。这一步的潜在结果是部分客户订单需要延迟交货。

    1. 针对瓶颈资源进行重新排程(Reschedule)

    前三项计划的对象均是Product,而此步计划的对象则是资源(Resource)。把资源纳入作为Production Planning的一个步骤。该步骤的目标是在产能供应角度保持一个可以执行的计划。这一步的潜在结果是部分瓶颈工序需要调整时间。

    1. 其他非瓶颈资源的重新调整

    因为上述第四点的调整,其上下游物料的需求和供应时间需要调整,细节不赘述。

    理论上,PPDS中一次Production Planning可以定义多达10步,每一步都可以是为了实现一个特定的计划目的。 而相较之下,ECC的MRP则是简单一步到底的方式,无法实现企业复杂计划需求。在过去,这类复杂需求基本上是手工处理的同义词。

    Production Planning的定制灵活性增加,如第一点区别所述,Production Planning可以使用各种Heuristic来实现特定计划目的。除了SAP标准提供的多个Heuristics之外,用户可以自开发定义Heuristic。从而使MRP的定制开发实现变得相对简单。

    而在ECC中如果要对标准的MRP运算逻辑进行更改就是System Modification,除了少数的BADI能使用之外,工具相当之少。大部分企业是很难改MRP运算逻辑的,因为风险太大且很难全面评估。而在PPDS中则不存在这个问题。除了Heuristic可以自定义之外,哪些物料或者资源运行该Heuristic是可以在选择屏幕中限定的。该方法足够灵活,同时风险也大大降低。
     1. 关于需求和供应的追溯性报告(Pegging Relationship)

    ECC中大家知道在MD04里有个溯源需求(Pegging Requirement)的按钮,可动态匹配需求项和供应项形成一个基于BOM多层次向上向下追溯性报告。用户通过此功能知道该供应项是由哪些需求项触发的。同时SAP还提供Order Progress Report(CO46 /MD4C)之类的报表功能(如下图)支持下溯性报告。故这些追溯性工具是支持从上到下或自下而上。
    这些上下层需求/供应的匹配,链接了企业内部和外部的供应链节点。这些节点上的一个需求项和供应项的变动直接影响供应链上的各个其他节点。 在排程和客户交期承诺中等等都可能用到这些信息。但是因为其不储存在数据库中,就失去了为这些重要业务/功能服务的机会。

    在APO PPDS中,需求和供应的动态匹配链接成为Pegging Relationship. 所不同的是这些数据储存在数据库表中,所以其他功能应用可调用这些数据去实现特定的计划和排产功能。比如可以实现在排产中当一个上层工单被移动时希望原来Pegged的下层工单同步进行移动。

    这在ECC中标准功能是无法实现的,ECC的Capacity Leveling功能只能支持用户单层的排产,虽然在MRP中下层可能会出现Exception Message,但是改变不了用户需要手工逐层调整各个层次计划的悲伤事实。这也就是为什么CM21在单层BOM情况下通过一些配置还是能用的,但是多层BOM就束手无策了。核心问题就出在Pegging Relationship上。

    APO中Pegging在Location Product是单独有主数据需要维护(见下图)
    然后在Product View(/N/SAPAPO/RRP3)中除了正常的element界面(类似MD04)之外有单独的一个Tab Pegging Overview显示这些数据(见下图);
    Pegging Relationship可以是动态的也可以是固定的。APO可应用Heuristic来固定Pegging Relationship或者删除Pegging Relationship来配合特定的计划排程步骤。
    在ECC中计划的精度通常是在天这个级别。ECC中即使需求方是有具体时间点,比如工单工序开工时间决定的物料相关需求的时间实际上是精确到秒的,但在MRP计算中是按照天去考虑该相关需求,产生一个计划订单去满足该相关需求,该计划订单的Available时间是相关需求日期的前一天的结束时间。即相关需求的小时/分钟/秒根本不在MRP考虑范围内。

    同样的例证,一张工单的结束时间假设是上午11:00, 但是Available时间默认为第二天也体现了这种逻辑。类似的情况也发生在销售订单上,就算销售订单上可输入交货小时/分钟也不在MRP考虑范围中。总结来说,传统MRP自带冗余逻辑将一天内的小时/分钟抹掉了。供应项往往需要一定的提前量来满足需求。

    而APO中可以细到小时/分钟/秒(见下图),这是Product View的界面,类似于ECC的MD04. 可以看到除了日期还有具体时间(时分秒)。

    相关文章

      网友评论

          本文标题:PPDS

          本文链接:https://www.haomeiwen.com/subject/ujpwhrtx.html