SAP可用性检查实战：静态动态、预留单与补货提前期排查

简介：《SAP可用性检查应用测试》是一份面向SAP实施顾问、供应链与库存管理人员的实操型文档，围绕销售订单、预留、生产订单等业务场景，梳理静态可用性检查与MRP层面动态检查的差异、配置思路及测试验证方法。压缩包共1个文件，为docx格式，约536KB，内容集中在检查规则、移动类型、可用性检查组设置，以及库存、采购订单、预留需求日期变化下的结果分析。已有3063人学习下载，适合需要理解SAP可用性检查逻辑、排查库存不足提示或完善测试案例的初中级用户参考。文档通过具体数据模拟可用库存计算过程，能帮助读者快速建立从配置到前台验证的完整思路，并对照自身系统环境设计测试步骤、定位检查结果偏差。

1. 从一条“还差 5 个”的红条说起：可用性检查到底在拦什么

仓库里明明躺着 100 个，MIGO 201 发 105 个，系统直接一条红条怼回来，说还差 5 个；可同一批料换到 MRP 视角，采购订单还在路上、预留还没发完，系统又能算出 70 个可用。这就是 SAP 可用性检查最让人上头的地方：同一个提示框，背后跑的是两套完全不同的算法。这次拆的一份测试文档，围绕预留单把 SAP 可用性检查从静态到动态、从后台配置到前台报错整条链路走了一遍，包括那个很多人配完就忘的补货提前期开关。它适合已经会建预留、会看 MRP 清单，但一遇到“明明有库存却不让我建单”就想拍桌子的顾问和关键用户，照着文档里的日期和数量走一遍，比翻十页帮助文档管用。

文档的写法很朴素：先给库存，再给需求，然后看系统怎么回话，最后把配置往回倒推。这种“先看结果、再挖配置”的顺序，恰恰是排查可用性问题时最省时间的姿势，因为可用性检查是个黑匣子，你只有先摸清它对哪几类单据敏感，才谈得上改参数。

2. 静态与动态的分野：IM 层扣料和 MRP 层冲销差在哪

把可用性检查当成一个功能去理解，很容易糊；把它当成两个独立机制去理解，思路立刻清楚。文档一上来就把这两种机制切开，这个切法是对的，因为它们在系统里既是两套逻辑，也是两个入口，配错层是最常见的翻车起点。

2.1 IM 层的静态检查：只认当下非限制使用库存

静态检查发生在库存管理层面，触发点是那些会直接减少库存的移动，比如 201 发成本中心、261 发生产订单、 goods issue 类操作。它的判定极其简单：拿你这次要发的数量，去比对库存地点里“非限制使用”的库存，够就放行，不够就报错，不关心未来有没有到货，也不关心有没有别的单据在排队等这批料。

文档举的例子很典型：1000 工厂 A001 库存地点 100 PC，201 发 105 PC，系统提示还差 5 个。这里有两个隐含前提值得记住。第一，参与比较的只是非限制使用库存，质检库存、冻结库存、寄售库存都不算；第二，检查粒度是库存地点，不是工厂，所以在 A001 不够、A002 有余的情况下，系统不会自动帮你跨地点调拨，它只管把账算清楚。

这类检查不需要任何后台配置，属于系统自带的行为，常见做法是连测试环境都不用专门准备，随便找个有库存的物料发一笔超量就能看到效果。也正因为太“自带”，很多项目上线多年都没人意识到它存在，直到某个仓库抱怨“为什么别的仓能发、我这个仓发不了”。

2.2 MRP 层动态检查：把预计划收发货一起算进来

动态检查才是有配置成本的那一半，它挂在 MRP 的视角上，答案不是“现在有没有”，而是“到你要用的那天，够不够”。所以它要把两类东西一起拉进算式。

第一类是库存口径的可用量，文档里列了六项：安全库存、在途库存、质检库存、冻结库存、非限制使用库存、外包库存。注意这里的关键不是数量，而是“算不算”。安全库存通常被视为不可动用的底线，在检查中会被扣掉；质检库存和冻结库存默认不参与，除非检查范围里明确放开；在途库存和外包库存则要看是否有对应的收货凭证支撑。

