简介围绕 Oracle EBS ASCP 高级计划排程的方案设置与测试这份 doc 文档以 YY 手机有限公司为案例构建 M1、M2、M3 工厂与 D1、D2 分销中心的供应链场景并给出需求预测、物料提前期、价格及生产能力等基础数据适合 ERP 实施顾问、供应链计划人员及 ASCP 模块学习者对照查阅。内容从物料定义与组织分配入手延伸到 BOM 与工艺路线、来源规则和分配清单、MDS 需求录入、供应链计划定义与运行并覆盖计划下达、采购、生产、入库、发运等执行结果同时包含计划员工作台查看供应/需求、例外汇总和结果导出等分析视角便于读者把主数据准备、计划运算与执行反馈串成完整链路。资源包为 1 个 doc 文件约 1.43MB结构集中适合按测试场景逐项核对。目前已有 1953 人学习可作为 ASCP 方案设置、测试案例设计和计划结果复盘时的参考材料。1. 先定住需求一套能跑通多工厂协同的 ASCP 测试方案计划跑完界面上一片祥和需求全部有着落例外列表里只剩两三条无关痛痒的提示。等到执行环节才发现M2 的机身任务已经排到 6 月中旬采购申请到货日期比需求晚三天。查了一下午问题不在计划引擎而在建模时资源单位用量那一格——填 10 还是填 1差了一个量级。Oracle EBS ASCP 这类高级计划排程功能最容易背的锅就是“算不准”实际上大部分算不准在点击运行之前就已经注定。这套方案以一个手机制造企业的多工厂场景为载体三个工厂分别负责总装、机身、机盖两家分销中心承接区域需求四家供应商提供电池、键盘、电路板、屏幕从物料定义一路做到计划下达、采购、生产、发运把 ERP 里一条完整的供应链计划链路走通适合要交一份完整 ASCP 测试方案的人对照着做。2. 场景建模三个工厂、两个分销中心的组织与物料骨架2.1 组织架构先落成库存组织与责任整个方案里真正需要在系统里“盖房子”的只有第一层定义主组织和五个库存组织。主组织放物料模板M1、M2、M3、D1、D2 各自作为独立的库存组织存在负责总装、机身制造、机盖制造以及两个分销中心的仓储与需求承接。这里有个常见的认知偏差很多人以为“一个公司就是一个组织”其实在 EBS 里组织是能力边界工厂能做制造、分销中心只能做接收和发运能力的差别就靠组织参数和物料组织属性来表达。责任Responsibility的划分按角色来生产与分销经理负责物料、采购、接收这些执行动作供应链计划员负责分配清单高级供应链计划员负责计划定义和运行。测试时切换责任要当作一个真实动作来做别用一个超级用户从头点到尾因为不同责任下能看到的字段和按钮是不同的权限没配全的人往往在“怎么找不到这个按钮”上耗掉半天。物料在主组织建一次再分配给需要它的组织这是 EBS 多组织模型的基本规矩。以机盖 YY-JG 为例主组织建好物料后分配给 M1 和 M2 两个组织但两个组织的属性必须分别维护M1 的“制造或采购”选采购M1 不造机盖靠 M2 传送过来M2 选制造M2 才是真正生产机盖的地方。同一颗料在两个组织拥有两种身份这是整个方案里最容易被跳过、又最致命的一步。2.2 物料主数据六个字段决定物料在计划里的身份物料编码按“YY-”加物料类型前缀来做成品 YY-SJ、机盖 YY-JG、机身 YY-JS采购件 YY-SC 屏幕、YY-CB 电路板、YY-KB 键盘、YY-BA 电池。编码本身不参与计算但它是后面所有 BOM、来源规则、分配清单的引用键规范一点能少踩很多坑。物料编码类型提前期天供应来源手机成品YY-SJ成品1M1 制造机盖YY-JG子装配1M2 制造传送至 M1机身YY-JS子装配1M3 制造传送至 M1屏幕YY-SC采购件1供应商 S4电路板YY-CB采购件2供应商 S3键盘YY-KB采购件2供应商 S2电池YY-BA采购件3供应商 S1主数据里真正影响计划结果的字段有六个每个都要有明确的取值理由不能照模板抄完就算计划方法设为“MRP/MPP 计划”让物料进入物料需求计划的管辖范围预测控制设为“冲减衍生”保证销售订单进来时会冲减对应的预测数量不然需求会被重复计算一遍计划结果凭空多出一倍追溯方式选总装类追溯作用是让成品需求能顺着 BOM 一路贯穿到组件上计划员在结果里才能回答“这张工单是为哪一批需求做的”订单管理里启用“客户订购”让成品可以承接销售订单制造或采购标志按组织分别设置前面已经讲过计划员和例外集在组织属性里指定例外集统一选 ASCP保证例外信息能落到同一个集合里被集中查看。提示追溯方式属于“建好之后改起来很痛”的字段。物料一旦有了交易和计划结果再调整追溯设置历史数据的归属关系会变得混乱测试阶段就一次性定好。2.3 BOM 与工艺路线把产能换算成资源单位用量BOM 按三层来搭YY-SJ 由 YY-JG、YY-JS、YY-BA 组成一台手机对应一件机盖、一件机身、一块电池YY-JG 和 YY-JS 再各自挂各自的采购件。BOM 定义本身不难难的是和工艺路线对齐——BOM 说这个东西由什么构成工艺路线说这个东西在哪个部门、用哪个资源、花多少时间做出来两者不一致计划出来的产能就是假的。三个工厂的工作日历一致每周 5 天、每天 1 班、每班 8 小时。产能差异体现在资源上M1 每小时 5 千件M2 每小时 0.1 千件M3 每小时 5 千件。这套数字在系统里不是直接填“每小时产量”而是填它的倒数——资源单位用量含义是“生产一个单位的产品需要消耗多少资源小时”。工厂每小时产量千件资源单位用量小时/千件M1 总装50.2M2 机身0.110M3 机盖50.2M2 的工艺路线是这套方案里最值得讲的一处。先定义资源 YY-M2-R1定义部门 YY-M2-1 并把输入地点设为 M2然后在部门资源里挂上 YY-M2-R1取消“24 小时可用”勾选班次选白班、数量 1最后在工艺路线里选部门 YY-M2-1工序资源选 M2-R1单位用量填 10并把“计划”标志设为“是”。没有这个“是”这条工艺路线就只是档案不参与能力计算计划跑出来会是清一色的产能无限。2.4 用一条 SQL 做建模自检界面上一个个组织点进去核对太慢建模完成后用一条查询把物料在各组织的关键属性拉出来横向比对能在一屏之内发现漏配。-- 检查物料在哪些组织有定义以及组织层的制造/采购标志 SELECT p.organization_code AS 组织, msi.segment1 AS 物料编码, msi.description AS 物料描述, msi.planning_make_buy_code AS 制造采购标志, -- 1制造 2采购 msi.mrp_planning_code AS 计划方法, msi.exception_set_id AS 例外集 FROM mtl_system_items_b msi JOIN mtl_parameters p ON p.organization_id msi.organization_id WHERE msi.segment1 IN (YY-SJ,YY-JG,YY-JS,YY-SC,YY-CB,YY-KB,YY-BA) ORDER BY msi.segment1, p.organization_code;这条查询的逻辑是把物料主数据表按组织维度展开一个物料有几行就代表它被分配给了几个组织。看结果主要看三件事该出现的组织有没有出现YY-JG 应该只有 M1、M2 两行、制造采购标志符不符合业务M2 那行必须是制造、例外集有没有漏填。字段取值在不同版本里略有差异实际环境以数据字典为准但比对思路是通用的。发现漏配就直接回界面补不要在数据库里改测试文档要留下可复现的操作路径。3. 来源规则与分配清单让每颗料都知道自己从哪来3.1 三类来源规则怎么选来源规则回答的是“这颗料在这个组织里从哪获得”一共有三类采购来源、传送自、制造地点。判断顺序不复杂但要一个组织一个组织地过不能想当然。外购件用采购来源YY-BA、YY-SC、YY-CB、YY-KB 在各自需要它的组织里定义采购来源指向对应供应商。子装配件用传送自M1 里的 YY-JG 传送自 M2M1 里的 YY-JS 传送自 M3这条规则是跨工厂协同的核心。产成品用制造地点M1 里的 YY-SJ 来源类型选制造地点、组织填 M1。三类规则在三个组织 M1、M2、M3 里分别定义因为来源规则是组织级对象不是全局对象。这一步最常见的错误是只在 M1 里定义了全套规则然后指望 M2、M3 自动继承结果计划跑到 M2 就断了机身和机盖明明有需求却排不出任何供应。3.2 分配清单同一颗料在不同接收组织之间的份额分配清单解决的是“供给往哪分”的问题。为成品 YY-SJ 定义分配清单 YY-M1接收组织分别填 M1、D1、D2类型上 M1 选制造地点、D1 和 D2 选传送自来源组织统一填 M1分配百分比各 100%级别都填 1。这里 100% 不是笔误而是分配清单的机制决定的每个接收组织各自持有一条独立的分配记录百分比描述的是这颗料在该接收组织内部的满足份额不是三个组织之间的比例分摊。真正做多地供货分摊时才会出现 60/40 这种拆分测试场景里保持 100% 反而更干净因为一旦拆了百分比结果核对就要做加权出错时很难判断是分配错了还是计划错了。级别字段用来表达优先级。测试场景全部填 1表示三个接收组织没有先后。如果业务上要求分销中心优先于工厂库存就可以用级别区分但级别一旦引入计划结果的解释成本会明显上升答辩时也容易被追问建议先用单级别跑通。3.3 分配集把散落的规则打包成一个可复用对象来源规则和分配清单定义完它们还是散落的。分配集Sourcing Rule / Bill of Distribution 的组合对象的作用就是把这些规则收进一个命名对象里供计划引用。新建分配集名称 YYAPS-1把 YY-SJ 的分配清单 YY-M1 挂进去再把所有物料的来源补充规则一并加入覆盖 YY-SJ、YY-JG、YY-JS、YY-BA、YY-SC、YY-CB。这一步的价值在后面体现计划定义时只需要引用一个分配集名称而不是逐个物料去选规则。测试过程中如果发现某颗料的来源定义有问题改完规则后不用重新配计划只要规则已经在这个分配集里下一次计划运行就会带上新逻辑。定义完成后立刻查看多级供应链清单把整棵树从成品展开到采购件。这张清单是建模成果的第一次可视化呈现能在一屏里看到 M1 总装、M2/M3 分支、四家供应商的挂接关系是否完整。如果某层断了多级清单会直接显示不出来比跑完计划再看例外要早得多发现。提示分配集是计划定义的前置依赖。计划里的分配集字段是必填的没有可选项时先回头检查分配集是否保存成功、是否被正确挂到了当前组织。4. 计划定义与运行从 MDS 到计划员工作台4.1 MDS需求从哪张单子进来主需求计划MDS是整条链路的入口。在 D1、D2 两个分销中心各自定义一份 MDSD1 的命名为 YY-D1-MDS1冲减方式选“冲减”然后进入物料明细物料填 YY-SJ在详细资料里录入需求日期和数量。需求数据来自月初的市场预测5 月 2 日 10 千台5 月 25 日 20 千台。这两笔需求按分销中心拆开录入D1 和 D2 各承担一部分。测试场景里可以把 10 千和 20 千按同一比例拆到两个中心也可以集中放在一个中心但要保证两边加起来等于总量否则后面做倒推核对时对不上账。冲减方式选“冲减”而不是“不冲减”是为了让真实的销售订单进来时能够抵扣预测避免同一批需求被算两次。这一步和物料主数据里的“预测控制冲减衍生”是配套的一处设错需求就会翻倍而且从计划结果里看不出来只会在执行阶段表现为库存积压。4.2 计划选项四个页面怎么填新建供应链计划名称 YYAPS-1组织选测试账套下的 M1责任切换到高级供应链计划员。计划选项分四页每页解决一个问题。主要页面计划物料选“需求和供应计划物料”让计划同时管需求侧和供应侧分配集选前面定义的 YYAPS-1勾选“启用追溯”追溯方式选“按需求优先级追溯供应”这样计划员工作台里才能顺着供应反查需求来源。汇总页面计划合并相关参数保持默认测试场景不涉及多计划合并。组织页面把 D1、D2、M1、M2、M3 全部加入计划范围并分别为 D1、D2 挂上各自的 MDS。这一步漏掉任何一个组织该组织的供需就不参与运算计划结果会安静地少一块而且不会报错——这是 ASCP 里最典型的“黑匣子”式失败。约束页面先做非能力约束计划。非能力约束意味着不因为产能不足而拒绝需求只是把产能冲突记录成例外。第一次跑通链路时应该用这个模式先把物料和供需关系验证对再切到能力约束去看真实的产能瓶颈否则一上来就被产能例外淹没分不清是数据错了还是能力真的不够。4.3 启动计划与请求查看运行入口在组织 TST:M1 下选计划 YYAPS-1确认后系统提交一个后台请求。计划不是同步返回的一定要去看请求状态等它从“待处理”“运行中”走到“正常”或“警告”再去读结果。测试时最容易犯的低级错误是点完运行立刻切到工作台看到空白就以为计划没生效。请求完成后先看供应链清单组织选 TST:D1物料选 YY-SJ查看多级清单确认 M1、M2、M3 三个层级都展开出来了。如果只展开到 M1 就停了说明 M1 里机盖、机身的传送自规则没生效需要回到第 3 章去查来源规则。4.4 计划员工作台三样东西必须看进入计划员工作台后有三处是必须要看的不看就等于没跑计划。主要指标看总量层面的供需是否平衡。右键物料可以打开“供应/需求”窗口这里是逐笔的供需明细供应侧能看到建议的工单、采购申请、传送单需求侧能看到 MDS 带来的独立需求以及下层组件的相关需求。用“文件”菜单里的“导出”把这张明细导成 Excel是测试文档里最有说服力的一份凭证比界面截图更能说明计算过程。右键物料打开的“物料”窗口里目标、来源、使用处、替代、工艺路线、供应链几个页签可以逐层确认这颗料在计划视角下的画像工艺路线页签尤其值得看能直接验证资源单位用量是否被正确读取。例外汇总是最容易被跳过、又最有价值的一屏。能力不足、无来源、提前期不够、需求日期在过去这些问题都会在这里列出来。测试时把它当成检查清单逐条读比对着结果猜要快得多。4.5 计划执行把建议变成单据计划下达用一次性发放把组织间补货、制造任务、采购申请三类建议一起转成执行单据。发放之后的流程分两条线走。采购线以 YY-BA 为例ASCP 释放出来的采购申请没有订单编号需要到采购管理的“自动创建”里清掉采购员条件查出自动创建的申请选中 YY-BA点“自动”生成采购订单选好供应商后创建在发运页签里分配子库存 RIP最后审批状态变成“批准”。随后做采购接收再到现有量里确认库存真的进来了。生产线以 YY-JG 为例到在制品管理的离散任务里按装配件查找 YY-JG找到计划释放出来的任务在“工具”菜单里选“更改状态”改为“释放”。机身 YY-JS 同理。两条线都走完这批从需求到供应的闭环才算真正闭合。5. 避坑清单五个最容易翻车的点5.1 主数据与组织类问题现象计划结果的例外汇总里某个子装配件整片标着“无来源”供应侧一条建议都没有。原因物料分配给了组织但组织层的“制造或采购”标志没维护或者来源规则只在一个组织里定义了。解决先用第 2.4 节的 SQL 把物料在各组织的标志拉出来横向对比确认每个组织都有明确身份再逐个组织检查来源规则是否齐备。经验是无来源类例外九成出在组织维度漏配而不是规则类型选错。现象M2 的产能看起来永远充足无论需求多大都没有能力例外。原因部门资源里“24 小时可用”没取消或者班次数量填成了 24产能被放大三倍还有一种更隐蔽的情况工艺路线里“计划”标志没设成“是”这条路线根本没进能力计算。解决回到部门资源逐项核对勾选状态和班次数量再确认工艺路线上的计划标志。产能这个数一旦错了整个计划的交期承诺就不可信而且它不会报错属于典型的静默失败。现象资源单位用量填成每小时产量M2 直接填 0.1。原因把“产量”和“单位用量”当成同一个概念。解决记住单位用量是产量的倒数M2 每小时 0.1 千件单位用量就是 10 小时/千件。填反的后果是产能被放大 100 倍计划结果漂亮得不像话执行时全线延期。5.2 计划定义与结果类问题现象分销中心 D2 的需求在计划结果里完全消失也没有任何例外提示。原因计划选项的组织页面里没把 D2 加进计划范围或者加了组织但没挂 MDS。解决组织页面逐行确认 D1、D2、M1、M2、M3 五个组织齐全且 D1、D2 后面都挂上了对应的 MDS。这类问题最难受的地方在于静默——没有报错没有例外只是结果少了一块只能靠总量核对发现。现象计划给出的需求数量是预测的两倍。原因MDS 的冲减方式选了“不冲减”同时物料主数据的预测控制也不是“冲减衍生”预测和销售订单被重复计入。解决两处设置必须配套改完之后重新跑计划用需求总量和预测总量对比验证。现象计划刚跑完就急着做计划下达把明显不合理的建议转成了采购订单和工单。原因跳过了例外汇总只看主要指标。解决把“先读例外、再下达”固化成动作顺序例外没读完之前不碰下达按钮。这一条听起来像废话但真正在赶进度的时候翻车往往就翻在这里。6. 验收与答辩用倒推法核对计划结果验收这一步比对着界面截图说“你看它跑出来了”要有说服力得多。我的做法是先算一遍手算答案再拿系统结果去对对不上就说明某一层建模有问题。以 5 月的两笔需求合计 30 千台手机为锚点往下倒推电池 YY-BA 需要 30 千件提前期 3 天第一笔 10 千台的需求日期是 5 月 2 日那么对应的采购申请建议到货日期必须早于 5 月 2 日至少 3 天机身 YY-JS 需要 30 千件M2 每小时 0.1 千件需要 300 小时按每天 8 小时算是 37.5 个工作日5 月的工作日历根本装不下机盖 YY-JG 需要 30 千件M2 同样是 0.1 千件的节拍一样装不下M1 总装 30 千件每小时 5 千件6 小时就能干完毫无压力。这张倒推表最有价值的地方在于它给了一个明确的预期M2 必然出现能力不足例外。如果跑完计划例外汇总里干干净净那一定是资源或工艺路线没配对而不是计划算得好。核对项手算预期系统应表现对不上时先查电池采购建议30 千件到货早于 5/2 三天采购申请日期正确提前期、来源规则机身产能需 300 小时5 月装不下出现能力不足例外资源单位用量、班次机盖产能需 300 小时5 月装不下出现能力不足例外同上总装产能6 小时充裕无能力例外单位用量 0.2需求总量30 千台供需明细合计 30 千冲减设置、组织范围答辩环节最常被问的三个问题其实都能用这套倒推逻辑回答。问“你怎么知道计划是对的”答手算锚点和系统结果一致问“产能冲突怎么处理”答非能力约束下先看例外定位瓶颈再切能力约束看延误影响问“多工厂协同怎么体现”答 M1 的机盖来源是传送自 M2计划员工作台里能顺着供应反查到具体需求。提示验收时把导出的供需明细 Excel 和手算表放在一页里对照比十张界面截图更有说服力。从那以后我每次做计划类测试都会在点运行之前先把倒推表算出来贴在旁边跑完第一件事是对表而不是看界面。这个习惯救过我很多次也让我在评审现场少说了不少“应该是……吧”。希望帮到你。本文还有配套的精品资源点击获取