企业官网建设流程全解析

简介：面向Oracle EBS高级计划排程（ASCP）实施与测试人员的实操文档，以YY手机有限公司多工厂、多分销中心的供应链为背景，完整演示了从基础数据设置到供应链计划运行、执行的全过程。资源包为单个doc文档，压缩后大小约1.43MB，内容按ASCP测试流程逐项展开，涵盖主组织物料定义与分配、BOM与工艺路线搭建、来源规则与分配清单配置、MDS需求计划定义、供应链计划创建与运行，以及计划下达后的采购、生产、入库、发运等关键环节，每一步都给出了具体操作路径和参数设置说明，例如物料复制自模板、计划方法选择MRP/MPP计划、预测控制与追溯设置等。文档以M1、M2、M3工厂和D1、D2分销中心为案例场景，详细记录了YY-JG、YY-SJ等物料的设置步骤，并介绍了计划员工作台中的供应需求查询、导出、例外汇总等实用功能。全文档结构清晰、步骤完整，适合ERP实施顾问、供应链计划员以及正在学习ASCP模块的初学者对照练习，快速理解方案配置逻辑与测试方法。该文档已有1945人学习，是一份可直接用于项目参考和内部培训的实操手册。

1. ASCP 方案设置测试到底在测什么：它和 MRP 不是同一种生物

ASCP（Advanced Supply Chain Planning，高级供应链计划）是 Oracle EBS 套件里最容易被低估、也最容易测崩的一个模块。很多从业者第一反应是「不就是多工厂版 MRP」，真把方案搭起来跑一轮才发现：它做的是受约束的供应链计划，产能、物料齐套、跨组织调拨全被当成约束条件参与运算，测试的复杂度根本不在功能按钮上，而在数据源、快照和规则之间的咬合关系。做 ASCP 方案设置测试，本质是验证三件事：同步链路通不通、计划选项配得对不对、输出结果能不能被业务解释。这篇按一线实施顺序讲，新手能照步骤建方案，熟手能直接拿去对照参数边界和排查清单。

2. 动手前先立地基：数据源、快照与计划选项的层级关系

ASCP 的方案测试容易翻车，大多不是死在计划引擎上，而是死在计划引擎读到的数据不对。所以要先把三层地基理清楚：数据源负责把 ERP 的订单、库存、BOM、工艺路线搬到高级计划区的接口表；快照负责把这些数据做成计划引擎可用的定态镜像；计划选项决定引擎在这个镜像上怎么算。三层各自独立又层层依赖，任何一层没到位，后面测试结果都谈不上准，这也是为什么我不建议一上来就创建方案——先花半天确认三层地基，比跑完一轮再倒查数据要省得多。

2.1 数据源配置：ERP 到 APS 的同步链路怎么才算通

ASCP 运行时不直接读 EBS 的现行业务表，而是通过数据收集（Data Collection）把主数据与交易数据推到 APS 接口表。常见做法是配置一个数据收集集，把需求、供应、物料、BOM、工艺路线、资源等实体纳入，再按频率或手工触发同步。做设置测试时，我一般建议收集集至少包含下面几类实体，每类都有对应的接口表和业务含义，测试时可以逐项核对行数是否合理。

验证链路通不通有两个口径。第一个是看数据收集并发请求的完成状态——请求正常结束不代表有数据，只能代表步骤执行完；第二个是直接查接口表行数和最近收集时间，这个更可靠。我通常用下面这条 SQL 同时看两个口径：

SELECT l.collection_name, MAX(l.process_date) AS last_run_date, COUNT(*) AS record_count FROM msc_appl_instances a, msc_data_collection_log l WHERE a.instance_code = l.instance_code AND l.collection_name IN ('MSC_DEMANDS', 'MSC_SUPPLIES') GROUP BY l.collection_name;

这段查询能同时看到每个实体的最近收集时间和行数。如果 last_run_date 停留在几天前，说明收集没按预期跑起来；如果行数为 0，要么是业务侧确实没有这类单据，要么是收集集里的过滤条件把目标组织滤掉了。数据源层最容易漏的恰恰是过滤条件——按组织维度过滤时漏选测试组织，表现是计划里别的组织数据正常，唯独目标组织空荡荡，这种问题在界面上极难发现，只能靠按组织拆分行数来定位。

