简介:这是一份围绕SAP系统可用性检查的应用测试文档,适合SAP顾问、物料管理人员及供应链相关学习者,用于理解并验证静态与动态可用性检查的核心逻辑与配置路径。资源包共包含1个docx格式文档,整体大小536KB,内容集中在可用性检查的原理说明与实操测试。已有3055人学习下载,可作为SAP相关岗位的实用参考资料。文档基于MIGO发料场景展示静态检查如何直接提示库存不足,又通过预留、采购订单与补货提前期的组合案例,详细演示动态检查对可承诺库存的计算与异常报错,并梳理了可用性检查组、移动类型、检查规则等后台配置要点。读者可以据此搭建测试思维,快速理解物料在需求日期是否可用的判定机制,减少因库存短缺或过度承诺带来的业务风险。
1. SAP可用性检查:从静态到动态,先搞清这两套逻辑再建单
做SAP可用性检查的配置或测试,最忌一上来就调检查规则,因为先要分清楚系统里跑的是哪一层检查。同样一个物料在1000工厂有100件现货,MIGO发料超了会报错,建预留时却可能放行,这种看似矛盾的“翻车”现场,根源就是静态可用性检查与MRP层面动态可用性检查的差异。这篇笔记用一套完整的模拟数据把两条检查路径走一遍:先看它们分别检查什么,再按“建预留→建采购订单→再建预留”的顺序复现动态检查的报错与放行,最后把配置里最容易踩的三个默认参数和补货提前期的坑拆开讲。适合做MM/PP/SD后勤模块的从业者,以及刚接手可用性检查配置、想快速验证业务场景的人。
2. 静态可用性检查:IM层面的快速校验,一条MIGO就能验证
2.1 静态检查的逻辑与适用边界
静态可用性检查发生在IM层面(库存管理层面),也叫“可用性检查的简单模式”。它的判断基准只有一个:某个库存地点的非限制使用库存够不够本次需求,不把未来的采购订单收货、计划订单、相关需求等纳进来。素材里的例子很直接:1000工厂A001库存地点有100PC物料,用MIGO做货物移动,移动类型201向成本中心发料105PC,系统提示差5PC,这就是静态检查在工作。
理解这条逻辑要抓住三个边界:
第一,静态检查的“可用库存”是当前时点的库存视图,不考虑需求日期之后会不会有PO入库;第二,它默认不区分“哪天要用”,只要本次过账数量超出当前库存就报错;第三,它不需要额外配ATP检查规则,系统按移动类型里的默认设置直接跑,这也是素材里说“无须任何后台配置”的原因。
静态检查适合用在哪些场景?成品发料、成本中心发料、简单的库存转移这类对供应时点不敏感的业务,用静态检查足够快、足够直观。但对销售订单交期承诺、生产订单组件齐套这类需要把未来收货和未来需求放在一起算的业务,静态检查不够,必须上动态检查。
需要注意的是,“静态”不代表“落后”。有些顾问一看到需求日期就直接配动态检查,反而把简单的发料场景搞复杂了——静态检查没有补货提前期、没有需求累加,性能开销小,在库存地点多、过账频率高的环境里更稳。
2.2 静态检查的验证路径:MIGO 201发料直接复现
验证静态检查不需要动后台配置,有MM权限就能做。我用一套最小数据复现素材里的场景:
物料主数据建一个测试物料,库存地点A001维护初始库存100PC;然后MIGO发料,移动类型201,数量填105,过账时系统直接提示可用量不足,差额5PC。
具体操作如下:
事务代码:MM01 / MMBE(查看库存) 事务代码:MIGO 凭证类型:R(收货)改为 A(发货) 移动类型:201 接收方:成本中心 数量:105过账时的表现是:系统消息栏提示“物料xxx的可用数量不足(剩余5件)”这类库存不足消息。这里要理解的是,系统比较的是“当前非限制库存100”和“本次过账数量105”,105大于100,所以报错。把数量改成100或99,过账成功,这就是静态检查最典型的验证方式。
从配置角度看,静态检查的开关其实藏在移动类型里。IMG路径是物料管理→库存管理→移动类型→复制/修改移动类型,事务代码OMB2。选中201移动类型,双击“可用性检查”字段,可以看到检查规则被指定为默认规则,这一层不需要额外配检查控制。
我在项目里碰到过一种误判:有人把201移动类型里的检查规则改成动态规则,认为这样就能“增强”发料检查,结果发料时系统开始考虑补货提前期,未来收货未到就把旧库存扣完,账实反而不符。常见做法是静态检查场景保持移动类型默认规则,只在预留、销售订单、生产订单这类真正需要ATP逻辑的对象上做动态检查。
2.3 静态与动态的判断路径对比
| 对比维度 | 静态可用性检查(IM层面) | 动态可用性检查(MRP层面) |
|---|---|---|
| 检查层面 | 库存管理(IM) | 物料需求计划(MRP) |
| 检查对象 | 当前非限制库存 | 库存+预计划收货+预计划发货 |
| 是否考虑未来需求 | 否 | 是 |
| 是否考虑补货提前期 | 否 | 可配置 |
| 后台配置要求 | 基本不需要 | 需要定义检查规则与检查控制 |
| 典型业务 | 成本中心发料、库存转移 | 销售订单、预留、生产订单组件 |
判断路径其实是倒过来的:先问业务要不要看未来,再看后台配置有没有配动态规则,最后用一张测试单验证。素材里的动态测试就是因为勾选了“不含补货提前期”,同一张预留单在不同日期产生了完全不同的结果,这一点在第四章会完整拆解。
3. 动态可用性检查:MRP层面的完整“料账”逻辑
3.1 动态检查纳入的库存要素:从安全库存到外包库存
动态可用性检查与静态检查最大的差异,是把“库存”从单一的非限制库存拆成了六类要素。素材里明确列出的有:安全库存、在途库存、质检库存、冻结库存、非限制使用库存、外包库存。这六个要素在检查逻辑里不是简单相加,系统按物料在MRP视图里维护的参数,把可用库存计算为:
可用库存 = 非限制使用库存 + 在途库存(采购订单已发货未收货的部分) + 质检库存(如果检查规则允许纳入) + 外包库存(分包业务场景) - 安全库存(作为缓冲保留,不参与可用量计算)这里需要特别强调的是安全库存的角色:安全库存不是“可以用的库存”,而是“不允许动用的库存”上限。动态检查把安全库存当作需求的一部分来扣除,相当于系统在计算时先预留这部分数量,防止库存被业务单据吃穿。素材里把安全库存列入“对库存的考虑”,其实就是这个含义。
质检库存和冻结库存是否纳入可用量,取决于检查规则里的控制参数。很多第一次配的人会疑惑:为什么质检库存明明是实物库存,可用性检查里却不认?原因就在于检查控制里有限制范围设置。常见做法是:正常的可用性检查只认非限制使用库存,质检和冻结库存默认不让业务占用,只有特殊场景(紧急放行)才在规则里放开。
外包库存是另一个容易忽略的点。如果物料有分包业务,库存里有外包库存,动态检查会把它和常规非限制库存分开计算,因为外包库存的可用性取决于供应商产能而非工厂库存。素材里把它单列一项,说明在做动态检查配置时,外包库存要有对应的检查范围定义。
3.2 动态检查纳入的计划要素:采购订单、预留、SD提货单这11项
动态检查对“预计划的收货和发货”的考虑比库存要素更复杂,素材里列了11项:①采购订单、②采购申请、③相关需求、④预留、⑤独立需求、⑥SD提货单、⑦货运通知单、⑧基于订单的预留、⑨库存传输订单、⑩计划订单、⑾生产订单。
这11项在系统中的角色分两类。一类是“收货类”需求,比如采购订单和采购申请,它们在未来的某个时点会增加可用库存;另一类是“发货类”需求,比如销售订单、预留、生产订单,它们在未来的某个时点会消耗库存。动态检查在执行时,按“需求日期”把所有相关单据累加起来,得出某个时点上的可用量。
这里有一个新手必踩的概念分叉:第④项“预留”指手工预留,就是MB21这类事务代码建的预留单;第⑧项“基于订单的预留”指系统根据生产订单、销售订单自动产生的预留,不需要人工干预。两者在检查逻辑里都算发货需求,但来源不同、调整方式不同。素材专门强调“4跟8的差异”,因为手工预留可以随意改数量和日期,而基于订单的预留会随着订单数量变化自动重算——你在检查规则里给它们分配不同的“需求类型”后,系统在处理时会有完全不同的累加行为。
3.3 配置路径与三个默认锁死的参数
动态可用性检查不是配一个开关就能跑,需要按顺序走三个配置点。素材给的路径是“移动类型 → 检查规则 → 定义检查规则”,完整的IMG导航常见做法是:
IMG路径: 物料管理 → 基于消耗的计划 → 可用性检查 → 定义检查规则(OVZ1) 物料管理 → 基于消耗的计划 → 可用性检查 → 定义检查控制(OVZ2) 物料管理 → 基于消耗的计划 → 可用性检查 → 分配检查规则(OVZ3)在OVZ1中定义检查规则时,可以复制标准检查规则创建新规则,也可以直接新建。素材里特别提醒了一个“玄学”现象:不管是新建还是复制,新定义的可用性检查组后面的三个参数都是默认值——总计销售=A、总交货需求=A、冻结需求默认勾选,这三个值在界面上是灰的,修改不了。
这个现象的原因在于:这三个字段属于“检查规则”在T683表中的固定属性,SAP在标准检查规则里把它们定义成了最高等级的控制参数,不允许用户级修改。如果你确实需要不同的累加口径,只能选一个已经符合口径的标准规则来复制,或者对现有规则做检查控制层面的改动,而不是硬改这三个字段。
OVZ2里定义检查控制时,才能看到真正的“可操作参数”:是否允许补货提前期、是否包含收货、是否检查冻结库存等。素材里的补充测试“把不含补货提前期勾选”,改的就是这一层。常见的坑是:只在OVZ1里定义规则,没在OVZ2里维护检查控制,结果新建的检查规则在测试时表现和标准规则一样,看不出差异。
4. 一个案例跑通动态检查:从20200619到20200626的五步测试
4.1 测试数据准备:物料、计划交货时间、可用性检查组
要跑通动态检查测试,先准备四样东西:物料主数据、库存地点、计划交货时间、可用性检查组。素材里用的物料是G0120030,计划交货时间6天,可用性检查组分配为前面定义的动态检查组。我一般在测试前把这几项先截个图存档,后面所有模拟步骤都基于同一份数据,方便回溯。
具体准备路径如下:
MM01 → 创建物料G0120030,维护工厂1000/库存地点A001 MM02 → MRP2视图 → 计划交货时间:6天 MM02 → 工厂数据/MRP2视图 → 可用性检查组:填写自定义检查组 MMBE → 确认A001库存地点当前库存为100PC(日期20200619)这里有个细节:可用性检查组字段是在物料主数据的MRP2视图里分配的,不是每次建单据时临时选择。这意味着同一个物料只能配一个检查组,如果销售订单和生产订单要用不同的检查规则,要么分开设物料,要么用“可用性检查组”的自动确定逻辑来区分。
计划交货时间6天是本次测试的关键参数。素材里采购订单需求日期自动带出在20200625,就是依据这个6天计算出来的——动态检查在“可承诺”时会把补货提前期算进可用量。如果不维护计划交货时间,动态检查的PO收货不会出现在可用的时间窗口里,后面步骤就会变成静态检查的效果。
4.2 五步模拟:库存100、预留80、PO 50、再预留30
素材里的五步测试是一个经典的“库存消耗+未来补货”推演。我把每一步的动作用表格拆开,金额和数量全部按素材数据走:
| 步骤 | 日期 | 动作 | 数量 | 系统表现 | 计算逻辑 |
|---|---|---|---|---|---|
| 1 | 20200619 | 查看库存 | 100 | 正常 | 初始静态库存100 |
| 2 | 20200621 | MB21建手工预留 | 80 | 正常 | 消耗未来可用量 |
| 3 | 20200625 | ME21N建采购订单 | 50 | 正常 | 预留6天补货提前期后收货 |
| 4 | 20200620 | 再建预留 | 30 | 报错 | 20200620可用量=100-80=20<30 |
| 5 | 20200626 | 再建预留 | 30 | 通过 | 20200626可用量=100-80+50=70>30 |
步骤4是理解动态检查的“报错逻辑”的关键。需求日期20200620早于预留单80的需求日期20200621,但系统在20200620这个时点上,已经把20200621的预留需求80纳入计算了。这里的逻辑不是“看当天库存”,而是“看该时点之前所有已经确认的需求”,所以20200620可用库存=当前库存100-20200621预留需求80=20,20小于30,报错。
逻辑在于:MRP层面的可用性检查是“按需求日期排序扣减”的。系统把所有需求按日期从早到晚排列,然后用初始库存逐笔去扣。20200620这个日期在前,扣减时已经把后面20200621的80PC需求先算进去了,这是动态检查的累加特性,不是bug。
步骤5的通过则体现了“补货提前期”的参与:20200626这个日期晚于采购订单的收货日期20200625,所以系统在计算20200626可用量时,把PO数量50当作“已经可以使用的库存”加进去:100-80+50=70,70大于30,放行。这个“加回去”的动作,就是动态检查区别于静态检查的核心价值。
4.3 补货提前期开关造成的“报错翻转”
素材里的补充测试值得反复做:把检查规则里的“不含补货提前期”勾选上,再在20200626建立数量30的预留,系统直接报错。同样的日期、同样的库存、PO也还在,唯一变化的是补货提前期开关,结果从“通过”变成了“报错”。
原因不复杂:勾选了“不含补货提前期”,系统在计算20200626时点的可用量时,不再把PO 50纳入可用库存。此时可用量回到100-80=20,20小于30,所以报错。验证操作如下:
OVZ2 → 定义检查控制 → 选中检查规则 → 勾选“不包含补货提前期” (或按素材写法:勾选“不含补货提前期”) 然后回到MB21 → 建预留 → 需求日期20200626 → 数量30 → 回车这个测试的价值在于:它把“补货提前期”这个参数从抽象概念变成可见的报错/放行差异。勾选前,系统认为未来会有50入库,所以26号能发30;勾选后,系统只看已确定的需求和库存,未来PO不能提前“画饼”,所以26号照样缺料。
引申到实际业务里,这个开关对应的是“供应商能不能按时交付”的信心问题。如果业务上PO的到货日期不可靠,最好勾选“不含补货提前期”,宁可多报缺料、少承诺订单,也不要拿着不确定的PO去冲可用量。反之,如果供应商稳定、交期准确,不勾选能让可用量更贴近真实供应能力。
5. 动态可用性检查避坑:五个最容易翻车的地方
5.1 新规则前三个参数改不了,以为是权限问题
现象:新建或复制的检查规则里,“总计销售”“总交货需求”“冻结需求”三个字段灰色,点不动,第一反应是权限不够或编辑模式没开。
原因:这三个字段在T683表里属于检查规则的标准属性,SAP把这些参数在较高的标准层级锁定,不允许用户级修改。这不是权限问题,也不是编辑模式问题,而是设计如此。
解决:不要在这三个字段上花时间。需要不同累加口径时,换一个标准规则复制,或者在OVZ2检查控制里调整补货提前期、包含收货等参数来达到预期效果。T683里的字段改动属于开发级修改,正常项目里不做。
5.2 动态检查根本没触发,建单全部放行
现象:配置完检查规则,建预留、建销售订单时系统完全不检查,数量超额也不报错,感觉动态检查像是没配。
原因:最常见的是两个——物料主数据里没分配可用性检查组,或者分配的检查组和OVZ1里的检查规则对应的检查控制不一致;另一个原因是移动类型层面的静态检查先兜住了,轮不到动态规则参与。
解决:先查MM02里物料MRP2视图的可用性检查组是否为空,为空就填上自定义检查组;再查OVZ3里检查组与检查规则的映射关系;最后用事务代码OVZ2检查“检查控制”是否启用了“可用性检查”相关的元素。我自己的排查顺序一般是:检查组→检查规则→检查控制,三步走下来基本能找到断点。
5.3 手工预留与订单自动预留的4、8混用
现象:同一个物料,手工预留和订单自动预留的可用量结果不一样,测试数据总是对不上。
原因:素材已明确指出,第④项手工预留和第⑧项基于订单的预留是两类需求。人工建的预留修改灵活、日期可乱调,而订单自动产生的预留跟随生产订单或销售订单的数量变化而重算。如果检查规则里把两类需求分配了不同的累加符,系统计算时就会区别对待。
解决:测试前先确认这次要模拟的是哪一类预留。用MB21建的属于手工预留;跑MD04看物料需求清单时,带“预留类型”列的才能看出是订单自动产生还是手工维护。业务上要严格区分,不要拿着手工预留的结果去质疑订单自动预留的报错逻辑。
5.4 补货提前期开关导致“货没到却算有货”
现象:不勾选补货提前期时,PO收货没到货之前不增加可用量;勾选后,PO的需求日期一过,可用量立刻加上数量,哪怕实际还没做收货过账。
原因:这个开关控制的不是“收货事实”,而是“计划收货算不算数”。勾选=认可计划收货,未收货也按计划日期计入可用量;不勾选=必须实际收货后才算。素材里20200626放行的70,就是PO的50在未收货状态下被算进可用了。
解决:上线前跟计划部门确认PO交期是“计划口径”还是“实际口径”。如果PO交期经常不准,勾选“不含补货提前期”更稳妥;如果能保证PO到货日期基本准时,不勾选更能反映真实供应。没有绝对正确,只有匹配业务习惯。
5.5 静态规则下把PO算进可用量,误判为系统BUG
现象:用静态检查规则跑单,需求日期已经过了PO收货日期,系统依然报缺料,业务质疑“PO都该到了,为什么不算可用”。
原因:静态检查只看当前库存,不看PO、采购申请、计划订单这些预计划收货。需求日期是否过PO日期对静态检查没有意义,它不会把未来收货加进可用量。
解决:判断当前物料用的到底是静态还是动态规则,可以进MM02看一下可用性检查组字段,再对照OVZ3里这个组连接的是哪条检查规则;也可以直接用MB21建一个跨PO收货日期的预留做对照测试。要跟业务解释时,与其讲概念,不如当场用两步走通“动态检查放行”“静态检查报错”的结果对比,效果远好过口头解释。
6. 验证与复核:把整套规则跑成一页测试报告
配置改完,真正要花时间的是“把每条规则都用手工单据验一遍”。我习惯在做完一套可用性检查配置后,新建一个测试物料,规划一张四行用例的验证表,覆盖静态检查、动态检查、补货提前期开关三条路径:
| 用例号 | 验证对象 | 操作 | 预期结果 |
|---|---|---|---|
| T01 | 静态检查 | MIGO 201发料105,库存100 | 报库存不足5 |
| T02 | 动态检查 | 预留20200620数量30,含PO 20200625数量50 | 报错,可用量20 |
| T03 | 动态检查 | 预留20200626数量30,含PO 20200625数量50 | 通过,可用量70 |
| T04 | 无补货提前期 | 预留20200626数量30,勾选不含补货提前期 | 报错,可用量20 |
这四条用例跑完,可以对照检查规则逐一打勾,比口头说“规则应该没问题”可靠得多。跑测试时我建议用独立的测试工厂和测试物料,不要拿生产物料试错,因为动态检查的累加逻辑会把历史预留、历史采购订单全部卷进来,数据一杂就没法判断是规则问题还是数据问题。
复核时还有一个容易被忽略的动作:改完OVZ1/OVZ2/OVZ3之后,系统缓存里可能还留着旧的检查逻辑。我遇到过改完规则后测试结果没变化,折腾半天发现是会话缓存没刷新。后来养成了习惯,每次改完配置后做一次核对:先看当前会话里的规则是否已是新版本,再执行事务代码SM35刷新批处理队列,或者干脆重建一个新的GUI会话窗口再跑测试。从那以后,每次改完可用性检查规则,我都强制走一遍“配置→刷新→四行用例测试”的流程,再也不靠拍脑袋判断规则生效了。
另外,动态检查的测试结果要留档。把MMBE库存截图、MB21预留单、ME21N采购订单、系统报错或放行消息都截在一起,做成一条完整证据链。后续无论业务部门质疑“为什么26号能建30号不能建”,还是开发同事怀疑“规则配置有问题”,直接翻这份测试记录就能定位是规则没配对、还是业务数据已经变化了。希望这份笔记能帮你在排查可用性检查时少走两步弯路。
本文还有配套的精品资源,点击获取