简介面向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 不是同一种生物ASCPAdvanced Supply Chain Planning高级供应链计划是 Oracle EBS 套件里最容易被低估、也最容易测崩的一个模块。很多从业者第一反应是「不就是多工厂版 MRP」真把方案搭起来跑一轮才发现它做的是受约束的供应链计划产能、物料齐套、跨组织调拨全被当成约束条件参与运算测试的复杂度根本不在功能按钮上而在数据源、快照和规则之间的咬合关系。做 ASCP 方案设置测试本质是验证三件事同步链路通不通、计划选项配得对不对、输出结果能不能被业务解释。这篇按一线实施顺序讲新手能照步骤建方案熟手能直接拿去对照参数边界和排查清单。2. 动手前先立地基数据源、快照与计划选项的层级关系ASCP 的方案测试容易翻车大多不是死在计划引擎上而是死在计划引擎读到的数据不对。所以要先把三层地基理清楚数据源负责把 ERP 的订单、库存、BOM、工艺路线搬到高级计划区的接口表快照负责把这些数据做成计划引擎可用的定态镜像计划选项决定引擎在这个镜像上怎么算。三层各自独立又层层依赖任何一层没到位后面测试结果都谈不上准这也是为什么我不建议一上来就创建方案——先花半天确认三层地基比跑完一轮再倒查数据要省得多。2.1 数据源配置ERP 到 APS 的同步链路怎么才算通ASCP 运行时不直接读 EBS 的现行业务表而是通过数据收集Data Collection把主数据与交易数据推到 APS 接口表。常见做法是配置一个数据收集集把需求、供应、物料、BOM、工艺路线、资源等实体纳入再按频率或手工触发同步。做设置测试时我一般建议收集集至少包含下面几类实体每类都有对应的接口表和业务含义测试时可以逐项核对行数是否合理。数据实体接口表业务含义物料主数据MSC_ITEMS计划涉及的物料、属性、批次规则销售订单需求MSC_DEMANDS外部需求来源订单行与预测库存与供应MSC_SUPPLIES现有量、在制、采购在途、计划单BOM / 工艺路线MSC_BOMS / MSC_ROUTINGS结构关系、工序资源、替代关系验证链路通不通有两个口径。第一个是看数据收集并发请求的完成状态——请求正常结束不代表有数据只能代表步骤执行完第二个是直接查接口表行数和最近收集时间这个更可靠。我通常用下面这条 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 测试看数字对不对。所以结果对照阶段要建一张「预期-实际」对照表而且预期值必须在跑计划之前填好不能跑完再根据结果补预期那就失去了验证意义。测试场景输入条件预期输出实际观察判定单组织采购补货销售订单 100 件采购建议 100 件采购建议 100 件通过跨组织调拨需求 50 件调拨建议 50 件采购建议 50 件失败产能约束排产资源可用 40 小时建议量减半建议量不变失败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 方案测试从「每次重头查数据」变成了「每次只查差异」效率提升非常明显也希望这套办法能帮到你少走弯路。本文还有配套的精品资源点击获取
简介面向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 不是同一种生物ASCPAdvanced Supply Chain Planning高级供应链计划是 Oracle EBS 套件里最容易被低估、也最容易测崩的一个模块。很多从业者第一反应是「不就是多工厂版 MRP」真把方案搭起来跑一轮才发现它做的是受约束的供应链计划产能、物料齐套、跨组织调拨全被当成约束条件参与运算测试的复杂度根本不在功能按钮上而在数据源、快照和规则之间的咬合关系。做 ASCP 方案设置测试本质是验证三件事同步链路通不通、计划选项配得对不对、输出结果能不能被业务解释。这篇按一线实施顺序讲新手能照步骤建方案熟手能直接拿去对照参数边界和排查清单。2. 动手前先立地基数据源、快照与计划选项的层级关系ASCP 的方案测试容易翻车大多不是死在计划引擎上而是死在计划引擎读到的数据不对。所以要先把三层地基理清楚数据源负责把 ERP 的订单、库存、BOM、工艺路线搬到高级计划区的接口表快照负责把这些数据做成计划引擎可用的定态镜像计划选项决定引擎在这个镜像上怎么算。三层各自独立又层层依赖任何一层没到位后面测试结果都谈不上准这也是为什么我不建议一上来就创建方案——先花半天确认三层地基比跑完一轮再倒查数据要省得多。2.1 数据源配置ERP 到 APS 的同步链路怎么才算通ASCP 运行时不直接读 EBS 的现行业务表而是通过数据收集Data Collection把主数据与交易数据推到 APS 接口表。常见做法是配置一个数据收集集把需求、供应、物料、BOM、工艺路线、资源等实体纳入再按频率或手工触发同步。做设置测试时我一般建议收集集至少包含下面几类实体每类都有对应的接口表和业务含义测试时可以逐项核对行数是否合理。数据实体接口表业务含义物料主数据MSC_ITEMS计划涉及的物料、属性、批次规则销售订单需求MSC_DEMANDS外部需求来源订单行与预测库存与供应MSC_SUPPLIES现有量、在制、采购在途、计划单BOM / 工艺路线MSC_BOMS / MSC_ROUTINGS结构关系、工序资源、替代关系验证链路通不通有两个口径。第一个是看数据收集并发请求的完成状态——请求正常结束不代表有数据只能代表步骤执行完第二个是直接查接口表行数和最近收集时间这个更可靠。我通常用下面这条 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 测试看数字对不对。所以结果对照阶段要建一张「预期-实际」对照表而且预期值必须在跑计划之前填好不能跑完再根据结果补预期那就失去了验证意义。测试场景输入条件预期输出实际观察判定单组织采购补货销售订单 100 件采购建议 100 件采购建议 100 件通过跨组织调拨需求 50 件调拨建议 50 件采购建议 50 件失败产能约束排产资源可用 40 小时建议量减半建议量不变失败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 方案测试从「每次重头查数据」变成了「每次只查差异」效率提升非常明显也希望这套办法能帮到你少走弯路。本文还有配套的精品资源点击获取