2.2 快照机制：为什么 ASCP 不直接读 ERP 现表

ASCP 计算前需要先把接口表数据做一次快照（Snapshot），生成一个计划引擎专用的定态数据集。原因不难理解：计划运算可能跑几十分钟甚至几小时，期间 ERP 业务还在变，如果不冻结数据集，前一半计算用新库存、后一半用旧库存，结果就乱了。快照相当于给计划一个「我在这个时间点看到的供应链状态」，所有建议数量、供应归属、例外消息都基于这个时间点推导。

创建方案的界面里有一项「刷新快照」选项，常见取值有三个：仅在方案创建时快照一次、每次运行方案前自动快照、完全手工触发。做设置测试时我强烈建议选「每次运行前自动快照」，宁可多花几分钟快照时间，也别让结果基于过期镜像。快照完成后要注意一件事：方案运行结果对应的快照时间戳，必须晚于测试数据的准备时间，否则你新录入的订单根本不会被计划看到。确认快照状态的 SQL 也很简单：

SELECT plan_id, plan_name, snapshot_start_date, snapshot_complete_date, status FROM msc_plans WHERE plan_name LIKE 'TEST_ASCP%';

这条语句用来确认快照是否真正走完。snapshot_complete_date 为空且 status 长时间停在中间状态，通常是快照并发请求被后面提交的请求挤在队列里，或者是接口表有大事务锁导致快照读取被阻塞。测试规范里应该把「查快照完成时间」写成固定前置动作，而不是肉眼凭感觉。

2.3 计划选项参数：决定计划行为的关键开关

计划选项（Plan Options）是方案里最容易被复制粘贴出问题的部分，因为它参数多、默认值多、跨版本差异大。测试方案里至少要盯住三组参数。

第一组是计划时界。计划时界（Planning Time Fence）内的订单按固定供应处理，计划引擎不重排；需求时界（Demand Time Fence）内的需求强制用现有供应满足。测试时如果发现「明明有库存却不建议发货」，先去查需求时界是不是设成了全部需求都锁死。第二组是安全期与批量参数，安全库存天数、提前期偏置、最小批量会直接改动建议数量。测试用例里要写下每个物料预期的建议量，而不是只看「有没有产出建议」。第三组是约束开关：是否启用产能约束、是否考虑物料约束、是否允许多资源替代。这三个开关决定计划是无限产能还是有限产能——ASCP 的核心价值在后者，但测试初期建议先关闭约束跑一遍基线，再逐步打开，否则你无法区分结果差异是约束造成的还是数据造成的。

计划选项保存后会生成对应的计划文件，这个文件才是真正参与计算的载体。后续所有测试场景都基于这个计划文件跑，改了选项必须重新保存并重新运行，光在界面改值不保存，等于没改。这个点我在避坑章还会展开，因为它直接造成过「连续三轮测试结果完全一样」的怪现象。

3. 按这份清单建一个可测的 ASCP 方案：从创建计划到跑通首轮

方案设置测试的落地顺序，我建议按「创建计划 → 配置规则集 → 运行验证」三步走。每一步都有独立的检查点，顺序不能乱：先有方案文件，才能挂规则集；规则集挂错，运行结果就是废数据。这一章给出一份可以直接照着填的设置清单，每一项后面标了测试时要确认的内容。

3.1 创建计划：范围、组织与计划类型的选择

在 Advanced Supply Chain Planning 职责下进入 Plans 表单创建新计划。计划类型常见有 MPS 计划、MRP 计划和 SC 供应链计划，ASCP 设置测试核心用的是 SC 计划，因为只有它支持多组织与受约束的跨工厂运算。用 MPS 或 MRP 类型跑出来的结果不具备约束验证意义，这是新手最容易选错的地方。

