简介：本资源是一份面向SAP ABAP开发人员、供应链顾问及系统实施工程师的实操型测试文档，聚焦SAP可用性检查功能的原理验证与配置落地。文档深入解析静态（IM层面）与动态（MRP层面）两类可用性检查的核心逻辑、适用场景及关键差异，涵盖库存维度（安全库存、在途/质检/冻结/非限制/外包库存）与计划维度（采购订单、预留、生产订单、SD提货单等）的综合校验机制，并通过5步前台模拟测试（含需求日期变更、补货提前期开关对比），直观呈现系统可用性判断的动态计算过程。资源为1个536KB的Word文档（.docx），内容结构完整，含业务背景、配置路径说明、事务代码指引及详细测试截图与结果分析。目前已有3062人学习下载，适合希望透彻理解可用性检查底层逻辑、规避库存承诺风险并提升MRP配置能力的中高级SAP用户。
1. SAP可用性检查不是“库存够不够”的简单判断，而是MRP逻辑在前台的一次实时推演
你有没有遇到过这种场景：销售订单刚保存，系统立刻弹出“物料G0120030在20200620不可用”，但翻库存报表发现当天非限制库存明明有100件？——这不是系统抽风，而是动态可用性检查（ATP）在后台默默跑完了一整套MRP时栅逻辑：它把当前库存100，减去已锁定的预留80（6月21日那笔），再加进6月25日采购订单承诺的50件收货，最终算出6月26日可用量为70。而6月20日没加补货，所以只剩20，不够30。这个过程不依赖人工查表，也不等MRP运行，是事务触发瞬间完成的实时计算。本文讲的不是概念复述，而是把那份《SAP可用性检查应用测试.docx》里藏在截图和步骤背后的真实配置链路、参数生效边界、以及五个必踩的隐性坑，全部拆开给你看。适合正在做SD/MM模块配置、准备上线ATP功能，或被业务方反复追问“为什么这里报错那里放行”的一线ABAP顾问、FICO/SD顾问、以及带技术背景的供应链系统负责人。
2. 静态 vs 动态：两种检查的本质差异不在界面，而在数据源与触发时机
2.1 静态检查：IM层的“快照式”校验，本质是库存主数据+移动类型控制
静态可用性检查（Static Availability Check）严格来说甚至不算一个独立功能模块，它是库存管理（IM）底层的硬编码逻辑。其核心判断依据只有两个：
- 当前库存地点（Storage Location）下该物料的非限制使用库存数量（Unrestricted Stock）；
- 所选移动类型（Movement Type）是否启用了库存检查开关（Transaction OMJJ 中配置）。
以文档中MIGO 201发料为例：当用户输入移动类型201、物料G0120030、数量105时，系统立即读取该工厂+库存地点组合下的MARD-LABST字段值（即非限制库存），若105 > LABST，则直接报错“库存不足”，不走任何后台配置路径，也不读取MRP视图、不查采购订单、不看质检状态。这就是为什么它“无须后台配置”——因为配置早已固化在移动类型定义里。
提示：静态检查的开关位置在事务码OMJJ中，针对每个移动类型单独勾选“Check availability”。未勾选则完全跳过此检查，哪怕库存为0也允许过账。这是很多客户上线后才发现“发料不拦库存”的根本原因。
2.2 动态检查：MRP层的“时序推演式”计算，本质是ATP引擎调用MRP元素集合
动态可用性检查（Dynamic Availability Check）才是SAP ATP功能的真正载体。它不直接读取库存表，而是调用MRP运行时的内存结构，按时间轴逐日展开需求与供给。其数据源来自三类：
- 库存侧：非限制库存、安全库存、在途库存（PO收货）、质检库存（QI）、冻结库存（BLK）、外包库存（VMI）；
- 需求侧：销售订单（SO）、预留（Reservation）、生产订单（PRD）、计划订单（PLN）、独立需求（IND）；
- 供给侧：采购订单（PO）、采购申请（PR）、计划订单（PLN）、库存转储单（STO）、货运通知（DEL）；
关键点在于：所有这些数据必须已存在于系统中，且时间戳有效。例如，采购订单的“预计交货日期”必须早于需求日期，否则不参与ATP计算；预留单的“需求日期”必须是工作日（受工厂日历控制），否则系统会自动顺延到下一个工作日再计算。
2.3 为什么“冻结需求传默认勾选”无法修改？——这是ATP引擎的硬性契约
文档中提到：“新定义的可用性检查组后面的参数都是默认‘总计销售=A’‘总交货需求=A’‘冻结需求传默认勾选’此三处修改不了”。这不是UI限制，而是ATP引擎的底层设计约束：
总计销售=A：表示将所有销售订单行项目（含未确认、已确认、部分交货）统一计入总需求。若设为B（仅已确认），则未确认的SO不会参与ATP，极易导致过度承诺；总交货需求=A：同理，将所有交货单（VL01N创建的）纳入供给端计算。若设为B，则只计已过账交货，漏掉在途发货；冻结需求传默认勾选：指将“冻结库存”（如质量检验中、冻结批次）视为不可用库存。此项强制启用，是因为ATP逻辑要求所有库存状态必须明确可用性，冻结库存天然不具备即时可发性。
这三项一旦放开自定义，ATP结果将失去一致性保障。某导师曾在一个汽车零部件项目中尝试绕过此限制，结果导致销售端承诺交付日期与仓库实际可发货日期偏差达7天，最终回滚配置。
3. 动态检查配置四步法：从移动类型绑定到检查规则落地
3.1 第一步：确认移动类型已启用动态检查（事务码OMJJ）
动态检查不是全局开关，而是依附于具体移动类型。必须确保目标移动类型（如预留用201、生产订单发料用261）在OMJJ中勾选了“Check availability”且检查类型（Check Type）设为‘D’（Dynamic）：
# 进入事务码 OMJJ # 选择移动类型 201 → 点击“详细数据”标签页 # 检查字段： # - Check availability: X（勾选） # - Check type: D（必须为D，A=Automatic静态，B=No check） # - Availability check: 01（此处填入你后续定义的检查规则编号）注意：若此处设为A（静态），则无论后台如何配置动态规则，系统都只走库存快照逻辑。这是新手最常忽略的断点。
3.2 第二步：定义可用性检查规则（事务码OVZ2）
检查规则（Availability Check Rule）是动态检查的“策略模板”，它决定ATP计算时包含哪些库存与需求类型。标准规则01（缺省）已包含大部分常用项，但需根据业务调整：
| 字段名 | 含义 | 推荐值 | 说明 |
|---|---|---|---|
Total sales | 销售订单需求汇总方式 | A | 强制，不可改 |
Total delivery req. | 交货单供给汇总方式 | A | 强制，不可改 |
Frozen stock | 冻结库存是否计入不可用 | X | 强制勾选 |
Stock in transit | 在途库存是否计入可用供给 | X | 若存在跨厂调拨必须勾选 |
Quality inspection stock | 质检库存是否计入可用供给 | 空白 | 通常不勾选，因质检中物料不可发 |
Blocked stock | 冻结库存是否计入不可用 | X | 强制勾选 |
提示：
Stock in transit若未勾选，跨厂采购订单的收货将不参与ATP，导致本地工厂误判缺料。某公司曾因此造成3个工厂同时向同一供应商下单。
3.3 第三步：分配检查规则至可用性检查组（事务码OVZ3）
可用性检查组（Availability Check Group）是规则的容器，它与物料主数据MRP视图中的AVTKZ字段绑定。一个检查组可挂多个规则，但每个物料只能分配一个检查组：
# 进入事务码 OVZ3 # 创建新组 ZATP01（建议前缀Z避免与标准冲突） # 在“检查规则”子屏幕中添加： # - Rule: 01（上一步定义的规则） # - Requirement type: `KE`（销售订单）、`RES`（预留）、`PD`（生产订单）等 # - Supply element: `PO`（采购订单）、`PR`（采购申请）、`STO`（库存转储）等关键参数说明：
Requirement type：定义哪些需求类型参与计算。若只勾选RES（预留），则销售订单不会触发ATP；Supply element：定义哪些供给类型参与计算。若漏掉STO，则跨库存地点调拨单不计入供给；- 文档中强调“新建检查组后参数不可改”，实则是系统对
KE/RES等类型的默认行为锁定，但你可在子屏幕中增删具体类型。
3.4 第四步：将检查组分配至物料主数据（事务码MM02）
最后一步是让物料“认领”检查组。进入物料主数据MRP视图（MRP 1），填写字段AVTKZ（Availability check group）为ZATP01。此操作必须在物料创建后、首次使用前完成，否则历史预留/订单不会被新规则覆盖。
注意：若物料已存在大量预留单，修改
AVTKZ后需执行事务码CO09（重新计算可用性）或MD04（MRP清单）刷新缓存，否则前台仍按旧规则计算。
4. 前台测试五步验证法：用真实数据跑通ATP时序逻辑
4.1 测试准备：构建最小闭环数据集
按文档描述，我们构建以下基础数据（单位：PC）：
- 物料G0120030，工厂1000，库存地点A001；
- 当前库存（20200619）：非限制库存 = 100；
- 预留单19：需求日期20200621，数量80；
- 采购订单（PO）：数量50，预计交货日期20200625；
所有日期均需在工厂日历中为工作日，否则系统自动顺延，导致测试失真。
4.2 步骤一：验证静态检查失效点（MIGO 201发料105）
# 事务码 MIGO → 选择移动类型 201 # 输入物料 G0120030，数量 105 # 系统报错："Insufficient stock for movement type 201" # 原因：静态检查读取 LABST=100 < 105，直接拦截逻辑说明：此步验证OMJJ中201移动类型是否正确启用静态检查。若未报错，说明
Check availability未勾选或Check type设为B。
4.3 步骤二：触发动态检查（MB21建预留单）
# 事务码 MB21 → 创建预留 # 物料 G0120030，数量 30，需求日期 20200620 # 系统报错："Material G0120030 not available on 20200620" # 查看ATP详情（按钮"Availability"）： # - Current stock: 100 # - Requirements on 20200620: 30 (new reservation) # - Requirements on 20200621: 80 (existing reservation) # - Supply on 20200625: 50 (PO) # → ATP result for 20200620: 100 - 30 = 70? No — because PO supply is on 20200625, not 20200620 # → So available = 100 - 30 = 70? Wait — but existing reservation on 20200621 locks 80 from 20200619 onward! # → Correct ATP: 100 - 80 (locked from 20200621) = 20 < 30 → error参数说明：ATP引擎按时间轴滚动计算，20200620当日可用量 = 初始库存100 - 已锁定需求（所有需求日期 ≤ 20200620的预留/订单）。由于20200621的预留在20200620已生效（ATP锁定从需求日期起始），故当日可用量仅为20。
4.4 步骤三：验证补货提前期生效（需求日期改为20200626）
# 同样用 MB21，数量 30，需求日期 20200626 # 系统允许保存 # ATP详情显示： # - Current stock: 100 # - Requirements until 20200626: 80 (20200621) + 30 (20200626) = 110 # - Supply until 20200626: 50 (20200625 PO) # → Available on 20200626: 100 + 50 - 80 - 30 = 40 > 0 → OK关键逻辑：ATP计算的是“截至需求日期的累计净可用量”，而非单日快照。20200626的可用量 = 初始库存 + 所有供给（≤20200626） - 所有需求（≤20200626）。因PO在20200625到货，故计入供给。
4.5 步骤四：关闭补货提前期验证（OVZ2中取消勾选“Stock in transit”）
# 进入 OVZ2 → 规则 01 → 取消勾选 "Stock in transit" # 保存并激活 # 再次用 MB21 创建需求日期 20200626，数量 30 # 系统报错："Not available" # ATP详情： # - Supply until 20200626: 0 (PO excluded) # → Available = 100 - 80 - 30 = -10 → error血泪经验：某快消客户曾因未勾选
Stock in transit，导致所有跨区域调拨单不参与ATP，销售端承诺7天交付，仓库实际要等14天调货，引发客户投诉。补货提前期不是“可选项”，而是ATP成立的前提。
5. 动态检查避坑指南：五个真实翻车现场与自救方案
5.1 现象：销售订单（VA01）不触发ATP，但预留（MB21）可以
原因：销售订单使用的移动类型（通常是601）在OMJJ中Check type设为A（静态）或B（不检查），而非D（动态）；或销售订单对应的需求类型KE未在检查组（OVZ3）中勾选。
解决：
- 进入OMJJ，查移动类型601的
Check type是否为D； - 进入OVZ3，确认检查组中
Requirement type包含KE； - 若使用增强（如USEREXIT_SAVE_DOCUMENT_PREPARE），需检查增强代码是否绕过了ATP调用。
5.2 现象：采购订单（ME21N）收货后，ATP结果未更新
原因：采购订单收货（MIGO 101）生成的库存移动未关联到ATP供给链。常见于：
- PO未维护“计划交货日期”（EINDT），导致ATP引擎无法确定供给时间点；
- 收货移动类型101在OMJJ中未启用动态检查（应启用，否则不触发ATP重算）；
- 库存地点与采购信息记录（info record）中默认库存地点不一致，导致供给未落到正确地点。
解决： - 检查PO抬头的
EINDT字段是否填写； - 进入OMJJ确认移动类型101的
Check type=D； - 用事务码
MMBE核对收货后库存是否出现在预期库存地点。
5.3 现象：ATP显示可用，但仓库实际无法发货（如质检中、冻结批次）
原因：ATP计算时包含了质检库存（QI）或冻结批次（BLK），但这些库存物理上不可发。根源在于OVZ2中错误勾选了Quality inspection stock或Blocked stock。
解决：
- 进入OVZ2，确保
Quality inspection stock和Blocked stock字段为空白； - 用事务码
MD04查看ATP详情，确认“Stock in quality inspection”和“Blocked stock”数值为0； - 若业务确需将质检库存纳入ATP（如医药行业），需配合批次管理（batch management）启用特殊移动类型。
5.4 现象：同一物料，不同工厂ATP结果不一致
原因：ATP计算基于工厂级数据，但检查组（OVZ3）分配至物料主数据时，可能只维护了部分工厂的MRP视图。未维护的工厂沿用缺省检查组（如00），而00组未配置PO/STO等供给类型。
解决：
- 用事务码
MM02逐个工厂打开物料主数据MRP视图； - 确认每个工厂的
AVTKZ字段均填写为ZATP01； - 若工厂多，可用LSMW批量更新
MARC-AVTKZ字段。
5.5 现象：ATP结果延迟1~2秒才弹出，影响前台操作流畅度
原因：ATP引擎需实时读取大量表（如RESB、EBAN、EKPO、MSEG），若数据库未建索引或服务器内存不足，会导致查询慢。
解决：
- 检查数据库表
RESB（预留）、EBAN（采购申请）是否有复合索引：MATNR+WERKS+BDTER（物料+工厂+需求日期）； - 在事务码
DBACOCKPIT中监控ATP相关SQL执行时间； - 对高并发场景，可启用ATP缓存（需配置SCC4中ATP缓存开关），但会牺牲实时性。
6. 进阶技巧：用MD04反向验证ATP逻辑，把黑匣子变成透明流水线
6.1 MD04不是MRP运行工具，而是ATP的“调试控制台”
很多人把MD04当成MRP执行入口，其实它更是动态可用性检查的可视化调试器。当你在VA01或MB21中看到ATP报错，切忌直接改配置，先用MD04定位问题源头：
- 进入MD04，输入物料+工厂，回车；
- 点击右上角“ATP检查”按钮（或按Ctrl+Shift+A）；
- 在弹出窗口中输入需求日期、数量，点击“执行”；
- 查看下方“ATP详情”标签页，它会分栏列出：
Current stock：当前各类型库存；Requirements：所有需求类型明细（含行项目号、来源单据）；Supply：所有供给类型明细（含PO号、预计交货日）；Net requirement：逐日净需求曲线；
关键技巧：在MD04中右键点击任意需求行（如预留单19），选择“显示凭证”，可直接跳转到MB21查看原始单据；右键供给行（如PO 4500001234），选择“显示采购订单”，直达ME23N。这比翻后台表快10倍。
6.2 构建ATP验证矩阵表：用Excel固化检查逻辑
为避免每次测试都手动记笔记，我习惯用Excel建一张ATP验证矩阵，横向为日期（20200619~20200630），纵向为数据类型：
| 日期 | 非限制库存 | 预留（20200621） | PO（20200625） | ATP可用量 | 实际结果 | 备注 |
|---|---|---|---|---|---|---|
| 20200619 | 100 | 0 | 0 | 100 | OK | 基准日 |
| 20200620 | 100 | 80 | 0 | 20 | 报错 | 需求30>20 |
| 20200621 | 100 | 80 | 0 | 20 | OK | 预留生效日 |
| 20200625 | 100 | 80 | 50 | 70 | OK | PO到货日 |
| 20200626 | 100 | 80 | 50 | 70 | OK | 需求30<70 |
这张表的作用是：
- 暴露逻辑断点：若20200625 ATP可用量不是70，说明PO未被识别，立刻查PO日期或OVZ2配置；
- 支撑UAT签字：业务方质疑“为什么20号不行26号行”，直接出示此表，比讲10分钟原理更管用；
- 沉淀知识资产：项目交接时，这张表比配置文档更直观。
6.3 终极验证：用BAPI_AVAILABILITY_CHECK模拟前台调用
当MD04和前台操作结果不一致（极少见，但发生过），需深入到底层API验证。SAP提供标准BAPIBAPI_AVAILABILITY_CHECK，可完全复现前台ATP逻辑：
# Python调用示例（需安装pyrfc） from pyrfc import Connection conn = Connection( ashost="your-sap-host", sysnr="00", client="100", user="RFC_USER", passwd="RFC_PASS" ) # 构造ATP请求参数 atp_params = { "MATERIAL": "G0120030", "PLANT": "1000", "STGE_LOC": "A001", "REQ_DATE": "20200626", "REQ_QTY": "30.000", "CHECK_GROUP": "ZATP01", # 显式指定检查组 "CHECK_TYPE": "D" # 动态检查 } result = conn.call("BAPI_AVAILABILITY_CHECK", **atp_params) print("ATP Result:", result["AVAILABILITY"]) # 输出：{'AVAILABILITY': 'X'} 表示可用，' '表示不可用参数说明：
CHECK_GROUP必须显式传入，否则BAPI使用缺省组；REQ_DATE格式必须为YYYYMMDD字符串；REQ_QTY需带小数位（如"30.000"）。此方法能100%复现前台逻辑，是排查“配置没错但前台异常”的后悔药。
从那以后我每次上线新工厂的ATP功能，都强制走一遍这三步：先用MD04跑通基准数据，再填一张Excel验证矩阵，最后用BAPI写个自动化脚本每天凌晨校验关键物料。不是信不过配置，而是信不过人脑对时序逻辑的记忆力。希望帮到你。
本文还有配套的精品资源，点击获取