第二类是预计划的收货和发货，文档列了十一项，从采购订单、采购申请、相关需求、预留、独立需求，到 SD 提货单、货运通知单、基于订单的预留、库存传输订单、计划订单、生产订单。这一串看着杂，其实可以按方向分成两堆：采购订单、采购申请、计划订单、生产订单偏向“未来会来”；相关需求、预留、独立需求、提货单、货运通知单、库存传输订单偏向“未来要走”。动态检查做的事情，就是按需求日期把这些加减项排到时间轴上，看你这一笔新需求插进去之后，当天余额会不会变负。

真正决定结果的是“检查范围”（Scope of Check）里勾了哪些要素。同样一个物料，检查范围勾了采购订单和预留，算出来是 70；取消勾选采购订单，算出来就是 20。所以看到动态检查结果对不上，第一反应不该是怀疑系统，而是去确认这个检查组的检查范围到底放行了哪几类单据。

2.3 手工预留与订单预留：4 和 8 的差别为什么值得单独拎出来

文档特意点出“4 跟 8 的差异”，这是整份材料里最有经验含量的一句话。手工预留一般指用 MB21/MB25 这类事务码人工建的预留，需求是人工填的，数量、日期、需求方都是人拍脑袋定的；订单预留则是系统根据销售订单、生产订单等自动产生的，跟着订单的生灭走。

放在可用性检查里，这两者的差异体现在三个地方。其一，冲销时机不同，手工预留建完就占住可用量，订单预留通常跟着订单状态变化，订单改期或取消，占用量会跟着释放或挪动。其二，可信度不同，手工预留容易出现“建了不用、用完不删”的僵尸数据，把可用量长期压死，而订单预留至少和业务动作绑定，残留概率低。其三，排查路径不同，手工预留可以靠 MB25 一张张翻，订单预留要回到源订单去看状态和日期。

所以要复现一份干净的测试环境，我的习惯是先把历史手工预留清掉，只留本次造的那几条，否则测试结果永远比预期少一截，而且找不到原因。

3. 配置四步走：移动类型、检查规则、检查组怎么串起来

文档在这一段写得比较简略，只给了“配置路径：1 移动类型、2 检查规则、3 定义检查规则”三行字，还给了一句非常关键的提醒：新建或复制出来的检查组，后面“总计销售=A”“总交货需求=A”“冻结需求默认勾选”这几处是改不动的。这三行字背后的链路，值得展开说清楚。

3.1 物料、工厂、移动类型：三个挂点先理清

动态检查生效要同时满足三个挂点，缺一个就静默通过，也就是不报错、也不检查，最坑的就是这种“什么都没发生”。

三者关系可以这么记：物料说“我要检查”，移动类型说“按哪条规则检查”，检查规则说“拿哪些数据来检查”。任何一环断开，结果都是不检查。

3.2 检查组与检查规则的关系，以及那三个改不动的参数

检查组是给物料用的，检查规则是给移动用的，检查范围挂在检查规则下面。所以同一个物料在不同业务场景下可以走出不同结果，原因往往不是物料配错了，而是触发的检查规则不同。

至于那三个改不动的参数，文档的观察是对的：新建或复制检查组时，“总计销售=A”“总交货需求=A”以及“冻结需求”的默认勾选属于系统固化的标准逻辑，界面上就是灰的。这不是权限问题，也不是配置没做全，是标准程序写死的。常见做法是接受它，把差异化的诉求放到检查规则和检查范围那一层去做；真碰上标准逻辑覆盖不了的场景，才需要考虑增强，而那已经是另一个量级的工作量。

提示：看到灰色字段先别急着找权限，先在系统里复制一个已有的检查组对比一下，如果复制出来的还是一样灰，基本可以判定是标准固化，绕不过去。

3.3 一套可以照着敲的配置顺序

文档没写事务码，我按常规入口补齐，实际操作时以你系统里的菜单为准，但顺序建议照下面走，因为从下往上改会反复返工。

1. 先在检查规则里确认检查范围。用 OVZ8 一类入口进入检查规则维护，把要参与运算的要素勾上：库存类看安全库存、质检库存、冻结库存怎么处理，单据类看采购订单、采购申请、预留、相关需求是否放行。这一步决定“算什么”。
2. 再确认检查组的分配。用 OVZG 一类入口查看检查组，确认这个组下面挂了哪些检查规则，以及各规则对应的业务场景。这一步决定“谁来算”。
3. 回到移动类型配置，把检查规则填进对应移动类型的可用性检查字段。这一步决定“什么时候触发”。
4. 到物料主数据 MRP3 视图，把可用性检查组分配给测试物料，同时确认计划交货时间这个字段有值，它后面会直接影响补货提前期的判定。
5. 用一条小额预留试水，确认能触发检查，再开始造正式测试数据。