创建界面里必填且影响测试结果的项有四个。计划名称建议用可识别的测试前缀，比如 TEST_ASCP_0218，方便一轮测完整体清理。计划范围选「整个供应链」还是「选定组织」，取决于测试目标：单组织验证选选定组织，并勾上需求组织与供应组织；跨组织测试必须同时包含需求组织、供应组织和中间仓库组织，漏掉中转组织，计划输出里就会多出采购建议而非调拨建议，这个差异后面细说。计划起始日期与截止日期构成计划时界，常见问题是把起始日期设成当天，导致当天之前的需求全部被排除出计算。还有一个容易被忽略的选项「是否包含已审批供应」，勾选后计划会冻结审批过的历史计划单；如果测试目标是验证新场景，建议不要勾，避免旧数据污染产出。

创建完成后进入计划选项表单，把上一章说的三组参数逐一填好，然后保存。保存动作会生成计划文件，这一步漏了，运行按钮就是灰的。我见过不少测试人员以为表单保存就等于方案保存，实际上两个动作在 ASCP 里是分开的，界面上的「保存」只是存参数草稿，生成计划文件才是把参数固化下来。

3.2 约束与规则设置：ATP、采购与产能怎么落进方案

方案里的约束主要靠三块设置来表达，每一块都有独立的验证方式。

第一块是 sourcing 规则。在 Sourcing Rules 表单里为物料指定供应来源优先级，例如成品 A 的供应来源第一优先是组织2 生产，第二优先是外部采购。测试时要为每个关键物料至少配一条 sourcing 规则，否则计划会直接报「无供应来源」。验证方式是查计划单建议的来源类型字段，确认建议落在第一优先来源上；如果落到了第二优先，要检查第一优先来源的提前期或产能参数是不是被设成了不可用。

第二块是产能约束。打开资源约束后，计划按工艺路线里的资源可用工时排产。测试环境里资源日历（Workday Calendar）的维护经常被忽略，导致系统可用产能和实际排班对不上。测试用例里要写明「资源本周可用 40 小时」这个预期值，跑完比对资源负载视图，才能判断约束是否生效。我习惯把资源日历的检查写成排查步骤里的第一项，因为它在界面上藏得很深，但影响又极其大。

第三块是 ATP 规则（Available to Promise）。ATP 用于可承诺量校验，启用后需求会被按规则指向特定供应来源。常见的坑是 ATP 规则没有给测试组织配对应名称，系统直接跳过 ATP 校验，输出结果看起来「过于乐观」。三块设置都落在方案引用的规则集里，创建方案时选错规则集，会出现方案跑通但建议的供应来源与业务规则完全相反的怪现象——追查半天，最后发现方案引用的是另一个测试的旧规则集版本。

3.3 运行与验证：跑完计划后先看这几个输出

运行计划在 Plans 界面点「运行」，系统提交一个并发请求。测试人员要养成的习惯是：不要只看请求结束状态，要看计划输出的关键指标。并发请求正常结束只代表计算过程没报错，不代表结果可信。

SELECT plan_id, plan_name, run_date, run_status, total_demand_count, total_supply_count, exception_count FROM msc_plans WHERE plan_name = 'TEST_ASCP_0218';

run_status 为 4 通常表示计划运行成功。exception_count 是计划引擎抛出的异常消息条数，它本身不是错误，而是计划里需要人工关注的事项，比如「需求无供应」「到期待办」「逾期订单」。真正要盯的输出有三个：计划单建议、例外消息列表、资源负载（Resource Load）。资源负载视图是最直观判断产能约束是否生效的地方——如果各资源负载集中在 90% 上下，说明约束在起作用；如果负载数据参差不齐且有资源超过 300%，大概率是资源日历没维护好，产能数据本身就是错的，先修日历再谈结果。

4. 测试执行路径：从单组织补货到跨工厂约束场景

方案建好只是开始，测试执行才是真正暴露问题的地方。ASC P 测试最忌一上来就灌全量数据跑大计划，输出几万行建议单，根本无法定位问题。正确路径是先用最小场景验证链路，再逐步叠加约束与组织范围，每层都有明确的预期输出。这一章给三个按复杂度递增的测试场景，可以直接抄作业。

4.1 最小验证场景：一张销售订单触发采购建议

测试 ASCP 最有效的方式是用最小场景验证规则联通。我常用的最小场景是：给一个外购件建一张销售订单，跑计划，预期输出一条采购建议单。场景虽小，却能一次覆盖「数据收集 → 快照 → sourcing 规则 → 生成建议」整条链路。

