简介这份生产计划培训手册聚焦APS系统中的ASCP高级计划与排程功能面向制造业计划员、供应链管理者和ERP实施顾问。内容以Hitachi Consulting的ASCP为主线完整呈现需求整理、预测、内销转码、生产计划、物料计划、作业排程的业务流与数据流既讲清数据准备的方法和收集架构也演示定义计划、运行计划、分析计划结果、处理例外信息的具体操作并覆盖跟单件、共享件、中央空调虚拟生产过账、预测与产销平衡等典型业务场景。整套资料共1个PPTX文件大小3.74MB配套11个章节模块配有大量流程图、界面示意和操作演示适合按章节循序学习或作为日常排产工作参考。目前已吸引190人学习下载能够帮助读者快速建立APS/ASCP从数据准备到计划执行再到结果优化的闭环管理认知进而提升排产效率、降低库存成本。1. 从ASCP闭环看生产计划APS实施先把数据跑通几年前我第一次在制造企业接触Oracle ASCP时误以为把需求录入系统、点运行就能拿到可用的生产计划。实际上整个APS高级计划与排程项目的成败有一半压在数据准备和计划参数上。这份以日立咨询为美的做的培训手册虽然以pptx形式流传但内容逻辑比很多正式文档都完整。它把业务流和数据流拧成一条线ASCP运行前要收集数据运行后要看例外再经过计划员工作台分析最终把计划单释放到ERP执行。四步缺一不可前两步做不好后面解析例外的时间会翻倍。适合正在做APS选型、或者已经从MPS/MRP走向高级计划排程的制造业计划团队。2. ASCP数据准备先搞清哪些数据进入计划再谈收集频率2.1 参与ASCP运算的数据静态主数据与动态业务数据在ASCP里数据分为两类一类是长期不太变的主数据另一类是每天在变的业务数据。静态主数据包括组织、物料、物料清单、工艺路线、资源、日历、来源补充规则、安全库存等动态业务数据包括预测、主需求计划、销售订单、现有量、采购订单及申请、供应商反馈、在制品、物料及资源需求等。下表把常见数据和它们影响的环节对应起来。数据类别典型数据影响环节静态主数据组织、物料、BOM、资源、工艺路线、日历、来源规则计划展开的骨架动态业务数据预测、销售订单、采购、在制品、现有量供需平衡的输入为什么物料属性特别重要ASCP识别物料时有用到超过200个属性位一个属性设错计划结果会完全不同。比如“计划方法”设成不计划物料就可能完全不参与运算BOM里的替代组件、工艺路线里的替代资源则影响短期排程的可行性。数据质量决定了ASCP计划结果的正确性和可执行性这一条没有捷径。2.2 数据收集方法和频率完全、定向、净变更Oracle ASCP提供三种数据收集方法完全刷新会删除现有数据再全量重新收集速度最慢但逻辑最简单定向数据收集只刷新指定内容适合修复某类数据的遗漏净更改只收集变更对象速度最快但校验逻辑最复杂。PPT中美的的方案因为存在客制化程序采用完全刷新。实际项目里如果计划频率是每日完全刷新建议放在夜间工单反馈和订单录入完成后如果计划是周度至少每周收集一次。定向收集适合“发现某类数据漏了”的修复场景不太适合日常批量作业。2.3 Midea ASCP数据收集架构与ST/ODS检查美的ASCP数据收集架构是典型的三段式源数据库ADS通过Pull Program产生快照写入Staging Table再由ODS load把ST表数据做ID转换后加载到ODSODS继续通过Planning data pull加载到PDS最终启动ASCP计划。因为销售数据、供应商反馈PR形式和预测数据都从ST表进入ASCP所以ST到ODS这一步最容易出问题。实际排查时会看ST表和checklog表示意SQL如下-- 示意查 ST 到 ODS 的校验结果不同版本表名会有差异 SELECT collection_run_id, object_name, rows_inserted, status FROM msc_st_check_log WHERE collection_run_id :p_run_id ORDER BY object_name;collection_run_id是当次收集的批次号object_name是要检查的数据对象名称rows_inserted表示本次插入行数status表示该对象的校验状态。如果某个对象连续多次rows_inserted为0或status不是成功要立刻回到源系统看数据是否符合校验要求例如销售订单日期跨日历、物料无效等。这个查询最适合在客制化ST插入之后自动跑一遍把失败对象写到日志由IT定时检查。2.4 查询数据收集结果从工作台验证数据是否到位ASCP提供了一个数据收集工作台路径是“高级供应链计划员 - 收集 - 查看收集的数据”。使用时选择供应和需求两个方向按组织、日期、物料等条件过滤然后检查有没有“该有而没有”的数据。我一般会把查询结果导出成Excel比对前一天的订单数、预测行数、库存量是否合理。不要只看有没有报错还要看数量级变化。很多数据丢失是源系统接口时间差造成的运行ASCP前先看一眼这个工作台能省下不少分析例外的时间。3. 定义ASCP计划参数决定计划类型页面顺序决定可维护性3.1 计划名称、计划类型和三个关键勾选项定义ASCP计划的入口是“高级供应链计划员 - 供应链计划 - 名称”。创建名称时有几个点必须抠清楚计划名称最大10个字符不能只图好记因为提交请求和报表都会显示说明字段要写清楚是“EDD日计划”还是“ECC周计划”以免日后找不到勾选ATP表示该计划作为GOP/ATP的基础美的方案中的日ECC计划需要勾选但同一时间里只能有一个成功运行的ATP计划勾多了反而会互相覆盖自动释放生产一般不勾选因为手动释放更稳通知按需勾选勾了会在计划完成后自动发工作流给相关人。计划类型不外乎MPS和MRPMPS多面向独立需求MRP向下展开相关需求实际应用会把MPS计划结果再喂给MRP。3.2 计划参数主要页面从主页面到决策规则PPT把定义计划参数拆成了五个页面主要页面、汇总页面、组织页面、约束页面、决策规则页面。关键字段和业务含义可以按下面的表格去配置。页面关键字段业务含义与建议主要页面计划策略、计划方法、发运窗口、ATP规则决定整张计划的计算范围发运窗口要匹配订单频率汇总页面汇总需求、汇总供应、中途汇总影响计划结果展示粒度建议按天或按周汇总组织页面参与计划的组织、组织层级多组织场景下不参与计划的组织不要勾入约束页面资源约束、物料约束、排程时界有限产能和无限产能的差别初期先跑无限决策规则页面计划员、订单优先级、安全库存策略、例外集决定计划如何“妥协”优先级和例外集要一起设设置时最容易出问题的不是不知道参数在哪而是多套计划共用同一组参数但业务规则不同。常见做法是按业务场景复制计划然后只改约束页面和决策规则页面。例如EDD计划用交期优先ECC计划用成本或批量合并优先两套计划共存避免频繁改参数。3.3 运行ASCP计划与状态检查运行计划的入口是“高级供应链计划员 - 供应链计划 - 计划”选中计划后提交并发请求。并发请求会调用ASCP引擎运行时间取决于数据量和处理复杂度。可以设定每日运行时间表例如在夜间数据收集完成后自动启动。提交后如果怀疑状态不对可以直接查MSC_PLANS表-- 查看计划运行状态PLAN_NAME 替换为实际计划名 SELECT plan_name, status, start_time, end_time FROM msc_plans WHERE plan_name EDD_DAY ORDER BY start_time DESC;status字段通常能看到COMPLETE、RUNNING、ERROR等状态。COMPLETE不代表结果没问题只是运算结束ERROR时去并发请求日志里看具体报错最常见的错误仍来自于数据收集阶段的缺失。运行时间突然变长优先查是不是数据收集量成倍增加而不是抱怨服务器性能。4. 计划员工作台从例外消息反推计划问题的根因4.1 工作台怎么过滤供需计划员工作台是分析ASCP结果的必经之路路径在“高级供应链计划员 - 计划员工作台”。打开后会看到供应、需求、计划单等多个页签关键是先设置过滤条件通常按组织、计划员代码、日期范围、物料编号过滤。过滤条件太少几十万行数据直接卡死过滤条件太严格又会漏掉相关供给。我一般会先按组织加未来两周加例外类型非空去查看到有问题的行再逐条钻取而不是一开始就看全量。4.2 ASCP例外信息比红色警告更值得先看的字段ASCP运行完会自动生成例外信息这些信息不是报错而是计划在约束条件下妥协的结果。常见例外有资源能力不足、物料短缺、需求日期早于供应日期、计划单被推迟、安全库存被消耗等。例外类型含义计划员动作资源不足某天产能超过资源最大负荷调整班次或转到替代资源物料短缺物料供应日期晚于需求日期确认采购提前期或调整需求时间供应早于需求库存长期占用调整计划单开始时间订单被推迟因约束无法满足交期与销售沟通交期或提升优先级查看例外可以使用MSC_EXCEPTIONS视图示意SQL-- 按严重程度查看例外的分布 SELECT exception_type, severity_code, item_name, message_text, due_date FROM msc_exceptions WHERE plan_id :p_plan_id ORDER BY severity_code DESC, due_date;这里plan_id是计划的内部ID可以在MSC_PLANS中查到。severity_code把严重级别排前面due_date用来看临近交期的冲突。同一张计划里例外可能很多先看“物料短缺”和“资源不足”两类因为它们对执行层影响最大其他例外往往可以由系统自动消化。4.3 EDD和ECC计划结果怎么分析美的方案里日EDD和日ECC是两种不同侧重的计划结果。EDD按最早交货日期去排程适合交期敏感的内销订单ECC更重视合并规则和例外控制适合共享件多、对批量敏感的场景。回到实际排产调度时经常会提到“越急越优先”这句话在ASCP里不是靠拍脑袋实现的而是由EDD计划的目标函数和决策规则页面里的优先级共同作用。计划员的工作不是去救火而是把例外消息按严重度排好让系统在下一轮计划里自动把高优先级订单提到前面。分析时不要混用两套结果先用EDD判断能不能保交期再用ECC看要不要合并批量。若两者差异大通常是因为物料约束或资源约束把EDD方案推后了这时回到例外消息里看是哪类约束造成的。4.4 把计划单释放到执行系统分析结束后要释放计划单。ASCP支持自动释放和手动释放两种方式自动释放会在计划运行完成后根据物料属性里的“释放时间”字段把计划单推到WIP或采购模块美的方案中因为是人工确认不勾选自动释放由计划员在计划员工作台里按行释放。释放前建议先看两类数据一是计划单二是实施建议。特别留意被修改过开始时间的计划单这些行极容易在执行系统里造成早晚班切换问题。5. 总装跟单件落地从基础数据到联动下达工单5.1 跟单件是什么按件跟踪的总装计划场景总装跟单件是指需要按单件或批次追踪的总装订单常见于内销整机、部装自制件。普通物料计划可以按批合并跟单件不行因为后续质量追溯、售后维修都依赖“哪件产品用了哪批物料”。所以ASCP先在基础数据里把这些关系定义好再通过“总装跟单件查询”看到每一件的状态最后联动下达工单。很多APS项目把跟单件做砸不是因为系统不支持而是没有把总装部门和提前期设置好。5.2 总装跟单件基础数据设置清单先整理一遍PPT列出的设置对象这些设置全都要在ASCP业务操作前完成。设置项内容常见问题总装部门定义哪些组织是总装部门多组织漏配计划查不到部门快速代码业务分类、工单类型等代码写错后续报表归类乱提前期装配提前期、检验提前期提前期太粗排程结果不可信用户权限限定计划员可操作组织或物料权限过大会有误释放风险总部装关系设置定义总装与部装的父子层级关系缺失导致来源追溯断掉优先级最高的是提前期和总部装关系。提前期可以先用历史平均数据再逐步按物料细分总部装关系则必须和工艺路线、BOM保持一致否则ASCP计算总装工单开始时间时会缺少依据。5.3 总装跟单件的需求来源与联动下达跟单件的业务需求来源主要为营销订单、预测冲减、备件需求。ASCP把这些需求整理成计划单后计划员在“总装跟单件查询”页面按单件看确认可以后执行联动下达系统按计划单生成WIP工单。生成后不要直接回主流程先在总装工单里查一遍-- 根据 ASCP 计划单 ID 查总装工单 SELECT we.wip_entity_name, we.status_type, wdj.planner_code, wdj.source_order_id FROM wip_discrete_jobs wdj, wip_entities we WHERE wdj.wip_entity_id we.wip_entity_id AND wdj.source_order_id :p_plan_order_id;wip_entity_name是系统生成的工单号status_type决定工单当前状态planner_code是计划员代码source_order_id会保留ASCP计划单的来源ID。如果查不到记录说明计划单没有成功下达或者被拆分成多张工单要在计划员工作台里重新检查释放动作。联动下达之后并不是立刻完成。ERP收到计划单后会校验物料可用、工艺路线是否存在、工序是否齐套任何一个校验不过工单都不会生成。所以查找生成工单时如果发现缺失先从这三个校验入手。我通常还会再查一次计划单状态如果还在待释放状态说明根本没有触发接口这时候不需要盯工单而是盯计划单的释放操作。6. 共享件拆分追溯与计划单下达验证6.1 为什么要手工拆分共享件计划单共享件是多个总装件共用的物料。ASCP按合并规则生成一张计划单但需求来源可能分散在不同日期一条订单要求周三用另一条要求下周一用。共用一张计划单要么提前占用库存要么延迟到货。手工拆分就是把计划单按时间段或需求来源切开比改BOM和来源规则更快也是计划员最常用的应急处置手段。6.2 修改开始时间、手工拆分与拆消操作路径我一般按“共享件查询 - 计划单开始时间修改 - 计划单手工拆分 - 拆分取消 - 计划单下达”的顺序走。先选中计划单修改开始时间让系统知道给哪个时间点供应手工拆分时填写拆分数和数量如果拆错了执行拆分取消把拆出来的行合并回去确认无误后再点计划单下达。拆分时拆分数不宜超过实际需求段数拆太细会拖慢执行系统接收。6.3 追溯来源结构与来源明细验证拆分是否完整拆分后的验证不能只看总数。ASCP计划单有“追溯来源结构”和“来源明细”两个视图来源结构按树状展示计划单由哪些销售订单、预测或安全库存引出来源明细展示每一条需求的数量和日期。验证方法很简单对照来源明细把拆分后的计划单数量按相同日期段重新累加应等于该段的来源需求合计。如果有差异先看安全库存和现有量是否被系统自动扣减再看是否有预测冲减未处理。要想减少返工建议把检查结果留在计划员工作台的备注字段里保留单一计划单与来源明细同屏比来回翻三个页面更能快速发现拆分散差。这个习惯养成后共享件计划单的异常率会明显下降。本文还有配套的精品资源点击获取 从ASCP数据准备到计划参数：APS实施先把数据跑通
简介这份生产计划培训手册聚焦APS系统中的ASCP高级计划与排程功能面向制造业计划员、供应链管理者和ERP实施顾问。内容以Hitachi Consulting的ASCP为主线完整呈现需求整理、预测、内销转码、生产计划、物料计划、作业排程的业务流与数据流既讲清数据准备的方法和收集架构也演示定义计划、运行计划、分析计划结果、处理例外信息的具体操作并覆盖跟单件、共享件、中央空调虚拟生产过账、预测与产销平衡等典型业务场景。整套资料共1个PPTX文件大小3.74MB配套11个章节模块配有大量流程图、界面示意和操作演示适合按章节循序学习或作为日常排产工作参考。目前已吸引190人学习下载能够帮助读者快速建立APS/ASCP从数据准备到计划执行再到结果优化的闭环管理认知进而提升排产效率、降低库存成本。1. 从ASCP闭环看生产计划APS实施先把数据跑通几年前我第一次在制造企业接触Oracle ASCP时误以为把需求录入系统、点运行就能拿到可用的生产计划。实际上整个APS高级计划与排程项目的成败有一半压在数据准备和计划参数上。这份以日立咨询为美的做的培训手册虽然以pptx形式流传但内容逻辑比很多正式文档都完整。它把业务流和数据流拧成一条线ASCP运行前要收集数据运行后要看例外再经过计划员工作台分析最终把计划单释放到ERP执行。四步缺一不可前两步做不好后面解析例外的时间会翻倍。适合正在做APS选型、或者已经从MPS/MRP走向高级计划排程的制造业计划团队。2. ASCP数据准备先搞清哪些数据进入计划再谈收集频率2.1 参与ASCP运算的数据静态主数据与动态业务数据在ASCP里数据分为两类一类是长期不太变的主数据另一类是每天在变的业务数据。静态主数据包括组织、物料、物料清单、工艺路线、资源、日历、来源补充规则、安全库存等动态业务数据包括预测、主需求计划、销售订单、现有量、采购订单及申请、供应商反馈、在制品、物料及资源需求等。下表把常见数据和它们影响的环节对应起来。数据类别典型数据影响环节静态主数据组织、物料、BOM、资源、工艺路线、日历、来源规则计划展开的骨架动态业务数据预测、销售订单、采购、在制品、现有量供需平衡的输入为什么物料属性特别重要ASCP识别物料时有用到超过200个属性位一个属性设错计划结果会完全不同。比如“计划方法”设成不计划物料就可能完全不参与运算BOM里的替代组件、工艺路线里的替代资源则影响短期排程的可行性。数据质量决定了ASCP计划结果的正确性和可执行性这一条没有捷径。2.2 数据收集方法和频率完全、定向、净变更Oracle ASCP提供三种数据收集方法完全刷新会删除现有数据再全量重新收集速度最慢但逻辑最简单定向数据收集只刷新指定内容适合修复某类数据的遗漏净更改只收集变更对象速度最快但校验逻辑最复杂。PPT中美的的方案因为存在客制化程序采用完全刷新。实际项目里如果计划频率是每日完全刷新建议放在夜间工单反馈和订单录入完成后如果计划是周度至少每周收集一次。定向收集适合“发现某类数据漏了”的修复场景不太适合日常批量作业。2.3 Midea ASCP数据收集架构与ST/ODS检查美的ASCP数据收集架构是典型的三段式源数据库ADS通过Pull Program产生快照写入Staging Table再由ODS load把ST表数据做ID转换后加载到ODSODS继续通过Planning data pull加载到PDS最终启动ASCP计划。因为销售数据、供应商反馈PR形式和预测数据都从ST表进入ASCP所以ST到ODS这一步最容易出问题。实际排查时会看ST表和checklog表示意SQL如下-- 示意查 ST 到 ODS 的校验结果不同版本表名会有差异 SELECT collection_run_id, object_name, rows_inserted, status FROM msc_st_check_log WHERE collection_run_id :p_run_id ORDER BY object_name;collection_run_id是当次收集的批次号object_name是要检查的数据对象名称rows_inserted表示本次插入行数status表示该对象的校验状态。如果某个对象连续多次rows_inserted为0或status不是成功要立刻回到源系统看数据是否符合校验要求例如销售订单日期跨日历、物料无效等。这个查询最适合在客制化ST插入之后自动跑一遍把失败对象写到日志由IT定时检查。2.4 查询数据收集结果从工作台验证数据是否到位ASCP提供了一个数据收集工作台路径是“高级供应链计划员 - 收集 - 查看收集的数据”。使用时选择供应和需求两个方向按组织、日期、物料等条件过滤然后检查有没有“该有而没有”的数据。我一般会把查询结果导出成Excel比对前一天的订单数、预测行数、库存量是否合理。不要只看有没有报错还要看数量级变化。很多数据丢失是源系统接口时间差造成的运行ASCP前先看一眼这个工作台能省下不少分析例外的时间。3. 定义ASCP计划参数决定计划类型页面顺序决定可维护性3.1 计划名称、计划类型和三个关键勾选项定义ASCP计划的入口是“高级供应链计划员 - 供应链计划 - 名称”。创建名称时有几个点必须抠清楚计划名称最大10个字符不能只图好记因为提交请求和报表都会显示说明字段要写清楚是“EDD日计划”还是“ECC周计划”以免日后找不到勾选ATP表示该计划作为GOP/ATP的基础美的方案中的日ECC计划需要勾选但同一时间里只能有一个成功运行的ATP计划勾多了反而会互相覆盖自动释放生产一般不勾选因为手动释放更稳通知按需勾选勾了会在计划完成后自动发工作流给相关人。计划类型不外乎MPS和MRPMPS多面向独立需求MRP向下展开相关需求实际应用会把MPS计划结果再喂给MRP。3.2 计划参数主要页面从主页面到决策规则PPT把定义计划参数拆成了五个页面主要页面、汇总页面、组织页面、约束页面、决策规则页面。关键字段和业务含义可以按下面的表格去配置。页面关键字段业务含义与建议主要页面计划策略、计划方法、发运窗口、ATP规则决定整张计划的计算范围发运窗口要匹配订单频率汇总页面汇总需求、汇总供应、中途汇总影响计划结果展示粒度建议按天或按周汇总组织页面参与计划的组织、组织层级多组织场景下不参与计划的组织不要勾入约束页面资源约束、物料约束、排程时界有限产能和无限产能的差别初期先跑无限决策规则页面计划员、订单优先级、安全库存策略、例外集决定计划如何“妥协”优先级和例外集要一起设设置时最容易出问题的不是不知道参数在哪而是多套计划共用同一组参数但业务规则不同。常见做法是按业务场景复制计划然后只改约束页面和决策规则页面。例如EDD计划用交期优先ECC计划用成本或批量合并优先两套计划共存避免频繁改参数。3.3 运行ASCP计划与状态检查运行计划的入口是“高级供应链计划员 - 供应链计划 - 计划”选中计划后提交并发请求。并发请求会调用ASCP引擎运行时间取决于数据量和处理复杂度。可以设定每日运行时间表例如在夜间数据收集完成后自动启动。提交后如果怀疑状态不对可以直接查MSC_PLANS表-- 查看计划运行状态PLAN_NAME 替换为实际计划名 SELECT plan_name, status, start_time, end_time FROM msc_plans WHERE plan_name EDD_DAY ORDER BY start_time DESC;status字段通常能看到COMPLETE、RUNNING、ERROR等状态。COMPLETE不代表结果没问题只是运算结束ERROR时去并发请求日志里看具体报错最常见的错误仍来自于数据收集阶段的缺失。运行时间突然变长优先查是不是数据收集量成倍增加而不是抱怨服务器性能。4. 计划员工作台从例外消息反推计划问题的根因4.1 工作台怎么过滤供需计划员工作台是分析ASCP结果的必经之路路径在“高级供应链计划员 - 计划员工作台”。打开后会看到供应、需求、计划单等多个页签关键是先设置过滤条件通常按组织、计划员代码、日期范围、物料编号过滤。过滤条件太少几十万行数据直接卡死过滤条件太严格又会漏掉相关供给。我一般会先按组织加未来两周加例外类型非空去查看到有问题的行再逐条钻取而不是一开始就看全量。4.2 ASCP例外信息比红色警告更值得先看的字段ASCP运行完会自动生成例外信息这些信息不是报错而是计划在约束条件下妥协的结果。常见例外有资源能力不足、物料短缺、需求日期早于供应日期、计划单被推迟、安全库存被消耗等。例外类型含义计划员动作资源不足某天产能超过资源最大负荷调整班次或转到替代资源物料短缺物料供应日期晚于需求日期确认采购提前期或调整需求时间供应早于需求库存长期占用调整计划单开始时间订单被推迟因约束无法满足交期与销售沟通交期或提升优先级查看例外可以使用MSC_EXCEPTIONS视图示意SQL-- 按严重程度查看例外的分布 SELECT exception_type, severity_code, item_name, message_text, due_date FROM msc_exceptions WHERE plan_id :p_plan_id ORDER BY severity_code DESC, due_date;这里plan_id是计划的内部ID可以在MSC_PLANS中查到。severity_code把严重级别排前面due_date用来看临近交期的冲突。同一张计划里例外可能很多先看“物料短缺”和“资源不足”两类因为它们对执行层影响最大其他例外往往可以由系统自动消化。4.3 EDD和ECC计划结果怎么分析美的方案里日EDD和日ECC是两种不同侧重的计划结果。EDD按最早交货日期去排程适合交期敏感的内销订单ECC更重视合并规则和例外控制适合共享件多、对批量敏感的场景。回到实际排产调度时经常会提到“越急越优先”这句话在ASCP里不是靠拍脑袋实现的而是由EDD计划的目标函数和决策规则页面里的优先级共同作用。计划员的工作不是去救火而是把例外消息按严重度排好让系统在下一轮计划里自动把高优先级订单提到前面。分析时不要混用两套结果先用EDD判断能不能保交期再用ECC看要不要合并批量。若两者差异大通常是因为物料约束或资源约束把EDD方案推后了这时回到例外消息里看是哪类约束造成的。4.4 把计划单释放到执行系统分析结束后要释放计划单。ASCP支持自动释放和手动释放两种方式自动释放会在计划运行完成后根据物料属性里的“释放时间”字段把计划单推到WIP或采购模块美的方案中因为是人工确认不勾选自动释放由计划员在计划员工作台里按行释放。释放前建议先看两类数据一是计划单二是实施建议。特别留意被修改过开始时间的计划单这些行极容易在执行系统里造成早晚班切换问题。5. 总装跟单件落地从基础数据到联动下达工单5.1 跟单件是什么按件跟踪的总装计划场景总装跟单件是指需要按单件或批次追踪的总装订单常见于内销整机、部装自制件。普通物料计划可以按批合并跟单件不行因为后续质量追溯、售后维修都依赖“哪件产品用了哪批物料”。所以ASCP先在基础数据里把这些关系定义好再通过“总装跟单件查询”看到每一件的状态最后联动下达工单。很多APS项目把跟单件做砸不是因为系统不支持而是没有把总装部门和提前期设置好。5.2 总装跟单件基础数据设置清单先整理一遍PPT列出的设置对象这些设置全都要在ASCP业务操作前完成。设置项内容常见问题总装部门定义哪些组织是总装部门多组织漏配计划查不到部门快速代码业务分类、工单类型等代码写错后续报表归类乱提前期装配提前期、检验提前期提前期太粗排程结果不可信用户权限限定计划员可操作组织或物料权限过大会有误释放风险总部装关系设置定义总装与部装的父子层级关系缺失导致来源追溯断掉优先级最高的是提前期和总部装关系。提前期可以先用历史平均数据再逐步按物料细分总部装关系则必须和工艺路线、BOM保持一致否则ASCP计算总装工单开始时间时会缺少依据。5.3 总装跟单件的需求来源与联动下达跟单件的业务需求来源主要为营销订单、预测冲减、备件需求。ASCP把这些需求整理成计划单后计划员在“总装跟单件查询”页面按单件看确认可以后执行联动下达系统按计划单生成WIP工单。生成后不要直接回主流程先在总装工单里查一遍-- 根据 ASCP 计划单 ID 查总装工单 SELECT we.wip_entity_name, we.status_type, wdj.planner_code, wdj.source_order_id FROM wip_discrete_jobs wdj, wip_entities we WHERE wdj.wip_entity_id we.wip_entity_id AND wdj.source_order_id :p_plan_order_id;wip_entity_name是系统生成的工单号status_type决定工单当前状态planner_code是计划员代码source_order_id会保留ASCP计划单的来源ID。如果查不到记录说明计划单没有成功下达或者被拆分成多张工单要在计划员工作台里重新检查释放动作。联动下达之后并不是立刻完成。ERP收到计划单后会校验物料可用、工艺路线是否存在、工序是否齐套任何一个校验不过工单都不会生成。所以查找生成工单时如果发现缺失先从这三个校验入手。我通常还会再查一次计划单状态如果还在待释放状态说明根本没有触发接口这时候不需要盯工单而是盯计划单的释放操作。6. 共享件拆分追溯与计划单下达验证6.1 为什么要手工拆分共享件计划单共享件是多个总装件共用的物料。ASCP按合并规则生成一张计划单但需求来源可能分散在不同日期一条订单要求周三用另一条要求下周一用。共用一张计划单要么提前占用库存要么延迟到货。手工拆分就是把计划单按时间段或需求来源切开比改BOM和来源规则更快也是计划员最常用的应急处置手段。6.2 修改开始时间、手工拆分与拆消操作路径我一般按“共享件查询 - 计划单开始时间修改 - 计划单手工拆分 - 拆分取消 - 计划单下达”的顺序走。先选中计划单修改开始时间让系统知道给哪个时间点供应手工拆分时填写拆分数和数量如果拆错了执行拆分取消把拆出来的行合并回去确认无误后再点计划单下达。拆分时拆分数不宜超过实际需求段数拆太细会拖慢执行系统接收。6.3 追溯来源结构与来源明细验证拆分是否完整拆分后的验证不能只看总数。ASCP计划单有“追溯来源结构”和“来源明细”两个视图来源结构按树状展示计划单由哪些销售订单、预测或安全库存引出来源明细展示每一条需求的数量和日期。验证方法很简单对照来源明细把拆分后的计划单数量按相同日期段重新累加应等于该段的来源需求合计。如果有差异先看安全库存和现有量是否被系统自动扣减再看是否有预测冲减未处理。要想减少返工建议把检查结果留在计划员工作台的备注字段里保留单一计划单与来源明细同屏比来回翻三个页面更能快速发现拆分散差。这个习惯养成后共享件计划单的异常率会明显下降。本文还有配套的精品资源点击获取