简介这份文档面向Oracle EBS ERP实施顾问、供应链计划人员及ASCP初学者围绕高级计划排程模块的方案设置与测试流程展开帮助读者理解从物料定义到供应链计划执行的完整链路。资源包内含1个doc文件约1.43MB以图文步骤形式记录ASCP测试全过程便于对照系统界面逐步操作。文档以YY手机有限公司为案例背景覆盖物料定义与组织分配、BOM与工艺路线、来源规则与分配清单、MDS定义、供应链计划定义与运行以及计划下达、采购、生产、入库、发运等执行环节并配有具体物料编码、提前期与需求预测数据。目前已有1945人学习适合需要系统掌握ASCP设置逻辑、复盘测试步骤或准备相关认证与项目实施的读者参考。1. ASCP 方案设置测试到底在测什么从一次计划跑偏说起车间排产会上计划员拍着桌子说系统建议的开工日期比实际采购提前期还早三天采购说物料根本到不了两边僵住。翻出 Oracle EBS 里 ASCPAdvanced Supply Chain Planning的方案设置一看问题不在算法在测试文档里漏掉了一条「计划例外」的阈值配置。这类场景在制造业供应链里太常见了ASCP 跑出来的计划看着漂亮落地就翻车。ASCP 方案设置测试文档本质是把「计划引擎怎么算、按什么约束算、算完怎么验证」这三件事写成可复现的检查清单。它解决的不是功能有没有而是配置对不对、数据准不准、结果能不能信。适合谁正在做 EBS 供应链模块实施、准备上线 ASCP、或者接手别人留下的计划方案、被「计划不准」反复折磨的从业者。这篇不聊概念聊怎么把一份 ASCP 测试文档从纸面变成能跑通、能排错、能交接的东西。2. ASCP 方案设置的核心对象与测试前置条件2.1 方案、计划与实例三个容易混的概念在 EBS 里说「ASCP 方案」实际涉及三层对象。最上层是Plan计划比如「M1 主生产计划」「周滚动补货计划」它定义了计划范围、计划选项、计划 horizon。中间层是Plan Options计划选项控制计划引擎的行为是否考虑能力约束、是否启用分配、是否做 pegging、例外集用哪个。最底层是Instance / Source Instance实例与源实例决定计划从哪个组织、哪个业务实体取数。测试文档如果只写「配置计划选项」实施顾问换个人就不知道到底改了哪几个 tab。我一般要求测试用例里把路径写死Supply Chain Planning Plans Names进入具体计划后Plan Options里逐 tab 截图或记录。常见做法是建一个专门的测试计划命名带_TEST后缀避免污染生产计划。2.2 测试前必须锁定的四类基础数据ASCP 跑不准八成是基础数据的问题不是方案设置的问题。测试文档里必须有一节专门核对数据就绪度我通常按这四类查数据类别关键检查点常见问题物料主数据计划物料标志、提前期、安全库存提前期单位是天还是工作日没统一物料清单 BOM生效日期、替代料、组件产出率BOM 循环导致计划挂起工艺路线 Routing资源、工序提前期、班次资源产能未维护能力计划全为零供应商与采购采购提前期、最小订购量、供应商日历供应商日历与工厂日历冲突核对方式可以用后台查询比如查计划物料是否都勾了「Planable」-- 查询指定组织下未标记为可计划的物料 SELECT msi.segment1 AS item_code, msi.description, msi.planning_make_buy_code FROM mtl_system_items_b msi WHERE msi.organization_id :org_id AND msi.planning_make_buy_code IS NULL AND msi.inventory_item_status_code Active;这段 SQL 的逻辑是在指定组织内找出还在启用状态、但没有维护「计划制造/采购」代码的物料。planning_make_buy_code为空意味着 ASCP 不知道这个物料是该做还是该买计划引擎会直接跳过或报例外。参数:org_id要替换成实际组织 ID测试文档里应记录每个参与计划的组织 ID避免用错组织跑测试。2.3 测试环境与职责分工测试文档不是一个人写的。方案设置测试至少涉及三类角色计划管理员负责配置计划选项和跑计划数据管理员负责基础数据核对业务代表负责确认计划结果是否符合实际。文档里要明确谁在什么阶段做什么否则测试会变成「顾问自己跑一遍说没问题」。环境上我坚持在 CRPConference Room Pilot或独立测试实例上做不在生产实例直接改计划选项。测试实例的 ASCP 并发管理器要确认已启动否则计划提交后一直挂起新手容易以为是配置问题。检查并发管理器状态# 在应用服务器上查看 ASCP 相关并发管理器进程 ps -ef | grep -i fnd | grep -i concurrent # 或通过 EBS 界面System Administrator Concurrent Manager Administer命令含义是列出应用层与并发管理相关的进程。如果看不到FNDLIBR或FNDSM相关进程说明并发管理器没起来计划根本不会执行。这一步在测试文档里应作为「环境就绪检查」的第一条比配置检查更靠前。3. 从零跑通一次 ASCP 计划配置、提交与结果验证3.1 计划选项里必须逐项确认的参数进入Plan Options后tab 很多但测试文档不需要全测聚焦影响计划结果的核心项。我一般按这个顺序过Main tab计划类型MRP / DRP / MPS、计划 horizon、计划组织。计划 horizon 太短会导致远期需求看不到太长会拖慢运行。测试时建议先用 30 天 horizon 跑通再扩到实际周期。Constraints tab是否考虑物料和能力约束。如果勾了「Enforce Capacity Constraints」但资源产能没维护计划会大量报「能力不足」例外。测试文档要记录勾选状态和对应基础数据是否就绪。Pegging tab是否启用 peggingpegging 级别是 end assembly 还是 full pegging。启用 full pegging 后计划运行时间明显变长但能追溯需求来源。测试时先关掉跑通后再开对比运行时间和结果差异。Exception Set tab选择例外集。默认例外集可能包含几十条例外测试文档要列出哪些例外是「必须处理」、哪些是「可忽略」。比如「Late Supply」必须看「Excess Inventory」在测试阶段可以先忽略。3.2 提交计划的两种方式与参数差异方式一界面提交。Supply Chain Planning Plans Launch选择计划、选择「Snapshot」或「Live」模式。Snapshot 模式基于快照数据跑速度快适合测试Live 模式取实时数据慢但准。测试文档建议先用 Snapshot 验证配置再用 Live 验证数据。方式二并发请求提交。通过Submit Request找到「Plan Launch」请求参数里填计划名和模式。这种方式适合批量或定时跑。测试文档里应记录请求名称和参数组合方便复现。提交后查看计划结果Supply Chain Planning Plans Workbench。Workbench 里能看到计划订单、例外、pegging。测试文档要定义「通过标准」比如计划订单数量与独立需求偏差不超过 5%关键物料没有「No Supply」例外。3.3 用查询验证计划结果是否合理界面看结果直观但批量验证要靠查询。ASCP 的计划结果存在msc_开头的表里比如msc_supplies、msc_demands、msc_plan_orders。测试文档里可以放几条验证 SQL-- 查询指定计划中所有计划订单及其建议日期 SELECT po.plan_order_id, po.item_name, po.order_type, po.suggested_due_date, po.quantity, po.supplier_name FROM msc_plan_orders po WHERE po.plan_id :plan_id AND po.order_type IN (Planned Order, Purchase Requisition) ORDER BY po.suggested_due_date;逻辑说明从计划订单表里取出指定计划的所有计划订单按建议日期排序。order_type过滤出计划订单和采购申请排除已确认的工单。参数:plan_id是计划运行后生成的内部 ID可以在msc_plans表里根据计划名查到。测试文档里应记录如何获取plan_id否则这条 SQL 没法直接用。再比如验证例外-- 统计指定计划中各类例外的数量 SELECT me.exception_type, COUNT(*) AS exception_count FROM msc_exceptions me WHERE me.plan_id :plan_id GROUP BY me.exception_type ORDER BY exception_count DESC;这条查询帮测试人员快速判断计划质量。如果「Late Supply」例外特别多说明供应提前期或需求日期有问题如果「No Supply」多说明物料没来源。测试文档里应给每个例外类型写一句「出现后先查什么」比如 Late Supply 先查供应商日历和采购提前期。3.4 计划结果与业务预期的比对方法跑通计划不等于计划可用。测试文档最后一步是业务比对挑几个关键物料手工算一遍净需求和 ASCP 结果对。手工算法期初库存 在途 计划订单 - 独立需求 - 相关需求 预计可用。如果对不上先查单位、日期、损耗率。我一般让计划员挑 5 个物料做手工比对覆盖一个采购件、一个制造件、一个有替代料的、一个有过期库存的、一个需求波动大的。比对结果记在测试文档的「验证记录」表里签字确认。这一步看着笨但能挡住大部分「系统跑出来不对」的扯皮。4. ASCP 测试中最容易翻车的五个配置点4.1 计划 horizon 与需求日期错位现象计划跑完某些销售订单的需求没出现在计划里。原因计划 horizon 的起始日期晚于需求日期或者需求日期在 horizon 之外。ASCP 默认从「当前日期」开始但如果有 backdated 需求就会被漏掉。解决在 Plan Options 里把 horizon 起始日期往前调覆盖最早的需求日期。测试文档里应记录「最早需求日期」的检查步骤查msc_demands里demand_date的最小值。4.2 组织访问权限导致数据取不到现象计划跑完某个组织的物料完全没有计划订单。原因计划选项里没有把该组织加入「计划组织」列表或者职责没有该组织的访问权限。解决检查Plan Options Organizations确认所有参与计划的组织都已勾选。同时检查职责的「组织访问」设置。测试文档里应列出所有参与组织及其 ID逐项核对。4.3 例外集选错导致关键例外被隐藏现象计划结果看起来正常但上线后发现大量缺料。原因测试时用的例外集没有包含「No Supply」或「Late Supply」或者例外阈值设得太宽松。解决测试文档里明确指定例外集名称并列出必须启用的例外类型。常见做法是复制一份默认例外集命名为ASCP_TEST_EXC把关键例外的阈值调紧。4.4 快照数据过期导致计划失真现象Snapshot 模式跑出来的计划和 Live 模式差异很大。原因快照没有及时刷新取的是几天前的数据。解决测试文档里写清楚快照刷新步骤Supply Chain Planning Snapshots Refresh并记录刷新时间。如果测试周期长每天跑计划前先刷新快照。4.5 并发管理器冲突导致计划挂起现象计划提交后状态一直是「Pending」或「Running」几小时不动。原因ASCP 的并发管理器没有启动或者并发管理器被其他请求占满。解决检查System Administrator Concurrent Manager Administer确认 ASCP 相关的管理器状态为「Active」。如果被占满可以临时提高工作进程数或错峰跑计划。测试文档里应记录并发管理器的正常状态截图方便对比。5. 把测试文档变成可复用的回归清单测试文档写完不是归档是下次改配置时的后悔药。我习惯把每次测试的「配置快照 验证 SQL 例外基线」存成一个回归包。配置快照用Plan Options的导出功能或者直接查msc_plan_options表存成 CSV。验证 SQL 按计划 ID 参数化下次改个 ID 就能跑。例外基线是这次测试中各类例外的数量下次跑完对比数量突增就说明配置或数据变了。-- 导出指定计划的关键选项配置用于回归对比 SELECT mpo.plan_id, mpo.option_name, mpo.option_value FROM msc_plan_options mpo WHERE mpo.plan_id :plan_id ORDER BY mpo.option_name;这条查询把计划选项拉成两列方便和上次的 CSV 做 diff。参数:plan_id换成当前计划 ID。测试文档里应记录每次回归的日期和计划 ID形成时间线。进阶一点可以把验证 SQL 包成一个脚本用 SQL*Plus 或 Python 定时跑输出例外数量到日志。Python 连接 Oracle 用cx_Oracle或oracledb测试文档里可以放一段最小示例import oracledb # 连接测试库注意不要在生产库上跑批量查询 conn oracledb.connect(userapps, password****, dsntestdb:1521/TEST) cur conn.cursor() plan_id 123456 # 替换为实际计划 ID cur.execute( SELECT exception_type, COUNT(*) FROM msc_exceptions WHERE plan_id :pid GROUP BY exception_type , pidplan_id) for row in cur: print(f{row[0]}: {row[1]}) cur.close() conn.close()逻辑说明连接测试库按计划 ID 统计例外数量并打印。dsn格式是主机:端口/服务名测试文档里应记录测试库的连接串但不要写生产库密码。这段脚本可以扩展成每天跑一次把结果追加到日志文件形成例外趋势。我自己的习惯是每次改完 ASCP 方案设置先跑回归脚本对比例外基线再让计划员看关键物料。如果例外数量在基线 ±10% 以内基本可以认为配置没引入新问题。这个习惯帮我挡过好几次「改了一个参数导致全厂计划偏移」的事故。希望帮到你。本文还有配套的精品资源点击获取