测试前要确认四个前置条件：物料有 sourcing 规则指向采购；库存现有量为 0 或已知；提前期参数正确；订单需求日期落在计划时界内。然后在订单表单录入销售订单，数量取 100，需求日期放在计划截止日期之前。运行计划后查建议单：

SELECT mso.order_number, msd.demand_date, mso.item_id, mso.suggested_quantity, mso.order_type, mso.supplier_id FROM msc_suggested_orders mso, msc_supply_demand msd WHERE mso.plan_id = :plan_id AND mso.demand_id = msd.demand_id AND msd.sales_order_number = 'SO-10001';

如果返回一条采购建议，数量等于订单量减去可用库存再按批量规则取整，说明链路基本通了。如果返回空结果，优先怀疑三个点：销售订单没进数据收集、快照在订单创建前就完成、sourcing 规则没生效。这个场景的价值在于能快速区分链路问题和计算逻辑问题——空结果大概率是链路问题，数量不对才是计算逻辑问题，两者排查路径完全不同，混在一起查会浪费大量时间。

4.2 跨组织场景：组织间调拨与 sourcing 规则验证

单组织场景通过后，第二个必测场景是跨组织调拨。在这个场景里，需求组织没有产能，供应组织有产能，预期输出是组织间调拨建议，而不是采购建议。验证方法直接看计划单的订单类型字段：调拨建议对应「组织间转移」类型，采购建议则对应采购类型。

配这个测试要特别留意 sourcing 规则里供应来源的类型。来源类型有生产、采购、调拨三种，如果来源类型误配成采购，计划就会建议直接采购而不是调拨，后果在真实业务里是「既买了料又多付了运费」。跨组织场景还要验证方案范围是否包含中转仓库：范围缺中转组织时，输出会多出两条独立的采购建议，而不是一段调拨加一段收料，这正是测试时要对比的预期差异。顺带要查调拨单上的供需组织编码和成本参数，成本参数配错会导致调拨建议显示负贡献，计划引擎会判定为不经济而放弃调拨，转而去采购。

4.3 结果对照：用 SQL 核对计划输出与预期

ASCP 测试和普通功能测试最大的区别在于：功能测试看界面有没有报错，ASCP 测试看数字对不对。所以结果对照阶段要建一张「预期-实际」对照表，而且预期值必须在跑计划之前填好，不能跑完再根据结果补预期，那就失去了验证意义。

SQL 核对主要用于把计划输出表的数值精确抓出来。用下面这条查询可以按物料拉出供应、需求与净数量，和对照表的预期值逐项比对：

SELECT msd.item, msd.origination_type, msd.order_type, msd.supply_quantity, msd.demand_quantity, msd.net_quantity FROM msc_supply_demand msd WHERE msd.plan_id = :plan_id AND msd.item IN ('ITEM_A', 'ITEM_B') ORDER BY msd.item;

net_quantity 的正负与数值能直接反映计划对该物料的净需求处理：正数表示多出供应，负数表示缺料。结果对照的目的是让测试结论可追溯，每条失败记录都能追到具体的参数或数据问题，而不是停留在「看起来没问题」的模糊判断上。

5. ASCP 方案测试避坑：5 个最容易翻车的点与排查

ASCP 方案测试做到第三轮以后，翻车点就高度集中在几个固定场景上。这一章把最常见、也最隐蔽的五类问题按「现象 → 原因 → 解决」写清楚，碰到同类问题可以直接按顺序排查。

5.1 现象：方案跑完，建议量却基于一周前的库存

计划结果里需求日期和数量都对，但建议量对应的库存余额明显过时，这是快照时机问题。原因是方案配置了「仅在创建时快照」，测试数据后来改了，方案运行不会重新生成快照，引擎算的是旧镜像。解决方法是把方案运行选项改成每次运行前自动刷新快照，或者在测试流程里固定加入「刷新快照」的并发请求。我习惯在测试步骤模板里把刷新快照列为运行计划的前置动作，并记录快照完成时间，确认快照时间晚于测试数据准备时间后再点运行。

5.2 现象：新录入的销售订单进了业务表，但计划里查不到