第 5 步很多人会跳，结果后面所有数据都白造。我一般会先建一条明显超量的预留，看到红条才继续往下走，这一步花两分钟，能省掉半小时的自我怀疑。

3.4 配置完成后先别急着建单

配置改完，前台不一定立刻按新逻辑走。已经打开的事务、已经存在的单据、甚至某些缓存的会话，都可能让你看到旧结果。稳妥的做法是退出当前事务重新进入，用新建单据来验证，拿旧单据反复试只会越试越乱。

另外，检查组一改，影响面是整个物料的所有相关业务，不只是你正在测的那条预留。所以在测试系统里改完记得记录改动前后的检查范围截图，等生产环境同步时照着对一遍，别凭记忆。

4. 用预留单复现测试：100 库存、80 预留、50 采购订单的推演

这份文档最有价值的部分就是这段前台推演，日期、数量、单据都给了，照着走一遍能直接看到动态检查的算数过程。测试物料是 G0120030，计划交货时间 6 天，物料主数据里分配好上面定义的那个检查组。

4.1 基线数据：先把 6 月 19 日的库存钉死

第一天只做一件事，确认 20200619 这个时点的静态库存是 100。这个数必须是干净的，也就是没有历史预留、没有未清采购订单、没有其他需求压在这批料上。常见做法是找一个新建物料，或者把测试物料的历史单据全部清理掉，否则后面每一步的差额都对不上。

“计划交货时间 6 天”这个字段在这里不是摆设，它会在补货提前期的判定里起作用。填 0 和填 6，同样的日期组合能跑出两种结果，这一点在最后补充测试里会体现得非常明显。

4.2 五步推演：从 100 掉到 20，再回到 70

把文档里的步骤整理成一张表，每一步的可用量变化都标出来，方便对照。

第 4 步是整段测试的分水岭。需求日期 20200620 早于采购订单的到货日 20200625，那 50 个在 6 月 20 日这个时点上还没到，自然不能拿来用，可用量只能是 100 减掉 80 的预留，剩 20，撑不起 30 的需求，系统报错是对的。

第 5 步换到 20200626，采购订单在 6 月 25 日已经到货，50 个可以算进来，70 撑 30 绰绰有余，通过。这两步放在一起看，说明动态检查是按需求日期逐日推演的，不是拿总数做减法，时间轴错了结论一定错。

实际排查时，光看红条不够，建议同步开 CO09 看这个物料的可用性总览，它会把你关心的日期段内每一笔收发和余额列出来。红条告诉你“不够”，CO09 告诉你“差在哪一笔”，两者配合才能定位到底是预留压多了还是采购订单日期填错了。

4.3 补货提前期那一勾：同一笔需求，两种命运

补充测试是这份文档的收尾，也是最容易被跳过的一步。同样在 20200626 建 30 的需求，把“含补货提前期”的勾去掉之后，系统直接报错，跟勾着的时候结果完全相反。

原因在于这一勾改变了系统把收货纳入检查窗口的时间基准。勾着的时候，系统会结合物料的计划交货时间，允许把补货周期内的到货提前视作可用；去掉之后，检查就变得更严格，只认那些在判定上已经站得住的收货，采购订单那 50 个在 6 月 26 日这个需求上就不被认账了，可用量退回 20，30 的需求自然过不去。

这里我不想把机制讲得太绝对，因为不同版本、不同检查范围组合下，明细行的排列会有差别。稳妥的验证方式是同一组日期跑两遍，一遍勾、一遍不勾，然后拿 CO09 的两份明细对照，看那 50 个到底落在哪一行、被算进了哪一天。自己比对出来的结论，比记别人的口诀可靠得多。

顺带说一句，这个勾不是纯技术开关，它背后是业务口径：如果企业习惯按计划交货时间做提前备货，就该勾；如果要求严格按实际到货日算，就别勾。这属于供应链策略问题，测试阶段先和业务确认清楚，别等上线后被仓库追着问“为什么昨天能建今天不能建”。

5. 避坑与排查：五个把人折腾到怀疑系统的现场

可用性检查的坑有个共同点：系统不报错，只是结果和你预期不一样。下面五条是我在类似测试里反复撞见的，按“现象、原因、解决”记下来，下次遇到能少绕两圈。

5.1 配了半天，发料根本不报错

