简介这份文档面向SAP顾问、供应链与物料计划人员围绕可用性检查这一核心功能展开测试与验证帮助读者理解静态检查与动态检查在实际业务中的差异与配置逻辑。资源包共1个docx文件约536KB内容以测试记录与配置说明为主便于直接查阅与复用。文档从IM层面的静态可用性检查切入说明其无需后台配置、仅依据当前库存判断的特点随后深入MRP层面的动态可用性检查梳理安全库存、在途库存、质检与冻结库存等库存维度以及采购订单、采购申请、预留、独立需求、生产订单等预计划收发货因素并特别区分手工预留与订单自动产生预留的差异。文中还给出移动类型、检查规则与可用性检查组的配置路径并通过预留单、采购订单与需求日期调整的模拟测试展示系统报错与放行的判断过程以及补货提前期对结果的影响。目前已有3057人学习适合需要掌握SAP可用性检查配置与排错思路的读者参考。1. 从一次预留报错说起SAP可用性检查到底在查什么有个做PP模块的同行在群里贴了一张报错截图物料库存明明躺着100个建一张30个的预留却被系统拦下来提示可用库存不足。他反复查了MM03的库存总览非限制库存、质检库存、冻结库存加在一起远超需求数量但系统就是不松口。这种“库存看得见、系统说不够”的玄学现象几乎每个刚接触SAP可用性检查的人都会撞上一次。这份《SAP可用性检查应用测试》文档就是围绕这个场景展开的实操记录。它不讲虚的直接拆了两种检查类型——IM层面的静态检查和MRP层面的动态检查用一组预留、采购订单、需求日期的组合测试把系统到底怎么算“可用”这件事摊开给你看。适合正在配检查规则、被预留报错卡住、或者想搞清楚补货提前期到底怎么影响判断的从业者。读完你至少能明白系统报错不是乱报它算的是未来某个需求日期上的可用量而不是你此刻看到的库存数字。2. 静态检查与动态检查两种逻辑的分水岭在哪2.1 静态检查只看眼前库存不做任何预判静态可用性检查发生在IM层面逻辑简单到近乎粗暴。系统只拿当前库存地点下的非限制使用库存去比对需求数量不考虑任何在途、预留、计划订单。文档里举的例子很典型1000工厂A001库存地点有100PC物料你用MIGO做201成本中心发料105PC系统立刻报错因为100减105小于零。这个检查不需要任何后台配置系统默认就会执行。它的适用边界也很清楚适合那些“发了就没了”的场景比如直接消耗类发料、成本中心领用。你不需要它去预测未来它也不具备那个能力。很多新手误以为所有库存移动都会触发动态检查其实不是——移动类型决定触发哪种检查而移动类型的配置又和检查规则绑定。2.2 动态检查把未来收发货全部拉进来算总账动态检查在MRP层面运行考虑的因素多得多。文档里列了两组库存侧包括安全库存、在途库存、质检库存、冻结库存、非限制使用库存、外包库存预计划收发货侧包括采购订单、采购申请、相关需求、预留、独立需求、SD提货单、货运通知单、基于订单的预留、库存传输订单、计划订单、生产订单。这里有个容易被忽略的细节文档特别提醒了“4跟8的差异”。4是手工预留8是订单自动产生的预留。两者在系统里的来源不同但都会参与动态可用性计算。如果你在排查为什么某张预留没被算进去先确认它是手工建的还是订单带出来的。动态检查的核心逻辑是在需求日期那个时间点上把之前所有已知的收货和发货全部加减一遍看剩余量能不能覆盖当前需求。它不是在查“现在有多少”而是在查“到那天为止还剩多少”。2.3 配置路径移动类型、检查规则、检查组的三层绑定文档给出的配置路径是移动类型 → 检查规则 → 定义检查规则。这三层是逐级绑定的。移动类型决定哪些操作触发检查检查规则决定用哪套参数去算检查组则是参数的集合。有一个坑文档里专门标了新建或复制检查组时后面的参数“总计销售A”“总交货需求A”“冻结需求传默认勾选”这三处改不了。这不是系统bug是SAP的标准行为。你只能接受这个默认值或者去改更底层的配置。很多人在这里卡住以为是自己权限不够或者配置漏了其实它就是设计成这样。提示如果你需要调整这三个参数的行为不要在前台检查组界面硬试去检查规则的定义层面找对应的控制点。3. 用一组预留和采购订单把动态检查的算法跑一遍3.1 测试数据准备与检查组分配文档的测试从一组干净的数据开始。物料G0120030计划交货时间6天分配了前面定义的可用性检查组。初始状态是2020年6月19日静态库存100PC。这个100是后续所有计算的起点。在动手之前建议你先用MM03确认三件事物料主数据里的可用性检查组是否已分配、计划交货时间是否维护、工厂和库存地点的非限制库存是否准确。这三项任何一个缺失后面的测试都会跑出意料之外的结果。3.2 逐步构建需求与收货观察系统报错节点步骤1确认20200619静态库存为100。步骤2建预留单单号19需求日期20200621数量80。此时系统不报错因为20200621之前没有其他消耗100减80等于20够用。步骤3建采购订单数量50需求日期20200625。系统根据预计交货日期自动带出这个日期。这张PO在动态检查里会被当作“预计划收货”参与计算。步骤4再建预留需求日期20200620数量30。系统报错。为什么因为20200620这个时间点上可用库存等于当前库存100减去20200621那张预留的80剩下20小于30。注意这里的关键虽然20200621的需求日期在20200620之后但动态检查在计算20200620的可用量时会把之前所有未清的需求都算进去。这就是很多人翻车的地方——以为需求日期靠后就安全其实系统看的是时间轴上的累计效应。步骤5把需求日期改到20200626数量30系统通过。计算逻辑是100减80加50等于7070大于30。这里加上的50就是那张采购订单因为它的收货日期20200625在需求日期20200626之前所以被算作可用。3.3 补货提前期那个让结果反转的勾选项文档的补充测试是整篇里最有价值的一段。把“不含补货提前期”勾选上再在20200626建需求系统报错。同一个日期、同一个数量只因为一个勾选项结果完全反转。补货提前期的含义是系统在判断某个需求日期是否可用时会往前推一段时间看那段时间内是否有足够的补货。如果不勾这个选项系统就只看需求日期当天及之前的收货不会把“未来可能到货但还没到”的部分提前纳入。勾上之后系统会把补货周期内的预期收货也算进来。这个参数在实际项目里争议很大。勾上系统更宽松可能放过一些实际上有风险的订单不勾系统更严格但可能误杀一些其实能赶上的需求。我的经验是如果你们的采购周期稳定、供应商靠谱可以勾上如果采购提前期波动大建议不勾宁可让系统报错人工介入判断。# 查看当前检查规则分配的快速路径事务代码层面 # 1. 用MM03查看物料主数据MRP3视图的可用性检查组 # 2. 用OVZ2查看检查规则定义 # 3. 用OVZ1查看可用性检查组参数 # 注意不同版本的事务代码可能略有差异以系统实际为准上面这组事务代码是排查时的常用入口。OVZ2和OVZ1的区别在于OVZ2定义规则本身OVZ1定义检查组并分配规则。如果你发现某个移动类型没有触发预期的检查先从这里查起。4. 避坑与排查预留报错时先看这五个地方4.1 现象库存充足但预留报错提示可用量不足原因动态检查算的是需求日期时间点上的累计可用量不是你此刻看到的库存总数。之前未清的需求、预留、计划订单都会吃掉可用量。解决用MD04看物料在那个日期前后的出入库明细把时间轴拉出来逐项加减。不要只看MM03的库存总览。4.2 现象采购订单已建但动态检查没把它算进去原因采购订单的收货日期在需求日期之后或者采购订单的确认标识、交货日期没维护正确。系统只认“在需求日期之前能到货”的收货。解决检查采购订单的交货日期和确认交期确保它在需求日期之前。如果确实到不了那就是真实的供应缺口系统报错是对的。4.3 现象新建检查组时三个参数灰显改不了原因SAP标准行为总计销售、总交货需求、冻结需求这三个参数在检查组层面固定为A和默认勾选。解决不要在这个界面死磕。如果业务确实需要不同的行为去检查规则的定义层面找替代控制点或者用增强的方式处理。大多数场景下默认值已经够用。4.4 现象手工预留和订单自动预留系统处理方式不一致原因文档里提到的4和8差异。手工预留和订单产生的预留在系统里的来源标识不同参与动态检查时的优先级和逻辑可能有细微差别。解决在MD04里分别查看两类预留的行项目确认它们是否都出现在可用量计算中。如果有一类没出现检查预留的类型和状态。4.5 现象补货提前期勾选后系统放过了明显不够的需求原因补货提前期把未来一段时间的预期收货提前纳入了计算导致可用量被高估。解决评估你们的采购提前期稳定性。如果不稳定取消这个勾选让系统严格按实际到货日期判断。宁可多报错不要漏报。注意每次修改检查规则或检查组之后一定要用一组已知结果的数据重新跑一遍测试。配置的改动不会自动生效到所有场景有些需要重新创建单据才会触发新规则。5. 进阶技巧用MD04和检查规则模拟器做交叉验证当你把基本的预留、采购订单测试跑通之后下一步是学会交叉验证。我一般会做两件事第一用MD04把物料的时间轴拉出来逐日核对出入库第二用检查规则模拟器如果有的话或者新建一组测试单据验证配置改动后的行为是否符合预期。MD04的用法有讲究。不要只看当天的库存行要把日期范围拉宽到覆盖需求日期前后各两周。重点看三类行项目需求类预留、销售订单、相关需求、收货类采购订单、采购申请、计划订单、库存类非限制、质检、冻结。把这三类按日期排序手动加减一遍看结果和系统报错是否一致。如果一致说明你理解了逻辑如果不一致说明还有你没考虑到的因素。检查规则模拟器不是所有版本都有如果没有就用最笨的办法建一组隔离的测试数据物料、工厂、库存地点都独立然后逐步添加需求观察系统在哪个节点开始报错。这个方法慢但最可靠。还有一个容易被忽略的点计划交货时间。文档里物料G0120030的计划交货时间是6天。这个字段在动态检查里会影响补货提前期的计算。如果你发现系统对某个日期的判断和预期不符先确认物料的计划交货时间是否维护正确。# MD04时间轴核对时的常用操作 # 1. 输入物料和工厂进入MD04 # 2. 点击“设置”调整日期范围建议前后各两周 # 3. 用“筛选”只显示需求、收货、库存三类行项目 # 4. 逐行记录日期和数量手动加减验证 # 5. 对比系统报错节点确认逻辑一致性从那以后我每次配完检查规则都会强制走一遍这个流程建一组隔离数据、逐步添加需求、用MD04交叉验证、确认补货提前期的勾选状态。这套动作花不了多少时间但能挡住大部分上线后才会暴露的坑。希望帮到你。本文还有配套的精品资源点击获取