排查顺序是：先查数据收集是否把订单拉进接口表，再查收集请求是否成功，最后查快照时间。最常见的原因是数据收集集里需求实体按需求来源过滤，销售订单来源被排除在外；其次是订单需求日期落在计划时界外，被引擎自然排除。解决方法是扩大收集集的来源过滤条件，把测试组织的需求来源全部纳入，同时检查订单需求日期是否在计划起始日期之后。在测试环境更稳妥的做法是直接让计划起始日期早于测试数据的单证日期，减少时界干扰。

5.3 现象：资源负载显示超载 300%，但车间实际没这么忙

这是资源日历和产能参数的锅。工艺路线里资源的可用小时数按日历计算，如果日历没维护节假日或者班次时间，系统以为资源一周只能工作 20 小时，负载自然飙升。另一个常见原因是资源对象的计划单位和工艺路线的运行单位不一致——资源按小时计划，工序时间却按分钟写，数值直接差 60 倍。解决方法是先查资源日历的可用总工时，再查工艺路线的工序时间单位，两边对上了再打开产能约束重跑。这个坑最容易在测试环境出现，因为测试日历常常是初始化数据，没人维护。

5.4 现象：连着跑三轮测试，第二轮和第三轮结果完全一样

第一轮测试发现参数不对，改了选项重跑，结果却纹丝不动。原因多半是上一轮的计划文件没有重新生成。计划选项改动后必须重新保存并生成计划文件，很多测试人员只在界面上改了值，没走保存动作，系统一直用的是旧计划文件。解决方法是确认计划列表里的计划文件「上次更新时间」在新参数保存之后，再点运行。界面上的「运行」按钮有时调用的还是缓存里的旧文件，稳妥做法是先保存、再进入计划文件确认时间戳，最后运行。

5.5 现象：测试计划在另一个职责下看不到输出

测试人员用一个职责跑完方案，切到另一个职责查结果，发现计划列表是空的，以为数据丢了。原因是 ASCP 方案的可见性受数据访问权限集控制，职责对应的权限集没有包含测试组织，计划输出自然不可见。解决方法是给测试职责配置覆盖全部测试组织的权限集，或者直接约定用同一个职责完成运行和查看，减少权限问题导致的「结果丢失」误判。这个问题很少被写进测试文档，但遇到一次就够让人怀疑人生。

6. 把方案测试沉淀成回归习惯：基准订单集与快照比对

做完一轮 ASCP 方案设置测试，真正有价值的产出不是「这次通过了」，而是一套能反复用的回归基线。我后来在新项目里养成的习惯是：维护一个基准订单集文件，包含五个固定场景——单组织采购补货、跨组织调拨、产能受限排产、物料替代、计划时界外需求。每个场景写明输入条件和预期输出，每次方案参数调整后只跑这五个场景，就能快速判断改动有没有破坏已有行为。基准集规模不大，但覆盖面足够定位绝大多数回归问题。

配套的验证手法是快照比对。跑新参数前先记录旧方案的供应建议量和例外消息数量，跑完后做增量对比，用集合差直接把两个方案输出之间的差异行抓出来：

SELECT item, order_type, suggested_quantity FROM msc_suggested_orders WHERE plan_id = :old_plan_id MINUS SELECT item, order_type, suggested_quantity FROM msc_suggested_orders WHERE plan_id = :new_plan_id;

这条语句列出旧方案有而新方案没有的建议行，方向反过来再跑一次就能得到双向差异。回归时用这个办法扫差异，比逐单核对快得多。新方案如果只是预期内的参数微调，差异应该只集中在目标物料上；如果差异扩散到无关物料，说明存在隐藏的参数联动，需要回头查计划选项里的级联关系。

我踩过最大的坑是自信地认为「我没改那个选项，结果变化和我无关」，后来发现计划选项里有几个参数存在级联保存，一次保存会同时影响多个约束开关。从那以后我每次都保留前后两版方案文件的快照时间戳和输出行数，再下结论。这一套习惯做下来，ASCP 方案测试从「每次重头查数据」变成了「每次只查差异」，效率提升非常明显，也希望这套办法能帮到你少走弯路。

本文还有配套的精品资源，点击获取