现象：移动类型改了，检查规则也定义了，201 发超量依然顺利过账，一点提示都没有。

原因：物料主数据 MRP3 视图的“可用性检查”字段是空的，或者分配了一个不存在的检查组。物料这个挂点是源头，源头没接上，后面配得再花哨也不会触发。

解决：回到 MM03 看 MRP3 视图，确认字段有值；改完记得保存并重新进入事务，用新建单据验证，别拿改之前就打开的单据试。

5.2 会报错，但报错的时点和预期不一样

现象：明明需求日期还早，系统却提前拦住了；或者反过来，日期很紧了反而放行。

原因：触发的检查规则和你想的不是同一条。移动类型里填的规则决定了用哪套检查范围，而检查范围里对采购订单、预留、相关需求的放行程度不同，算出来的可用量自然不同。

解决：先把这次操作的移动类型对应的检查规则查出来，再逐项核对检查范围的勾选状态。改之前截图，改之后对比，别凭记忆判断哪一项动过。

5.3 配置改完，新单据还是老结果

现象：检查范围调整过了，新建预留跑出来跟改之前一模一样。

原因：会话缓存或者旧单据携带的旧逻辑在作怪，也有可能是改的根本不是这个物料所用的那个检查组，复制出来一个新的但物料还指着老的。

解决：退出事务重新进入，用全新单据验证；同时回到物料主数据确认检查组编号，别把“复制出来的组”当成“已经生效的组”。

5.4 只盯红条，不看明细，误判成系统故障

现象：红条说差 10 个，可库存明明有 100，翻了半天觉得是系统算错。

原因：可用量不等于库存量。安全库存被扣了、质检库存没放行、某条历史预留还压着、采购订单还没到货日，任何一条都能让可用量比库存少一大截。

解决：开 CO09 逐行看，把每一笔加减项和日期对一遍。这一步做完，八成以上的“系统 bug”会自己消失。

5.5 在三个灰字段上死磕

现象：想在检查组里改“总计销售=A”“总交货需求=A”或者取消冻结需求的默认勾选，发现根本点不动。

原因：这几项是标准程序固化的，不是权限也不是配置缺失。

解决：接受它，把差异化需求放到检查范围和检查规则里去做；确实覆盖不了的场景再评估增强方案，别在灰色字段上耗时间。

注意：测试环境里改检查组会影响所有引用这个组的物料，改完记得记录改动点，生产同步时逐条对照，不要只凭印象。

6. 进阶验证：把检查组当黑匣子做一轮回归

可用性检查这个功能，最怕的不是配错，是配完之后没人再验证。项目里常见的情况是上线前测过一轮，之后业务调整、物料新增、检查范围被人顺手勾了一下，没人知道，直到某天仓库发不出料才发现结果早就变了。所以我后来的习惯是，把检查组当成一个黑匣子，每次动配置就跑一轮最小回归，用固定的日期和数量组合去撞它的边界。

最小回归不用复杂，四五条就够，关键是每次都用同一套数据。

这五条跑完，基本能判断出配置有没有被动过。我一般会在测试系统里把这几条存成一份固定清单，每次改完配置照着敲一遍，用的是同一批物料、同一批日期，唯一变的是配置本身，这样结果差异才有解释力。反过来，如果每次测试都换物料换日期，出了问题根本分不清是配置变了还是数据变了，那种折腾纯属自找。

还有一个容易被忽略的点：日期一定要用相对日期去想，不要写死某一天。测试文档里用的是 2020 年 6 月的日期，照抄的时候要换算成系统当前日期附近的时点，因为可用性检查是按需求日期和收货日期做比较的，如果拿一个已经过去的日期去建单，系统可能直接按历史时点算，结果和预期完全对不上。我吃过这个亏，当时照抄文档日期，建出来的预留怎么都不报错，查了半天才发现所有需求日期都在过去，系统压根没按未来推演。

最后留一个自己的教训。早年做这类测试，我喜欢先把配置全改一遍再开始建单，觉得这样效率高，结果第一次跑就不对，回头查是哪一处改错了，得把七八个勾选项一个个还原再试，一个下午就没了。从那以后我每次动检查组之前都先跑一遍上面那张用例表，把基线结果记下来，改完再跑一遍，两下一对比，问题出在哪个勾上立刻现形。这份文档里的五步推演和补充测试，本质上就是一条基线，照着走一遍把它变成你自己的基线，后面所有关于可用性检查的争论都会变得很好收场。希望帮到你。

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