Oracle EBS ASCP 方案设置测试文档编写与结果验证实战

简介这份文档面向Oracle EBS供应链与计划模块的实施顾问、运维人员及ERP学习者聚焦ASCP高级计划排程的方案设置与测试流程帮助读者理解从物料定义到计划执行的完整链路。资源以YY手机公司为案例背景覆盖物料分配、BOM与工艺路线、来源规则与分配清单、MDS定义、供应链计划运行及计划下达、采购、生产、入库、发运等环节可作为ASCP模块的实操参考与测试模板。压缩包内共1个doc文件约1.43MB内容为完整的方案设置与测试记录结构按测试背景、主要步骤、详细过程与结论组织便于按章节查阅。目前已有1945人学习下载适合需要梳理ASCP配置逻辑、对照案例复现测试流程的读者参考使用。1. ASCP 方案设置测试文档到底在测什么从一次计划跑偏说起很多做过 Oracle EBS 的人都有过这种经历ASCPAdvanced Supply Chain Planning里计划跑出来一堆建议采购说数量不对计划员说日期不对最后追到方案Plan设置上发现是某个 Profile 或者计划选项没配对。ASCP 方案设置测试文档本质上就是把「一个计划方案从建到跑通、再到结果可信」这件事拆成可重复执行的验证步骤让下一次建方案不用靠玄学。它解决的不是「ASCP 怎么装」而是「方案建好之后我怎么证明它算得对」。适合三类人刚接手 ASCP 模块的 EBS 顾问、负责计划结果校验的计划员、以及要做 ASCP 上线或迁移测试的实施人员。这篇不讲抽象概念按我实际做测试文档的顺序从方案定义、数据准备、计划选项、运行验证一路写到结果比对中间该贴 SQL 的地方贴 SQL该列参数的地方列表格。2. 方案定义与组织架构先把测试边界框死ASCP 方案设置最容易翻车的地方不是某个选项不会填而是测试范围没框清楚。一个 Plan 关联的组织、物料、来源规则一旦铺得太开跑一次计划几小时出了问题根本不知道从哪查。所以测试文档的第一步永远是定义「这个方案管哪些组织、哪些物料、哪些来源」。2.1 方案类型选型MPS、MRP、DRP 到底测哪个ASCP 里常见的计划类型有 MPS主生产计划、MRP物料需求计划、DRP分销需求计划还有 SOP 和 Production Plan。测试文档要写清楚本次测的是哪一类因为不同类型的计划选项、来源规则、冲减逻辑都不一样。我一般按这个判断如果测试目标是「成品层面的独立需求怎么驱动生产」选 MPS如果是「所有层级物料的需求展开和采购建议」选 MRP如果是「多组织之间的调拨和补货」选 DRP。测试文档里要明确写出计划类型并说明为什么选它否则后面结果对不上时没人能判断是设置错了还是类型选错了。方案定义界面在 ASCP 的 Plan Names 里关键字段包括 Plan Type、Source Instance、Source Plan如果是复制方案、Organization List。Organization List 是测试边界的第一道闸门建议测试阶段只挂 1 到 2 个组织不要一上来就全公司。2.2 组织与来源实例的绑定检查组织挂进方案之后还要确认来源实例Source Instance指向的是不是当前测试环境。这一步经常被忽略尤其是从生产克隆环境做测试时来源实例可能还指着生产导致计划跑出来用的是生产数据。可以用下面这段 SQL 查方案和组织绑定关系确认测试环境里的 Plan 挂的组织和来源实例是否正确-- 查询 ASCP 方案与组织、来源实例的绑定关系 SELECT p.plan_id, p.plan_name, p.plan_type, p.source_instance_id, o.organization_id, o.organization_code FROM msc_plans p, msc_plan_organizations o WHERE p.plan_id o.plan_id AND p.plan_name plan_name -- 替换为测试方案名 ORDER BY o.organization_code;逻辑说明msc_plans是方案主表msc_plan_organizations是方案与组织的关联表。source_instance_id对应来源实例测试环境里应该指向本地实例。参数plan_name是方案名跑之前先确认方案名拼写ASCP 方案名大小写敏感。如果查出来组织数量比预期多或者source_instance_id不是测试实例先别往下跑计划回去改方案定义。这一步省下来的时间比后面排查计划结果快得多。2.3 物料和来源规则的范围确认组织框好之后物料范围也要框。ASCP 不会自动只算你关心的物料它会按组织下的所有有效物料展开。测试阶段建议用物料分类或者 Planner 字段做过滤把范围缩到可验证的几十个物料。来源规则Sourcing Rules和领用规则Bill of Distribution决定了需求怎么在组织间传递。测试文档里要列出本次测试涉及的来源规则名称和分配清单并确认这些规则在测试组织下是有效的。常见做法是先在 ASCP 的 Sourcing Rules 界面查一遍再用 SQL 核对分配比例和优先级-- 查询来源规则分配明细确认测试组织下的优先级和比例 SELECT sr.sourcing_rule_name, sra.organization_id, sra.source_organization_id, sra.allocation_percent, sra.rank FROM msc_sourcing_rules sr, msc_sourcing_rule_assignments sra WHERE sr.sourcing_rule_id sra.sourcing_rule_id AND sr.sourcing_rule_name rule_name ORDER BY sra.rank;参数说明allocation_percent是分配比例rank是优先级数字越小优先级越高。测试时要确认这些值和测试用例里预期的一致否则计划跑出来的建议来源会和你预期的不一样。3. 计划选项与 Profile 设置决定计划算得对不对方案定义只是框了范围真正决定计划怎么算的是计划选项Plan Options和 Profile 设置。这一章是测试文档的核心也是最容易漏项的地方。我一般把计划选项分成三类来测需求冲减类、计划运算类、输出控制类。3.1 需求冲减与预测控制测试用例怎么设计需求冲减Demand Consumption决定了销售订单和预测之间怎么冲减。ASCP 里有多种冲减方式比如按物料、按客户、按日期窗口。测试文档要针对每种冲减方式设计用例比如「同一物料同一日期有预测和销售订单跑完计划后预测剩余量应该是多少」。关键计划选项包括Consume Forecast、Consumption Window、Consumption Method。我一般会在测试文档里列一个用例表把输入和预期输出写清楚用例编号物料预测数量销售订单数量冲减窗口预期预测剩余TC-01ITEM-A100307 天70TC-02ITEM-A1001207 天0TC-03ITEM-B50503 天0这张表的作用是计划跑完之后直接拿结果和预期比不用凭感觉判断。测试文档里每个用例都要写清楚对应的计划选项值否则复现不了。3.2 Profile 选项MSC 相关 Profile 的检查清单ASCP 很多行为受 Profile 控制比如是否启用多组织、是否考虑在途、是否自动释放建议。测试文档里要列出本次测试依赖的 Profile 及其值。常见需要确认的 Profile 包括MSC: Enable Multi-Org PlanningMSC: Consider In-Transit InventoryMSC: Auto Release Plan RecommendationsMSC: Planning Time FenceMSC: Demand Time Fence可以用下面这段 SQL 查当前环境下的 MSC Profile 值确认和测试文档里写的一致-- 查询 MSC 相关 Profile 当前值 SELECT profile_option_name, profile_option_value FROM fnd_profile_option_values v, fnd_profile_options o WHERE v.profile_option_id o.profile_option_id AND o.profile_option_name LIKE MSC% AND v.level_id 10001 -- Site 层 ORDER BY o.profile_option_name;逻辑说明level_id 10001表示 Site 层ASCP 的 Profile 通常在 Site 层设置。如果查出来的值和测试文档预期不一致先改 Profile 再跑计划否则结果没有可比性。参数MSC%是模糊匹配如果只想看特定 Profile把 LIKE 条件改精确。3.3 计划运算参数时间栏、计划 horizon 和异常集计划运算类选项决定了计划跑多远、跑多细。关键参数包括 Plan Horizon、Planning Time Fence、Demand Time Fence、Exception Set。测试文档里要写清楚每个参数的值和设置理由。Plan Horizon 决定计划覆盖的天数测试阶段建议设短一点比如 30 到 60 天方便快速验证。Planning Time Fence 内的需求不会被自动调整测试时要确认这个天数是否覆盖了测试用例的日期范围。Exception Set 决定计划跑完后报哪些异常测试文档里要列出本次关注的异常类型比如「迟到订单」「过量供应」。我一般会在测试文档里加一个参数快照表把方案跑之前的参数值记下来跑完之后再对比。这样如果结果不对能快速判断是不是参数被改了。4. 计划运行与结果验证从提交到比对的完整链路方案设置好之后就是跑计划、看结果。这一步的测试文档要写清楚怎么提交、怎么监控、怎么取结果、怎么比对。很多人测试文档写到「提交计划」就停了结果验证部分一笔带过导致文档没法复现。4.1 提交计划并监控运行状态ASCP 计划可以通过界面提交也可以用并发请求提交。测试文档里建议写清楚提交路径和并发程序名。提交之后要监控运行状态常见状态包括 Pending、Running、Completed、Error。可以用下面这段 SQL 查计划运行状态和并发请求-- 查询 ASCP 计划运行状态 SELECT p.plan_name, r.request_id, r.phase_code, r.status_code, r.actual_start_date, r.actual_completion_date FROM msc_plans p, fnd_concurrent_requests r WHERE p.plan_id r.request_id -- 部分版本通过 request_id 关联 AND p.plan_name plan_name ORDER BY r.actual_start_date DESC;逻辑说明phase_code和status_code反映并发请求状态actual_start_date和actual_completion_date用来判断计划跑了多久。如果状态是 Error要去查并发程序的日志常见原因是来源实例连不上或者组织没挂对。参数plan_name替换成测试方案名。注意不同 EBS 版本里msc_plans和fnd_concurrent_requests的关联字段可能不同如果查不出数据先用 request_id 直接查并发请求表。4.2 计划结果取数用 SQL 验证供应和需求计划跑完之后结果存在 ASCP 的结果表里比如msc_supplies、msc_demands、msc_plan_entries。测试文档里要写清楚取哪些表、按什么条件过滤、和什么预期比。下面这段 SQL 查某个物料在测试方案下的供应和需求-- 查询测试方案下指定物料的供应和需求 SELECT SUPPLY AS entry_type, supply_id AS entry_id, item_id, quantity, new_schedule_date FROM msc_supplies WHERE plan_id plan_id AND item_id item_id UNION ALL SELECT DEMAND AS entry_type, demand_id AS entry_id, item_id, quantity, new_schedule_date FROM msc_demands WHERE plan_id plan_id AND item_id item_id ORDER BY new_schedule_date;逻辑说明msc_supplies和msc_demands是 ASCP 的核心结果表plan_id是方案 IDitem_id是物料 ID。new_schedule_date是计划建议日期测试时重点看这个日期和数量是否符合预期。参数plan_id和item_id需要替换成实际值plan_id可以从msc_plans表查。如果查出来的供应需求数量和测试用例预期不一致先别急着改方案回去检查需求冲减和来源规则大部分偏差都出在这两个地方。4.3 结果比对计划建议和预期用例的对照方法结果比对是测试文档的收尾环节。我一般会把 SQL 查出来的结果导出到 Excel和测试用例表逐条对照。对照的维度包括建议类型采购、生产、调拨、数量、日期、来源组织。比对时要注意ASCP 的计划建议可能有多条比如同一个物料既有采购建议又有调拨建议测试用例里要写清楚预期的是哪一种。如果结果里出现了用例没覆盖的建议类型说明方案范围没框干净回去检查物料和来源规则。测试文档里建议加一个「偏差记录」表把每条不一致的记录写下来包括预期值、实际值、初步原因。这个表是后续调方案和回归测试的依据。5. 避坑与常见问题ASCP 方案测试里最容易翻车的几个点ASCP 方案设置测试的坑很多不是技术难题而是流程和习惯问题。下面这几条是我实际做测试文档时踩过的按「现象 → 原因 → 解决」写出来供参考。现象计划跑完没有任何建议。原因方案挂的组织下没有有效物料或者来源规则没分配。 解决先查msc_plan_organizations确认组织再查msc_sourcing_rule_assignments确认来源规则。如果来源规则为空计划不会产生任何供应建议。现象计划建议的日期比预期晚很多。原因Planning Time Fence 或 Demand Time Fence 设置过大把需求推到了时间栏之后。 解决检查方案的计划选项里的时间栏值测试阶段建议设小一点比如 0 到 7 天确认日期逻辑后再调大。现象预测和销售订单没有冲减。原因Consume Forecast 选项没开或者冲减窗口设置和测试用例不匹配。 解决在计划选项里确认 Consume Forecast 为 Yes冲减窗口覆盖测试用例的日期范围。如果还是不对查msc_demands里的 demand_type确认预测和订单是否都进了计划。现象计划跑出来用的是生产数据。原因来源实例指向了生产环境或者测试环境是从生产克隆的但没改来源实例。 解决查msc_plans.source_instance_id确认指向测试实例。如果是克隆环境需要在 ASCP 里重新设置来源实例。现象计划运行状态一直是 Pending。原因并发管理器没启动或者计划提交后卡在队列里。 解决检查并发管理器的状态确认 ASCP 相关的并发程序有可用的管理器。如果是测试环境常见原因是并发管理器没随数据库启动。6. 把测试文档变成可回归的资产参数快照和自动化比对测试文档写完一次不难难的是下次改方案之后还能快速回归。我的习惯是把测试文档里的参数快照和结果比对做成可重复执行的脚本每次改完方案跑一遍几分钟就能看出有没有回归。具体做法是把方案定义、计划选项、Profile 值、来源规则这些参数用 SQL 查出来存成快照表每次测试前跑一次和基线快照对比。结果比对部分把测试用例的预期值也存成表用 SQL 做全外连接直接输出偏差记录。下面这段 SQL 是一个简化的偏差比对示例把预期表和实际结果表做对比-- 预期结果和实际计划结果的偏差比对 SELECT COALESCE(e.item_id, a.item_id) AS item_id, e.expected_qty, a.actual_qty, CASE WHEN e.expected_qty IS NULL THEN 实际多出 WHEN a.actual_qty IS NULL THEN 实际缺失 WHEN e.expected_qty a.actual_qty THEN 数量不符 ELSE 一致 END AS diff_type FROM test_expected_results e FULL OUTER JOIN test_actual_results a ON e.item_id a.item_id AND e.plan_id a.plan_id WHERE NVL(e.expected_qty, -1) NVL(a.actual_qty, -1) OR e.expected_qty IS NULL OR a.actual_qty IS NULL;逻辑说明test_expected_results和test_actual_results是测试文档配套的预期表和实际结果表字段包括item_id、plan_id、expected_qty、actual_qty。FULL OUTER JOIN保证预期有实际没有、实际有预期没有的记录都能查出来。NVL处理空值避免空值比较导致漏判。参数说明expected_qty和actual_qty是数量字段实际项目里可能还要加日期、来源组织等维度。这个脚本可以做成并发程序或者定时任务每次计划跑完自动执行输出偏差清单。我自己的习惯是每接手一个新 ASCP 方案先花半天把测试文档的骨架搭起来参数快照和比对脚本先跑通再往里填用例。这样后面不管方案怎么改回归测试都是几分钟的事不用每次重新翻界面。希望帮到你。本文还有配套的精品资源点击获取