Oracle EBS MRP模块要不要测、怎么测、测到哪些算到位一直是个容易被低估的问题。很多人觉得MRP不就是跑一个并发请求出一堆计划订单结果一上线就被一堆“该订没订”“不该订乱订”的反馈搞得焦头烂额。这篇文章就是我当时做MRP模块测试时的完整记录从场景设计、数据准备、实操步骤到踩坑后的排查思路尽量还原我自己的处理过程希望对正在准备做EBS MRP测试的朋友有帮助。1. 测MRP前先把它在EBS里的定位捋清楚1.1 MRP在制造流程里的承上启下作用如果去翻Oracle EBS制造业模块的官方文档MRPMaterial Requirements Planning物料需求计划是Manufacturing计划体系里的核心引擎。我习惯把它理解成“翻译器”和“分拣员”翻译器是把销售预测、销售订单这些独立需求结合BOM结构逐层展开翻译成对应原材料、半成品、成品的相关需求分拣员则是把每一个物料的毛需求、库存可用量、在途订单、安全库存这些信息汇总在一起判断到底缺什么、缺多少、什么时候必须下单。MRP本质上是MPS的延伸MPS管的是关键成品或选定的重要物料的计划MRP则把从MPS得到的成品计划结果连同独立需求一并展开到所有下层物料。在EBS里这两个模块通常会一起启用单独跑MRP但没跑MPS也可以——只要你在物料主数据里把计划方法Planning Method设置为MRP系统就会考虑。1.2 这次测试的范围和核心目标我当时负责的测试范围很明确验证MRP能否按照设定的计划参数准确生成自制件计划订单和采购件计划订单并且计划日期能正确反映制造提前期和采购提前期。具体包括下面几类验证点物料主数据上的计划参数订货策略、固定批量、提前期、安全库存是否被MRP正确引用。BOM是否按照多层结构逐层展开需求。工艺路线上的提前期是否在计划日期计算中被考虑。现有量、在途采购单、在制工单、销售订单、预测等供需信息是否被准确纳入计划计算。计划订单、计划例外信息、供需明细查询是否准确反映计划结果。测试的意义不在于所有参数都用一个标准的“推荐值”而在于搞清楚里面的逻辑链。我见过不少项目把MRP模块当成一个简单的“跑批工具”参数设置得很随意结果上线后一跑计划各种不可能完成的任务订单满天飞。MRP测试的重点其实就是回答三个问题需求的来源对不对、供给的计算对不对、计划日期算得准不准。2. 测试场景的设计决定了这个模块能不能真正扛住业务2.1 按“需求来源-计划策略-物料层级”三个维度拆解场景矩阵MRP的测试场景不能随便拍脑袋我是按“需求来源×计划策略×物料层级”来拆解的。需求来源包括销售订单Sales Order、独立预测Forecast、MPS计划结果、安全库存补库需求。计划策略重点看物料主数据里的订货策略批次对批次Lot-for-Lot每批都需要单独下单、固定批量Fixed Lot、再订货点Min-Max Planning这三类最常用。物料层级则分为成品层、半成品层、采购原料层。这三个维度组合起来就会形成一套覆盖主要业务规则的测试矩阵。例如场景1成品有销售订单需求物料计划方法为MRP订货策略为批次对批次BOM一层采购原料。场景2成品有独立预测需求通过MPS运行后产生计划订单再通过MRP把需求传导到下层原料。场景3某个原料设置了最小最大订货策略Min-Max验证安全库存触发的补货逻辑。场景4某个采购件已存在在途PO和在制工单验证MRP计算净需求时会不会正确冲减。场景5成品BOM包含多个半成品层验证多层展开后相关需求的汇总、批量、提前期偏移。你只需要把工厂里实际用的物料策略整理出来映射到这些场景里就行。我通常建议对每一个场景至少跑三次不同数据状态这样才能把“计算逻辑稳定”和“恰好一次算对”区分开来。2.2 物料主数据和BOM数据准备的两个干净口子MRP测试最怕的就是拿着生产环境的乱数据来定位问题——除了找自己一身麻烦很难判断到底是计划参数错了还是主数据本身脏。我自己的习惯是单独建一套测试组织或者在测试环境里把需要的物料、BOM、工艺路线单独建一遍。这样做的好处是一切可追溯跑错了可以快速在测试数据里定位。物料主数据上需要确认的字段Oracle EBS里主要在Inventory组织层的MRP计划和MPS计划相关界面设置主要包括计划方法建议把要跑MRP的物料设置为MRP关键成品设置为MPS不需要参与计划的设置为Not Planned。订货策略按业务实际情况来比如批量制造件常用批次对批次采购件如果供应商有起订量就设固定批量。固定批量大小设置后在MRP计算时会作为下单量取整依据。提前期采购件设置采购提前期自制件设置制造提前期包含工艺路线中工序时间换算出来的制造提前期这部分同时受物料主数据里的制造提前期和工艺路线具体工序提前期影响。安全库存按物料的重要程度设置固定安全库存量或基于服务水平的动态安全库存。计划时间栏Planning Time Fence这一项很容易被忽略但如果设置不好会导致计划订单频繁被系统手上的计划建议打乱。BOM和工艺路线方面要特别注意版本生效时间EBS里BOM和Routing都受Effectivity日期控制。测试前要把BOM生效日期、工艺路线生效日期与计划时间对齐否则会出现“逻辑对但结果完全不对”的情况。工艺路线里每个工序的工序提前期Per Lot OperationPPO和单件提前期Per Unit OperationPUO也需要注意因为MRP计算制造提前期会参考这些字段。有一个常见误解物料主数据里也有提前期BOM/工艺路线里也有提前期两者到底以哪个为准EBS默认在MRP计算时自制件的提前期用物料主数据上的固定的制造提前期而不是工艺路线的工序累计。但是当“工艺路线”作为提前期来源在相关参数中被启用的版本差异就需要仔细核对当前生效日期内的工艺路线累计提前期。我当时跑测试时用的是这样一个顺序先确认物料主数据上的制造提前期设置为固定值再单独在工艺路线界面跑一次“提前期汇总”功能把系统计算的制造提前期拿来做比对。这个环节能提前发现90%的计划日期计算异常问题。还有一个必须检查的点物料组织层级里的“ROP/PE”参数再订货点/计划例外参数是否激活因为如果物料同时启用了库存再订货点计划方法又被MRP跑需求叠加后容易产生多余的计划订单。3. 真正跑一次MRP计划的完整过程参数不是随便选的3.1 跑计划前的检查清单按这个顺序过一遍在运行MRP计划前我建议按下面的顺序做一遍数据检查避免跑到一半才发现第一层就把需求搞错了当前库存现有量是否与库存模块的库存快照一致如果启用了包含在途库存还要确认在途采购、在途转移OQ是否纳入供给计算。所有计划物料是否都在“MPS/MRP计划”界面设置了正确的计划方法、订货策略是否存在未发放的销售订单、预测条目它们是否被正确纳入需求时界BOM是否全部生效是否存在BOM失效但物料还在计划的情况采购申请、采购订单、工单是否处于“已核准”状态MRP在计算时需求方和供给方的一个重要判断依据就是单据状态。比如一张采购申请如果处于“待审批”状态MRP在默认设置下不会将其视为实际供应同理工单如果是“未发放”状态也会导致供给看不到。这类状态性问题测试阶段必须提前在数据准备时统一处理不然排查起来极其耗时。3.2 提交并发请求计划名、计划范围、计划方式怎么搭配EBS运行MRP计划是在“Manufacturing / MPS-MRP / 计划”里面提交MRP计划请求。这里有几个容易混淆的参数计划名Plan Name如果还没建计划需要先去“计划名”窗口创建。计划名决定了MRP是在哪个计划上下文中运行的也可以把它理解成一套独立的计划数据存放容器。计划范围Scope是运行这个计划名下的所有物料还是指定的类别Category内的物料我建议测试阶段用类别控制比如建一个“MRP_TEST”的类别把测试物料挂上去避免把无关的物料混进来。计划模式Schedule Mode是执行“重新计划”还是“增量计划”还是“只做净量更改”。我测试时绝大多数场景用的是“重新计划”因为这样才能保证计算结果能完整复现。增量模式在补跑只处理最近有变动的那部分数据定位问题时反而容易懵。“是否包含预测消耗规则/预测展开规则”这种参数这些不是必定要勾选但如果你测试的物料接入了预测消耗Demand Time Fence、消耗期间、消耗比例这些参数不一起测上线后会漏掉一大块需求逻辑。提交请求后系统会生成一个并发请求编号Concurrent Request ID在“查看请求”里可以看到运行日志。我一般会同时打开“MRP计划日志”和“MRP计划异常报表”两个输出。前者会列出系统运行时的关键步骤和警告后者会列出计划中产生的例外信息——这两个文件对定位问题非常关键不要只去看计划订单界面。3.3 计划结果怎么看计划订单、例外信息、供需查询MRP跑完后优先需要检查的界面主要有三类计划订单Planned Orders。它包含订单类型采购申请/工单、数量、建议日期、需求追溯Pegging。如果某个计划订单的需求追溯是空的说明它的需求不是来自实际的销售订单或BOM相关需求就要警惕是不是预测或安全库存触发的。例外信息Exception Message。例如缺料短缺、建议取消、建议延期、建议提前等。例外信息不是错误它只是告诉你“系统认为这个计划动作需要关注”。测试阶段重点看有没有大量“建议取消”或“建议延期”——如果有往往代表你的输入参数如批量、提前期设置不合理而不是MRP算错。供需明细查询Supply/Demand Detail。输入物料号可以展开看到这个物料所有参与计算的供给和需求。只要你把销售订单条件、预测条件、工单、PO、现有量逐条核对就能验证MRP计算是否正确。我自己验证计算逻辑时最笨也最有效的方法拿一款典型物料把它在“供需查询”里的所有行都导出来然后在Excel里按净需求毛需求-现有量-在途安全库存的逻辑重算一遍再对照MRP生成的计划订单。只要有一行对不上就说明某个单据被漏算或重复算了。这个方法虽然原始但特别能检验你对EBS MRP计算逻辑的理解。4. 实测中遇到的典型问题以及我用的排查思路4.1 计划订单数量比预期多系统把预测和销售订单重复计算了第一次跑MRP时某款物料明明只有500个销售订单需求MRP却生成了900个计划订单。一开始我怀疑是BOM展开数量不对后来逐个核对才发现问题出在预测和销售订单双算——当时选中了预测Forecast作为需求源但物料也同时存在未消耗的预测条目和实际销售订单MRP默认把两者都纳入了毛需求。这个需求双算是实际项目中特别常见的情况并不一定是系统配置错误更常见的是预测消耗规则没配对。EBS中处理预测与销售订单的关系主要靠消耗规则Consumption Rule如果没做消耗预测和订单就会同时计入需求。我后续测试中对有预测需求的物料统一检查是否启用了预测消耗、消耗周期是否合理、预测条目是否在职。消耗规则的一句话解释当市场上真订单实际发生系统会自动把预测的量消耗掉一部分从而避免双算。4.2 计划订单生成时间不对所有物料按固定提前期管理没有体现工艺路线的工序时间第二个比较头大的问题是不少自制件产生的计划订单计划开工日期提前天数都不对。后来检查发现物料主数据上的“制造提前期”设置成了通用固定值。这样EBS计算时不会去展开工艺路线各工序时间。如果企业实际是多工序、工序之间有等待时间和传送时间这种简化处理会导致开工日期偏晚或偏早。我的处理方法是在测试环境里给不同类别物料建立标准的工艺流程然后跑“工艺路线提前期汇总”功能计算每款物料真正的制造提前期再更新到物料主数据上。如果EBS版本支持自动提前期来源选择结合工艺路线和时间码来获取也可以大幅减少手工维护的工作。这里要说明一下EBS确实会同时使用物料主数据上的制造提前期和工艺路线里的工序时间但不同版本和Setup组合下来源有差别。稳妥的做法是测试阶段两种都对比跑一次以工艺路线明细为准反过来看物料主数据设置的制造提前期是否需要修正。别想当然认为“反正系统会从工序自动汇总”做得不严谨会直接被计划日期坑了。4.3 BOM变更后老计划还在根据旧BOM继续展开测试过程中还遇到过一个问题BOM被调整了但MRP跑完之后仍然按旧的BOM结构生成下层物料需求。后来查看MRP计划参数发现“BOM展开日期”没有设置为最新日期。MRP在展开需求时是以“计划运行日期”为基准然后按照BOM的有效日期范围取对应的BOM版本。如果改了BOM但没维护好生效日期或者运行MRP时选择的计划日期早于新版BOM生效日期系统就使用旧版本。这个问题的判断逻辑不复杂但从问题表象到根因排查比较费时。后续我在测试规范里加了一条每次BOM变更后重新运行MRP前先从“物料明细”界面查询该物料在当前计划日期下的BOM展开版本确认是预期的那一版再继续。4.4 其他几个常见问题的排查速查表我在测试过程中攒了一个小的排查表每次遇到异常就按图索骥效率会高很多异常现象优先排查方向常见根因计划订单完全没生成需求来源是否到位、物料计划方法是否为MRP、计划范围是否包含该物料物料被设成了Not Planned或预测/订单未生效计划订单数量偏大预测与销售订单是否重复计算、是否存在未关订单预测消耗规则未正确设置计划订单日期偏差物料主数据上的提前期与工艺路线提前期是否一致制造/采购提前期参数不匹配下层原料需求不在计划里BOM展开日期、替代物料关系、是否为通用件BOM版本失效或替代关系设置不当重复计划订单是否有多个计划名在对同一物料循环运行计划名隔离不彻底多计划名重复运行例外信息量巨大批量规则和计划时间栏是否正确订货策略设置不合理或计划时间栏过短4.5 排查问题时的数据核对技巧排查MRP异常有一个绝大多数时候都能帮你快速收敛问题的功能供需追溯Pegging。在“计划订单”界面可以直接查看某张计划订单是由哪一条需求触发的。每一个计划订单上面的Pegging显示了它的数据来源可能是某张销售订单行、预测条目、相关需求的半成品计划订单或安全库存。如果Pegging是空那就要想想需求是不是真的在系统里存在。我在测试中遇到的大部分“系统算错了”最终都是在Pegging这一步发现是需求源本身的数据问题MRP本身没有错。另一个我很常用的小技巧在Excel里维护一张“核心物料测试预期结果表”每一行记录物料号、场景描述、需求日期、需求数量、现有量、在途量、安全库存、批量规则、预期计划订单数量、预期计划订单日期。跑完MRP后直接用SQL把计划订单数据拉出来和预期表做VLOOKUP。这样做至少有两点好处第一是发现问题的时间大幅缩短不需要人工一屏一屏翻界面第二是后续写测试报告时直接就有了一份数据佐证材料。4.6 一个容易被忽略的问题工艺路线主数据对提前期计算的干扰前面提到了工艺路线的提前期问题这里单独展开说因为这是很多测试新人最容易忽略、也最容易“咬死”的地方。EBS的MRP计算制造件提前期时不同项目因为Setup差异有的版本会直接参考物料主数据里的“制造提前期”有的项目希望按照工艺路线各工序时间累加。问题就出在如果物料主数据的提前期没维护系统不会自己“报错”它可能会按0提前期或默认值继续算最终生成一个明显不合理的计划开工日期。我在测试过程中遇到过一个典型案例一款加工件在BOM下面有原料需求但该加工件的计划开工日期比计划完工日期只提前了1天。查看工艺路线后发现该物料有6道工序累计需要8天。为什么MRP只给了1天原因是物料主数据里的制造提前期被设置成了1天MRP只根据这个字段做了日期倒排。后面我在工艺路线界面用“提前期汇总”功能重新计算后把结果更新到物料主数据再跑一次计划计划日期才恢复正常。4.7 日期类型的坑需求日期与计划日期之间差了一整天这里多说一句日期处理上的细节。EBS里MRP是按天为粒度来计算如果你在测试时发现计划订单的日期比预期晚了一天先别急着认为是系统Bug。EBS的时间栏逻辑里订单的下达日期通常是需求日期往前倒推提前期天数得到的但这里又涉及“是否包含起始日”的问题。比如需求日期是第30天、提前期是3天计划订单日期到底是27天还是28天不同版本/参数设置下结果会有差异需要针对功能设置确认清楚。我后来在测试中明确了组织层参数EBS默认是不算起始日的也就是说需求是30日、提前期3天计划订单日期是28日30日往前倒推3天为28日。如果你做业务验证时按27日来预期自然会对不上。这个细节也提醒我们别光靠“我想当然”来预期结果系统功能有它自己的日历约定和计算规则不清楚就去查试。5. 测试收尾要留的三样东西能省后面上线阶段很多事5.1 把每个场景的预期结果和实际结果固化成对照表既然做了MRP测试就不要只停留在“我跑过了”这种程度上。我建议在测试报告里附上场景对照表对每一个场景明确写明前置条件、参数配置、预期计划订单、实际计划订单、差异分析、是否通过。这样即使三个月后有人问“当时这个逻辑是怎么验证的”你也能直接拿报告给他看不需要重新跑一遍回忆。我自己维护的MRP测试用例表里每一行还会有“SQL查询语句”和“对应查询界面路径”两列专门记录当时是从哪个界面或者哪个SQL里拿到验证数据的。这个习惯帮我省了非常多重复查询的时间。5.2 跑批参数记录表尤其是计划名和计划方式的组合MRP并发请求的参数组合直接影响计算结果。我在测试过程中专门维护了一张“计划运行参数记录表”记录每次跑批时间、计划名、计划方式、是否勾选预测展开、是否包含所有库存、计划创建人和备注。出现异常时可以直接看到是哪一次跑批出的问题。如果多个顾问或实施同事同时操作测试环境就更要记录清楚否则同一版数据被不同参数跑过再回头定位时简直无法复原。5.3 数据修正脚本备份方便重复回归测试过程中我写过不少数据修正SQL包括批量更新物料主数据提前期、批量设置预测消耗规则标记、批量修正计划订单状态。这些脚本我都按照“场景名称修改内容时间”进行归档。在回归测试时要复现相同前置条件直接执行脚本就能把环境恢复到指定状态。但要注意正式环境跑前SQL脚本必须经DBA评审并备份不能直接在正式环境复用测试环境脚本。6. 一些想法MRP测试最关键的是理解逻辑链MRP模块测试做到最后你会发现技术操作其实不复杂真正有难度的是理解整条逻辑链从销售订单/预测进入系统的那一刻开始到MRP计划结果输出的那一刻为止中间经历了需求收集、净需求计算、批量取整、提前期倒排、例外信息判定等多个环节。任何一个环节的参数设置错误都会导致计划结果和业务预期之间出现偏差。我在这个项目的实操体会是不要在MRP模块测试时只做“点按钮”级别的事。点按钮只是验证“系统能跑”。真正的测试价值在于在业务顾问、计划员、采购人员介入之前你先用数据证明“这套参数组合下生成的结果是符合业务的”。所以测试之前一定要把业务规则搞清楚然后再把它翻译成系统参数。测试过程中所有计算结果都用Excel或SQL做过交叉验证而不是简单地“看到有计划订单就认为通过了”。我后来在给团队做MRP测试培训时经常打一个比方MRP计划就像是一个仓库管理员拿到了一百张小票需求他去货架上看一遍库存看看路上还有多少货在补在途然后算出还需要进多少、什么时候进。如果你给他的小票本身数据是乱的或者货架上的库存记录是脏的那这个管理员离职了换谁都算不对。MRP不是“算得神奇”它的核心能力是规则确定、流程稳定、结果可追溯而测试就是验证这三件事的过程。这篇记录的很多内容不是教科书教出来的而是在一个个异常数据、一张张异常计划订单里磨出来的。如果你正准备做EBS MRP模块的测试我希望这篇记录能帮你少走一些弯路。如果你已经在测的过程中卡在了某些数据逻辑上可以顺着上面提到的“需求双算”、“提前期来源”、“BOM版本选择”这几个方向先自查大概率会有所收获。