SAP可用性检查：静态/动态逻辑、检查组配置与复现排查

简介面向SAP顾问、供应链与物料计划人员及ERP学习者这份文档围绕可用性检查的应用测试展开重点厘清IM层面的静态检查与MRP层面的动态检查在库存、预计划收货发货及预留处理上的差异。文中结合配置路径、检查规则与预留、采购订单、补货提前期等场景记录测试过程并给出动态检查下可用库存计算与报错判断的示例便于读者理解校验逻辑、排查库存不足提示并复用到实际配置验证中。资源包仅含1个docx文件大小约536KB轻量便于随查随用目前已有3063人学习下载适合作为SAP可用性检查入门梳理与操作对照的参考材料。1. 一条「20 对 30」的报错SAP可用性检查到底在拦什么库房里明明躺着 100PC系统却告诉你 2020-06-20 这天不能用 30PC只能给 20PC。第一次碰到这种提示的人十有八九会去查库存查完发现库存没问题然后开始怀疑人生。这就是 SAP可用性检查最容易被误解的地方它拦的从来不是「库存够不够」而是「到那个需求日期为止算上所有已经压在时间轴上的单据之后还够不够」。这份测试文档把两条完全不同的逻辑摆在了一起。一条是静态检查MIGO 用 201 发 105PC库存 100PC系统立刻提示缺 5 个不需要任何后台配置另一条是动态检查走 MRP 视角把在途、质检、冻结、采购订单、预留、独立需求统统拉进来算一遍还要看检查规则和检查组的配置。同一句「物料不可用」背后可能是两套完全不同的算术。适合正在做 MM/SD 模块、准备上线前跑一遍可用性检查用例的人也适合被「有库存却报不可用」折腾过、想搞清楚那个检查组到底在哪生效的人。下面按配置链路到前台复现的顺序拆开。2. 静态与动态的边界两套算法各自把什么算进来先把两种检查的分界线划清楚后面配置才不会配错地方。静态检查是「此时此刻」的算术动态检查是「到需求日期为止」的算术两者触发的入口、读取的数据源、能改的参数完全不在一个层面上。2.1 静态检查触发在哪一步上限又在哪静态检查跑在 IM 层面文档里那个例子很典型1000 工厂 A001 库存地点有 100PC通过 MIGO 做 201 移动类型向成本中心发料 105PC系统直接拦下提示还差 5 个。整个过程中没有任何后台配置参与也不需要物料主数据上挂什么检查组系统只做一件事——拿非限制使用库存和这次移动的数量做减法减出来是负数就报错。这个「不需要配置」的特性很多人误读成「静态检查不受控制」。实际上它是受控的控制点在移动类型上。哪些移动类型走检查、哪些不走是移动类型的配置决定的201、261 这类消耗性移动通常带检查标识而很多收货类、转储类移动不带。所以生产上偶尔会看到「同样是发料A 事务报错 B 事务不报」八成是两个移动类型的检查标识不一样跟库存本身没关系。静态检查的边界也很明确它只看当下的库存采购订单在途的 50PC 它当不存在明天要发的 80PC 它也当不存在。所以它适合拦住「账上不够还硬发」这种低级错误拦不住「账上够但三天后会被别的订单吃光」这种计划性问题。文档把这一层叫「IM 层面的检查」用词是准确的。还有一个经常被忽略的点静态检查看的是库存地点级别的可用量。同一个物料在 A001 有 100PC、在 A002 有 0PC你在 A002 发料依然会报错系统不会自动跨库存地点调拨。要跨地点那是库存转移或者 MRP 层面的事不是检查规则能解决的。2.2 动态检查把 17 类要素卷进来之后会发生什么动态检查走 MRP 层面文档把它拆成两大块库存侧和计划侧。库存侧列了六类——安全库存、在途库存、质检库存、冻结库存、非限制使用库存、外包库存。这六类不是全都算「可用」的非限制使用库存当然算质检库存和冻结库存默认不算除非检查规则里明确放行安全库存是底线通常被扣掉在途库存在到货日之前也不算。这一点如果没搞明白就会反复出现「明明有 200PC 却说不够」的困惑。计划侧列了十一类收货和需求采购订单、采购申请、相关需求、预留、独立需求、SD 提货单、货运通知单、基于订单的预留、库存传输订单、计划订单、生产订单。这些单据只要在系统里存在并且状态、日期、工厂对得上就会被拉进这次计算。文档里那句「非常值得注意的是4 跟 8 的差异」是整个测试文档里最有含金量的一句话。第 4 项是手工预留人在 MB21 里敲出来的需求日期、数量都是人定的改起来自由第 8 项是基于订单的预留由生产订单、销售订单自动带出来数量跟着订单走改需求日期等于改订单日期。这两者在可用量计算里权重一样但可维护性完全不同。测试用例里步骤 2、步骤 4、步骤 5 用的都是手工预留单 19所以可以把需求日期在 06-20 和 06-26 之间来回挪换成生产订单带出来的预留这么挪就得先去改订单。这个差异在实际业务里会变成排查方向的分岔口发现可用量被吃掉了先在 MD04 里看是手工预留还是订单预留前者找计划员问后者找订单源头改。2.3 一份文档里的五个步骤其实是一条时间线文档的测试设计不复杂但顺序是有讲究的——先立库存再压需求再补收货最后用两个不同日期的需求去撞边界。把它摊成表更清楚步骤日期动作数量系统反馈关键点12020-06-19查静态库存100PC正常基线后续全部围绕它算22020-06-21建预留单 1980PC正常手工预留日期可自由调整32020-06-25建采购订单50PC正常到货日由预计交货日期带出42020-06-20再建预留30PC报错100-8020 3052020-06-26再建预留30PC通过100-805070 30补2020-06-26勾「不含补货提前期」后重建需求30PC报错同一日期、同一数量结果反转这张表最有价值的地方不是那五个数字而是最后一行同样的日期、同样的数量只改一个勾选项结论就从通过变报错。这说明动态检查的结果不是库存的函数是「库存 配置」的函数。测试文档如果只记录前五行这份文档基本没用把第六行记下来它才具备回归测试的价值。顺带说一句步骤 4 的日期是 06-20比步骤 2 的 06-21 还早但系统依然把 06-21 那笔 80 的预留扣掉了。这说明文档采用的算法是「已存在的需求不分先后全部参与加总」而不是严格的逐日 ATP 累计。这个细节决定了你复现时如果拿 CO09 去对数字可能对不上——这件事在第 4 章会专门讲。3. 配置链路复现从移动类型一路走到物料主数据配置这条线文档只给了四个标题移动类型、检查规则、定义检查规则、事务代码。信息量不大但顺序是对的。真要在一个空系统里复现出来缺一步都不行。3.1 移动类型上的检查开关决定静态检查生不生效移动类型的配置入口是 OMJJ进去之后找对应的事务码和移动类型组合。这里有个很容易踩的坑同一个移动类型 201在不同的事务码下可以有不同的配置比如 MB1A 和 MIGO 走的是同一套还是不同套取决于系统版本和配置方式。所以复现的时候不要只看「201 有没有勾检查」要看「我从哪个事务码进去做 201」。这一步的价值在于它解释了为什么有些发料会被拦、有些不会。文档里 201 发 105PC 被拦是因为该移动类型带检查标识如果你换一个不带标识的移动类型做同样的发料系统会安静地让你过库存变成负数也不一定报错。这不是系统 bug是配置本来就这么设计的。配置完成之后不要急着去测动态检查先用一个简单的 201 超量发料验证静态检查是否生效。这一步验证成本极低几十秒的事但能排除掉后面一大半的干扰因素。3.2 检查规则和检查组是两层别配反了这里是整份文档最需要说清楚、但原文只给了标题的地方。检查规则Checking Rule回答的是「查什么」库存移动要不要查、收货要不要查、发货要不要查、库存转储要不要查、预留要不要查。它是一组开关按业务类型逐项打开或关闭。检查组Checking Group回答的是「用哪套参数查」它挂一组检查规则同时带一批计算参数比如是否考虑补货提前期、是否考虑安全库存、收货需求怎么处理。顺序是先有检查规则再有检查组最后把检查组分配到物料主数据的 MRP3 视图「可用性检查」字段上。分配错了前面配得再漂亮也不会生效。我的习惯是配完之后立刻回物料主数据看一眼那个字段是不是真的填上了。这个字段在新建物料时经常被漏填尤其是从别的物料复制过来的复制模板里如果没有值新物料就是空的然后所有检查静默失效——不报错、不提示只是不检查。这种「静默失效」比报错难查十倍。至于事务代码OVZ2、OVZ9 这几个在不同版本里指向的节点名略有出入我一般直接在 SPRO 的搜索框里敲 availability check落到哪个节点就用哪个比记事务码稳。复制现有检查组再改也比从零新建省事但复制会带来源头的检查规则改完记得回头核对一遍。3.3 那三个灰掉的参数是被上层锁住的文档里唯一加了「此处注意」的地方就是新建或复制检查组时「总计销售 A」「总交货需求 A」「冻结需求传默认勾选」这三处改不动是灰的。很多人第一反应是权限问题去查角色、查授权对象查半天没结果。真正的原因在层级上检查组的这三个参数由它挂靠的检查规则决定或者说由系统对该业务类型的固定处理逻辑决定不是检查组自己能改的字段。要改得回到检查规则那一层或者改源检查组再重新复制。这条注意事项在文档里只占一行但它省下的是半小时的权限排查时间。类似的「字段灰掉」在 SAP 配置里很常见判断方法也统一先看这个字段是不是从上层带过来的再去上层找。3.4 物料主数据上的两个字段才是真正的开关回到测试物料 G0120030两个字段决定了整条链路能不能跑通。第一个是 MRP3 视图的「可用性检查」填上面定义的检查组。这个字段为空后面所有的测试都会「通过」——因为压根没检查。第二个是计划交货时间 6 天这个值参与补货提前期的推算也是步骤 5 能通过、补充测试会报错的根本原因。这个字段通常在采购视图或者 MRP2 视图里不同物料类型放的位置不完全一样。6 天这个数字不是随便填的它必须小于「需求日期 - 当前日期」的差值否则测试根本撞不到边界。文档选的 06-26 距离基线 06-19 正好 7 天比 6 天多 1 天这个「刚好越线」的设计是有意的。配置到这里就算齐了。接下来是前台数据也是最容易在复现时翻车的一段。4. 前台数据模拟把 6 天补货提前期跑成一条时间线前台这一步文档给了五个步骤加一个补充测试但没给中间过程的截图和解释。照着做很容易出现「我这儿怎么没报错」或者「我这儿怎么一开始就报错」的情况。原因通常在数据准备阶段就埋下了。4.1 先把算式写死再去系统里对在动系统之前我习惯先用几行脚本把文档里的算式跑一遍。这样做的好处是系统给出的结果和脚本不一致时你能立刻判断是配置错了还是数据错了而不是对着屏幕猜。from datetime import date, timedelta # 物料 G0120030 的计划交货时间等价于补货提前期 RLT_DAYS 6 OPENING_STOCK 100 # 2020-06-19 的非限制使用库存 # 单据池需求为负收货为正 DOCS [ {name: 预留19, date: date(2020, 6, 21), qty: -80}, {name: PO50, date: date(2020, 6, 25), qty: 50}, ] def available(target: date, strict_rlt: bool) - int: 按文档现象反推的可用量算式。 strict_rltTrue 对应勾选『不含补货提前期』的严格模式。 qty OPENING_STOCK for d in DOCS: if d[qty] 0: # 需求侧文档的算法是不分日期先后已存在的需求全量计入 qty d[qty] else: # 收货侧严格模式下货必须在「需求日 - 补货提前期」之前到 limit target - timedelta(daysRLT_DAYS) if strict_rlt else target if d[date] limit: qty d[qty] return qty print(available(date(2020, 6, 20), False)) # 20小于 30报错 print(available(date(2020, 6, 26), False)) # 70大于 30通过 print(available(date(2020, 6, 26), True)) # 20小于 30报错这段脚本的关键参数只有三个OPENING_STOCK是基线库存RLT_DAYS是补货提前期strict_rlt对应那个勾选项。需求侧的加总用的是「全量计入」这是从文档现象反推出来的——步骤 4 的需求日是 06-20却把 06-21 的 80 扣掉了只能这么解释。收货侧用的是「到货日与需求日的比较」严格模式下还要再往前推 6 天。要提醒的是这是按文档现象反推的算式不是系统源码。真实系统里 ATP 的逐日累计逻辑更细同一个场景用 CO09 看出来的数字可能和这里不完全一致。脚本的用途是帮你快速判断「差在哪一侧」不是替代系统结果。4.2 步骤 1 到 3把基线、需求、收货按顺序压上去库存这一步没什么好说的06-19 这天 100PC 非限制使用库存确认的时候顺手看一眼有没有质检库存和冻结库存混在里面因为这两类默认不参与可用量计算如果物料主数据上有个 20PC 的质检库存你的基线其实是 100 而不是 120后面的算法全要改。建预留单走 MB21单号 19需求日期 06-21数量 80。建完之后不要急着建下一张先去 MD04 看一眼这个物料的需求清单确认这 80 挂在 06-21 那一行上。这一步的价值在于排除「预留建到了别的工厂或别的库存地点」这种情况——预留单上的工厂、库存地点、需求日期三个字段错一个可用量都不会被吃掉。建采购订单走 ME21N数量 50交货日期系统会根据物料的计划交货时间自动带出来落在 06-25。这里也有个细节如果物料主数据上没有维护计划交货时间或者供应商主数据上的计划交货时间覆盖了物料的值带出来的日期就不是 06-25后面的边界就撞不上了。所以建完 PO 之后同样要回 MD04 确认收货行落在哪一天。这三步做完时间轴上应该是100 的存量-80 在 06-2150 在 06-25。用 4.1 的脚本算任何日期的可用量都是 100-8020因为需求全量计入收货在严格模式下不一定算得进来。这个中间状态很重要它是后面两个测试的共同起点。4.3 步骤 4为什么 06-20 的 30 一定会红再建一张预留需求日期 06-20数量 30系统报错。按脚本算可用量是 100-802020 30报错是必然的。这里真正值得琢磨的是06-20 比 06-21 早一天为什么系统会把一天之后的需求提前扣掉答案在 2.3 里提过——动态检查不是按天逐笔滚动的流水账它更接近「把时间轴上所有已知的进出加总看净值够不够」。所以在它眼里06-20 和 06-21 只差一天都在「未来」这个筐里一起算。这个特性带来一个实际影响需求日期的先后顺序在动态检查里不影响计算结果影响结果的是「这笔需求有没有进系统」。这跟很多人的直觉相反——直觉上早的需求应该优先满足晚的需求应该排在后面。系统不这么看系统看的是总量。如果业务上确实需要按优先级区分那要靠需求优先级、需求类别或者别的机制去做不是靠改日期。报错信息里通常会给出可用量和需求量的对比如果没有就去 CO09 看这个物料在这个日期的汇总可用量。这两处数字对不上说明检查规则里某一类单据被排除在外了回头查 3.2 那组开关。4.4 步骤 506-26 为什么又绿了补货提前期在这里做了什么同样的 30PC需求日期改到 06-26系统放行。按脚本算100-80507070 30通过。差别就在那笔 50 的采购订单被算进来了。为什么 06-20 那天算不进来、06-26 就能算进来因为收货有一个「到货日」的概念06-25 到货的货不能拿来满足 06-20 的需求这在任何算法里都成立。而 06-26 在 06-25 之后逻辑上说得通。补货提前期在这里的作用是给这个判断加了一个缓冲层。物料主数据上写了 6 天意味着从下单到收货最快也要 6 天系统在做检查时会把这个时间成本考虑进去如果需求日期距离现在还很远远到足够走完一轮补货那么「现在没货」这件事就不构成障碍可以放行如果需求日期已经在补货提前期之内那就必须靠现有库存和已确认的收货来满足。这也解释了补充测试为什么结论反转勾上「不含补货提前期」之后系统不再给这个缓冲收货必须更早到才算数06-25 到的 50 在严格模式下不满足条件可用量退回 2030 的需求再次被拒。我的建议是这个开关不要凭记忆判断一定要在测试系统里把勾选和不勾选各跑一遍用 CO09 把两次的可用量截图存下来。不同版本对这个开关的处理细节有差异文档里的现象在你的系统上不一定一模一样但「勾选前后结论反转」这个方向是稳的。4.5 反向验证把结论钉在证据上到这一步测试其实已经跑完了但一份能当作回归用例的文档还需要反向验证把勾选项改回去确认结论能复现把采购订单的数量从 50 改成 20确认 06-26 的需求也会被拒把预留 19 的数量从 80 改成 50确认 06-20 的需求变成可以通过。这三个反向动作各花不到两分钟但它们证明的是「结果确实由这几个变量驱动」而不是碰巧。验证过程里我习惯把 CO09 的汇总界面和 MD04 的需求清单各截一张图附在用例下面。半年后再回来看没有截图的用例基本等于废纸——你只记得「当时报错了」不记得报错时那几行数字长什么样。5. 避坑与排查五条踩过的记录这一章的五条都是复现这份文档时最容易卡住的地方。按「现象 → 原因 → 解决」写能对号入座最好。5.1 配置侧的三条现象一所有步骤都「通过」系统一次都没报错。原因是检查组没有真正挂到物料上。最常见的情况是 MRP3 视图的「可用性检查」字段为空或者填了但工厂视图没维护全。物料从别的物料复制过来时这个字段经常被带成空值。解决方式很直接MM03 看 MRP3 视图确认字段有值没有就 MM02 补上补完重新建一张预留试。如果字段有值还是不通去看检查规则里对应的业务类型比如「预留」是不是被关掉了。现象二想改「总计销售」「总交货需求」这几个参数字段是灰的。原因在 3.3 讲过这几个值由上层检查规则或系统固定逻辑决定检查组这一层改不了。解决方式是回到检查规则那一层改或者改源检查组后重新复制一份。别去查权限查不出结果。现象三静态检查该拦的时候没拦。原因通常在移动类型上该移动类型没有勾可用性检查标识或者你用的那个事务码走的是另一套移动类型配置。解决方式是 OMJJ 里核对移动类型先用一次超量 201 发料做最小验证。这一步验证成本极低建议每次配完都做一遍。5.2 数据与日期侧的两条现象四明明是按文档的日期建的预留可用量却对不上。八成是把手工预留和订单自动预留搞混了。手工预留MB21 建的对应文档清单里的第 4 项日期和数量可以随便改基于订单的预留第 8 项跟着生产订单或销售订单走改预留等于改订单。排查方法是在 MD04 里看那一行需求的来源单据类型手工预留显示的是预留单号订单预留显示的是订单号。解决方式是按来源去找对应的维护入口别在 MB22 里死磕一张根本改不动的预留。现象五同一日期、同一数量两次跑出来的结论不一样。先看「不含补货提前期」这个勾选项有没有被改动过这是最容易被忽略的变量。其次看物料的计划交货时间有没有被改过6 天和 5 天会让边界整体平移一天文档里那个「06-26 距离基线 7 天」的设计刚好卡在边缘提前期一变结论就翻。解决方式是在跑用例前把这两个值写进用例头部像记录实验条件一样记录配置状态跑完再核对一遍。6. 把这份文档变成能重跑的模板三个字段和一道复核一份测试文档的价值不在于它记录了一次结果而在于半年后别人拿着它还能复现出同样的结果。这份文档的骨架是好的——有场景、有配置路径、有五个步骤、有一个反向测试缺的是「可重跑的约束条件」。我后来把这类用例整理成一个固定模板头部只留三个字段物料号 计划交货时间、检查组名称 检查规则、基线日期 基线库存。这三个字段一确定后面的每一步结果就都是确定的。缺了任何一个用例就退化成「某人某天在某系统上看到过某个报错」没有复用价值。复核环节我一般做两件事。第一件是勾选项前后各跑一遍把两次的 CO09 截图并排放确认结论确实反转——这一步是为了证明这个开关真的在起作用而不是碰巧。第二件是把采购订单的数量从 50 改成 20 再跑一次确认 06-26 的需求从通过变成拒绝这一步证明结果确实由收货驱动不是别的原因。复核项改动预期结果证明什么补货提前期开关勾选「不含补货提前期」06-26 需求被拒开关参与判定收货数量PO 由 50 改 2006-26 需求被拒结果由收货驱动需求数量预留 19 由 80 改 5006-20 需求通过结果由存量需求驱动这三行做完这份用例才算闭合。说个自己的教训。早些年我做过一次类似的可用性检查配置测试全绿上线第二周业务反馈「有库存却下不了单」。回头查是物料主数据的可用性检查字段在批量导入时被覆盖成了空值等于所有检查静默失效测试环境那批数据是手工维护的所以没暴露。从那以后我每次配完检查组都会强制走一遍「MM03 看字段 → 建一张预留 → 看报错 → 改数量再建一张 → 看放行」这个四步循环不管多赶时间。静默失效这种东西你不主动去撞它它就一直躺着。这份文档的配置路径和测试步骤都还能用把它当成骨架把上面那三个头部字段和复核表补进去基本就能当团队的回归用例使了。希望帮到你。本文还有配套的精品资源点击获取