先讲个我经常遇到的场景：销售在系统里看到物料库存明明有100件，客户下了80件的单子，他却不敢承诺，因为另一位计划员昨天已经用预留把这批货“占住”了。这个“占住”的动作，在SAP里就是预留（Reservation），而系统用来判断“到底还能不能接单”的机制，就是ATP可用性检查（Available to Promise）。这篇文章我打算把ATP从配置到应用完整串一遍，重点落在BAPI_RESERVATION_CREATE1这个最常用的预留创建接口上，把配置逻辑、参数结构、调用示例和排错经验一次讲透。适合SAP MM/PP/SD模块顾问、ABAP开发以及刚接触可用性检查的运维同事参考。

1. ATP检查在解决什么问题：先看透可用量这盘账

1.1 一件“有库存却没法承诺”的糟心事

很多刚接触ATP的同事会把“库存数量”和“可用数量”当成一回事，这是最大的误区。库存数量是仓库里实实在在躺着多少货，可用数量是“现在还能自由承诺多少货”。两者之间差着什么呢？差着已经被其他单据占用的量，也差着即将到达仓库的量。

举个例子：

• 现有库存：100件
• 未发货的预留：30件
• 已确认的销售订单：20件
• 在途采购订单：40件（三天后到货）

那今天的可用量是多少？100 - 30 - 20 = 50件外加三天后到货40件。如果销售今天要给客户承诺60件，系统就会告诉你：不够。因为今天能发的只有50件，剩下10件要等三天后的采购收货。

这就是ATP存在的意义：在时间轴上动态判断“某个需求日期，我能不能兑现这个承诺”。它不是在仓库实物层面做校验，而是在计划层面做校验。

1.2 ATP和PAC：两个容易混的“可用性”

SAP里的可用性检查其实有两条线，一条是ATP（Available to Promise，可用量承诺），一条是PAC（Product Allocation，产品分配/配额）。PAC按客户、产品组等维度分配可销售配额，ATP则看库存和供需的时序账。实际项目里，有人把产品分配的“配额不足”也归到ATP头上，排查半天才发现走错了模块。

本文的ATP指的就是“可用量承诺”这条线，它关注的元素包括：库存、采购订单、采购申请、计划订单、生产订单、销售订单、预留等。理解了这些元素怎么进出可用量，后面的配置和BAPI才讲得通。

1.3 可用量不是“所有库存相加”，而是一笔时间账

SAP的ATP计算不是简单地“现有库存 + 所有收货 - 所有需求”，而是按日期滚动计算。在MD04（库存/需求清单）里，你能很直观地看到每一天的入库、出库、可用量变化。

核心公式是：

可用量（某日期）= 现有库存 + 计划收货（该日期及之前） - 计划需求（该日期及之前）

这个公式看起来简单，但有两个关键点：

1. 收货和需求都有“归属日期”。采购订单有交货日期，预留有需求日期，销售订单有计划交货日期。系统按这些日期把数落到时间轴上。
2. 检查范围决定了什么算、什么不算。比如有的公司希望把安全库存留作缓冲，不参与可用量计算；有的公司希望把质量检验库存排除在外，因为这部分库存还不能直接发货。这些都是在检查范围里配置的。

ATP检查还有一个容易被忽略的特性：静态检查和动态检查。静态检查只看某一时间点上的“现有库存 + 收货”是否足够满足这个时间点的需求，不考虑未来的其他需求占用；动态检查则会看未来的需求序列，这是销售订单ATP里常用的方式。生产中做可用性检查时，很多配置差异就出在这里——选了不适合的检查类型，业务上就会出现“明明后面有预留，系统却照样承诺”的怪现象。

2. 可用性检查配置的三层结构：检查范围、检查规则与需求类型

2.1 配置链路先理顺：三层关系

ATP的配置在SAP里不是孤立的，它由三层结构组成：

• 检查范围（Checking Scope）：定义哪些元素参与可用量计算。库存是否包含安全库存？收货是否包含采购申请？需求是否包含预留？
• 检查规则（Checking Rule）：一组检查范围的组合。一个规则代表一种检查策略，比如“面向库存销售”“面向订单生产”。
• 需求类型/项目类别与检查规则的分配：把规则绑定到具体业务单据上。比如销售订单的某一行项目类别用规则03，生产订单预留用规则01。

打个比方：检查范围是菜单里的菜品，检查规则是一份套餐，需求类型的分配决定哪位顾客点哪份套餐。很多顾问只改了套餐，没换顾客的菜单，结果配置了等于没配置。

2.2 OVZ1定义检查范围：决定哪些元素进可用量

调用事务代码 OVZ1，可以看到可用性检查的检查范围定义界面。这里要按“检查类型”（如销售订单可用性检查01、生产可用性检查02等）来定义参与计算的元素。 常见的元素包括：

配置时要特别注意：同一个元素，在收货途中是“收入”，在需求侧就是“支出”。比如计划订单，它既是未来收货，也会因为它的组件需求而产生下层物料的需求。如果检查范围没配好，很容易出现“同一个计划订单既让可用量增加，又没让它的组件需求占用可用量”的账目失衡。

2.3 OVZ2定义检查规则：把检查范围包成套餐

事务代码 OVZ2 里可以看到SAP预置的检查规则，比如规则01（适用于按库存生产）、规则02（适用于按订单生产）、规则03（适用于面向订单生产的销售订单）等。每个规则背后挂着一套检查范围。

在新配置一个检查规则时，要考虑清楚这几个问题：

• 这个规则是用于销售订单、生产订单，还是库存转移预留？
• 检查粒度是“按单行检查”还是“按需求汇总检查”？
• 如果需求超过可用量，是只提示警告，还是直接报错？
• 检查时考虑“补货提前期”吗？即在需求日期前能否通过采购/生产来补足？

这些问题决定了业务在执行时是“柔性承诺”还是“刚性拦截”。我在项目上见过一个典型配置错误：把规则设成严格报错，结果销售订单在创建时被各种拦截，因为很多物料都有历史预留占用；业务员怨声载道，最后才发现是检查范围里把“预留”也纳入了需求，而且规则设成了错误级别。

2.4 OVZ9分配规则：让业务单据找到正确套餐

配置好规则以后，还要通过 OVZ9 把规则分配给需求类型或项目类别。比如销售订单的需求类型“KL”（面向库存销售）可以分配规则01，需求类型“KE”（面向订单生产）可以分配规则02。这样同一公司代码下，不同类型的订单可用不同的ATP策略。

在生产模块里，移动类型也可以绑定检查规则。比如281移动类型（生产订单预留）分配规则01，201移动类型（成本中心领料预留）分配规则02。这里就进入本文最关心的领域了——预留才是ATP在计划层占用可用量的核心单据。

实际操作中，建议先用MD04查看某个物料的库存/需求清单，再在OVZ9里调整分配并对比效果，不要一次性改一大批规则。因为可用性检查的配置是“改动影响面极大”的，一个规则的调整可能让所有关联订单的承诺行为发生变化。

3. 预留（Reservation）如何进入ATP需求视图：MD04/MD07里的逻辑

3.1 预留到底是什么

预留（Reservation）在SAP里是“未来要发生却没有发生”的物料需求记录。它告诉系统：某部门在某个日期要领取某物料若干，或者某个项目在某个阶段要消耗某物料若干。它不改变任何库存数量，但它在计划层面“占坑”。

后台表是RESB。每次创建预留，系统会在RESB里生成一条或多条记录。这个表也是很多报表和BAPI的核心表。

3.2 预留为什么会影响ATP可用量

前面说了ATP是“现有库存 + 计划收货 - 计划需求”。预留就是“计划需求”的重要组成部分。当你在MD04里打开某个物料，你会看到预留作为一行“需求”出现在对应日期下。它不占实物库存，但占可用量。

举个例子，物料A库存100件：

• 一张销售订单需求30件（交货日期今天）
• 一张预留需求40件（需求日期今天）

那么今天可用量 = 100 - 30 - 40 = 30件。系统在销售订单ATP检查时，会看到可用量只剩30件，再有人想下50件的单，就承诺不了。

这就是为什么“创建预留”这个动作本身虽然没有从仓库搬走一件货，却会让整个供应链承诺能力瞬间下降。理解了这一点，你才能理解为什么BAPI_RESERVATION_CREATE1在ATP体系里这么重要。

3.3 用MD04看预留的“时间位置”

MD04是单物料视图，MD07是多物料汇总视图。对顾问和运维来说，MD07比MD04更适合做批量验证。它按物料、工厂、库存地点显示库存和需求汇总，能看多个物料的可用量状况。

在MD04中定位一张预留，你会看到类似这样的信息：

• 需求元素：预留 0000012345 / 0001
• 移动类型：261
• 需求数量：40件
• 需求日期：今天
• 可用量：30件

预留的需求日期非常关键。同样是40件的预留，如果需求日期是今天，可用量立刻减40；如果需求日期是下个月，那今天的可用量可能不受影响。这就是ATP的时间轴逻辑。

3.4 手动创建预留与接口创建预留的差异

手动创建预留可以用MB21，界面直观，适合少量操作和测试。接口创建预留就要用BAPI_RESERVATION_CREATE1，适合批量导入、系统集成、外围系统联动等场景。两者创建的预留，在SAP后台都是RESB记录，对ATP的影响完全一致。

但有一个细节容易踩坑：手动创建时系统会自动帮你带出很多默认值（比如移动类型的默认科目、成本中心默认值），但调用BAPI时这些值不会自动带出，必须显式传入。这就是为什么很多接口第一次调BAPI创建预留，都会报“科目确定失败”或者“成本中心不能为空”这类错误。

3.5 预留类型与移动类型对ATP的影响

预留类型（Reservation Type，RES_TYPE）在BAPI里是一个容易出现歧义的字段。常见取值包括空值（手动预留）、F（生产订单预留）、A（资产相关预留）等。不同预留类型，决定了预留对应的后续业务场景。

移动类型则决定了预留是“发货预留”还是“收货预留”。例如：

• 261：生产订单发货
• 201：成本中心领料
• 311：库存转移（转出方预留）

在ATP可用性检查中，这些移动类型的预留都会作为需求元素占用可用量。但311这类转移类预留还涉及“转出工厂可用量减少，转入工厂可用量增加”的连锁反应，配置时要额外关注。

4. BAPI_RESERVATION_CREATE1一步一步调通：参数细节与ABAP示例

4.1 为什么选CREATE1而不是CREATE

SAP提供了两个经典的预留创建BAPI：

• BAPI_RESERVATION_CREATE：老版本，基于抬头结构创建单行预留。
• BAPI_RESERVATION_CREATE1：新版本，支持通过RESERVATION_ITEMS表传入多行项目，灵活性更强。

实际项目里我基本都用CREATE1，即使只创建一行，也统一走多行表，代码结构更清晰，后续扩展多行也方便。而且CREATE1的返回参数包含了生成的RESB表数据，可以用于进一步校验。

4.2 核心参数结构拆解

BAPI_RESERVATION_CREATE1的参数大致如下：

这里我要特别强调一个容易犯错的地方：RESERVATION_ITEMS和RESERVATION_ITEMSX两张表必须一一对应。如果只传ITEM不传X，BAPI会报“未定义更新标记”；如果X传的字段与ITEM不一致，也容易出现“数值无效”之类的消息。最简单可靠的方式是：ITEM传哪些字段，X里就把哪些字段置为‘X’。

RESERVATION结构里还有几个业务上高频使用的字段：

• MATERIAL：物料号
• PLANT：工厂
• MOVE_TYPE：移动类型
• QUANTITY：数量
• REQUIREMENT_DATE：需求日期
• COSTCENTER：成本中心（261/201领料时常用）
• ORDERID：生产订单号（与261配套）
• RES_TYPE：预留类型

4.3 单行预留创建示例（ABAP）

下面是一段可以直接参考的ABAP代码，逻辑清晰，注释完整：

DATA: ls_reservation TYPE bapi_reservation_create, ls_reservationx TYPE bapi_reservation_createx, lt_items TYPE STANDARD TABLE OF bapi_reservation_items, lt_itemsx TYPE STANDARD TABLE OF bapi_reservation_itemsx, lt_return TYPE STANDARD TABLE OF bapiret2, lt_resb TYPE STANDARD TABLE OF resb, lv_res_no TYPE bapi_reservation_create-reservation. ls_reservation-material = 'M-10001'. ls_reservation-plant = '1000'. ls_reservation-move_type = '261'. ls_reservation-quantity = '10'. ls_reservation-require_date = sy-datum. ls_reservation-res_type = ''. ls_reservation-costcenter = '10001111'. ls_reservationx-material = 'X'. ls_reservationx-plant = 'X'. ls_reservationx-move_type = 'X'. ls_reservationx-quantity = 'X'. ls_reservationx-require_date = 'X'. ls_reservationx-costcenter = 'X'. APPEND INITIAL LINE TO lt_items ASSIGNING FIELD-SYMBOL(<fs_item>). <fs_item>-material = ls_reservation-material. <fs_item>-plant = ls_reservation-plant. <fs_item>-move_type = ls_reservation-move_type. <fs_item>-quantity = ls_reservation-quantity. <fs_item>-require_date = ls_reservation-require_date. <fs_item>-costcenter = ls_reservation-costcenter. APPEND INITIAL LINE TO lt_itemsx ASSIGNING FIELD-SYMBOL(<fs_itemx>). <fs_itemx>-material = 'X'. <fs_itemx>-plant = 'X'. <fs_itemx>-move_type = 'X'. <fs_itemx>-quantity = 'X'. <fs_itemx>-require_date = 'X'. <fs_itemx>-costcenter = 'X'. CALL FUNCTION 'BAPI_RESERVATION_CREATE1' EXPORTING reservation = ls_reservation reservationx = ls_reservationx IMPORTING reservation = lv_res_no resb = lt_resb TABLES reservation_items = lt_items reservation_itemsx = lt_itemsx return = lt_return. IF lv_res_no IS NOT INITIAL. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'. WRITE: / '预留创建成功:', lv_res_no. ELSE. LOOP AT lt_return INTO DATA(ls_return) WHERE type = 'E'. WRITE: / ls_return-message. ENDLOOP. ENDIF.

代码里有个关键点：即使你在RESERVATION抬头里已经传了物料和数量，也建议在RESERVATION_ITEMS里显式传一遍。有些版本中，抬头结构和行项目表同时存在时，系统以行为准。宁可多传，也不要赌它忽略其中一处。

4.4 多行预留创建示例

多行预留的写法只是在填表时循环添加多行，其他参数不变：

LOOP AT lt_input INTO DATA(ls_input). APPEND INITIAL LINE TO lt_items ASSIGNING <fs_item>. <fs_item>-material = ls_input-matnr. <fs_item>-plant = ls_input-werks. <fs_item>-move_type = ls_input-bwart. <fs_item>-quantity = ls_input-menge. <fs_item>-require_date = ls_input-bedat. IF ls_input-kostl IS NOT INITIAL. <fs_item>-costcenter = ls_input-kostl. ENDIF. APPEND INITIAL LINE TO lt_itemsx ASSIGNING <fs_itemx>. <fs_itemx>-material = 'X'. <fs_itemx>-plant = 'X'. <fs_itemx>-move_type = 'X'. <fs_itemx>-quantity = 'X'. <fs_itemx>-require_date = 'X'. IF ls_input-kostl IS NOT INITIAL. <fs_itemx>-costcenter = 'X'. ENDIF. ENDLOOP. CALL FUNCTION 'BAPI_RESERVATION_CREATE1' EXPORTING reservation = ls_reservation reservationx = ls_reservationx IMPORTING reservation = lv_res_no TABLES reservation_items = lt_items reservation_itemsx = lt_itemsx return = lt_return.

多行预留创建后，SAP会生成一个预留号，下面挂多个行项目。在MD04里可以看到预留号下的每行需求，这对后续MIGO按预留发货非常有帮助。

4.5 返回数据处理：别只看“有没有预留号”

很多开发判断BAPI是否成功，只看导出的预留号是否为空，这是不够严谨的。预留号非空只能说明BAPI执行到了生成预留的步骤，并不能代表所有行都成功。

正确做法是：

1. 检查RETURN表里有没有类型为‘E’的消息。
2. 用导出的RESB表（实际写入的预留行）与输入项逐条核对数量、工厂、物料。
3. 再提交事务（BAPI_TRANSACTION_COMMIT）。

在多行场景下，如果其中一行有错误但其他行成功，系统可能返回部分成功。此时必须把错误的行挑出来回滚或重试，不能直接当成全部成功。

4.6 一个“教科书里没写”的关系：预留与ATP的联动点

再说一个容易迷糊的点：BAPI_RESERVATION_CREATE1本身不会触发ATP可用性检查，它只创建预留需求记录。真正看到预留对ATP的影响，要等后续销售订单ATP运行时，系统自动把预留作为已有需求占用可用量。

也就是说，调BAPI时系统不会告诉你说“创建这个预留会让某某订单无法承诺”。预留就像一个安静的需求“钉子”，暂时不可见，但会在MD04、MD07、销售订单ATP里默默起作用。想要主动验证可用量变化，可以用BAPI_MATERIAL_AVAILABILITY或者在MD04里观察前后可用量差。

5. 排错记录：BAPI创建预留失败的常见原因与排查链路

5.1 报错“维护预留抬头数据/行项目数据”

这是一个很通用的报错，出现原因是抬头结构和行项目表数据不一致，或者两者都没传有效数据。排查方向：

1. 确认RESERVATION_ITEMS里至少有一行物料、工厂、数量非空。
2. 确认RESERVATION_ITEMSX里对应的行索引与RESERVATION_ITEMS一致。
3. 确认抬头结构里没有填一个与行项目冲突的数量或物料。

如果抬头和行项目都传了，一定要保证它们“讲同一个故事”。比如抬头里物料是M-10001，行项目里却是M-10002，系统就会认为数据矛盾。

5.2 报错“科目确定失败”或“成本中心不能为空”

这类错误常见于261（生产订单发货）或201（成本中心领料）移动类型。BAPI无法从界面自动获取成本对象，必须显式传入：

• 261通常要传ORDERID（生产订单号）
• 201通常要传COSTCENTER（成本中心）或内部订单
• 特殊库存业务还要传SOBKZ

排错时先看移动类型对应的“科目分配类别”，在BAPI里叫ACCTASSCAT。常见取值：

• K：成本中心
• F：订单
• A：资产
• P：项目
• U：未知（不需要科目分配）

如果科目分配类别没传或传错，系统根本找不到记账规则，预留自然创建不出来。

5.3 报错“没有允许该移动类型的库存类型”或“特殊库存类型无效”

移动类型与特殊库存（SOBKZ）的组合，决定了预留是否允许某种BAPI调用。比如：

• 普通库存（SOBKZ为空）：常规预留
• 寄售库存（SOBKZ=K）：通常用于客户寄售场景
• 管道库存（SOBKZ=P）：管道业务
• 在途库存（SOBKZ=E）：跨工厂转储

调用BAPI时，如果业务物料需要特殊库存，必须在ITEM里传入SOBKZ，否则系统默认按普通库存校验。这里建议先查表T156（移动类型）和T157（移动类型-科目确定）确认组合是否有效。

5.4 预留创建成功但MD04里看不到

这种问题在接口上线初期特别多。预留创建成功了，但业务在MD04里怎么都看不到，排查链路如下：

1. 确认筛选条件：MD04的视图范围是否包含“预留”，有的用户只勾选了“销售/采购需求”，忘了勾预留。
2. 确认工厂和库存地点：预留创建在工厂1000，MD04却查工厂2000，当然看不到。
3. 确认需求日期：预留需求日期如果被传成未来半年，默认视图可能没显示那么远。
4. 确认后台RESB表：查RESB里有没有RSNUM对应的记录。如果RESB有，MD04没有，多半是视图显示问题或缓存问题。

5.5 BAPI成功，但预留数量与业务预期不一致

比如传了“10 PC”，系统里却显示“10 ST”。这是单位换算问题。物料主数据的基本单位是ST，BAPI传入PC，系统按换算关系转成ST并存储。数量值本身没有错，但显示单位和业务预期不一致时会造成误导。

解决办法是：调用前确认传入单位与物料主数据基本单位一致，或程序里先做单位换算。可以用函数MD_CONV_MATERIAL_UNIT或直接查表MARM。

5.6 排错路径总结

我自己在项目上的排错习惯，按下面顺序走，90%的问题都能定位：

1. 先看RETURN消息，把MESSAGE_TYPE为E的行全部列出来 2. 用事务代码MB21手动创建一张同样的预留，看能不能成功 3. 如果MB21能成功，对比手动创建与BAPI传参的差异 4. 查T156/T157确认移动类型与科目分配、特殊库存是否匹配 5. 查RESB看数据是否写入，查MD04看是否可见 6. 用事务代码MD07核对多物料汇总下的可用量变化

6. 预留与ATP集成的业务设计经验：给关键决策提个醒

6.1 什么时候要用预留，什么时候不用

预留的本质是“锁定未来需求”。但并非所有需求都应该以预留方式创建。

推荐用预留的场景：

• 生产订单已经下达，所需物料已经确定，需要锁定可用量防止被销售订单抢走。
• 项目领料与成本中心领料已经审批通过，需要在系统里记录计划消耗。
• 跨工厂调拨或转储，需要在转出方建立需求。
• 与外部系统（EAM、MES、WMS）集成，由外围系统把领料需求传给SAP。

不推荐用预留的场景：

• 单纯想“查一下库存够不够”，应该用ATP检查BAPI（如BAPI_MATERIAL_AVAILABILITY），而不是创建预留。
• 预测性需求，应该用计划独立需求（PIR），由MRP统一评估。
• 尚未审批、还在评审阶段的领料需求，建议先在线下沟通，盲目创建预留会占用可用量，影响真实订单。

6.2 S/4HANA新ATP下还适用吗

S/4HANA之后，SAP引入了嵌入式ATP（Embedded ATP），在SAP S/4HANA 2020以后还有了新的事务代码和界面（比如可用性检查的配置入口从OVZ1/OVZ2逐步迁移到新界面，部分客户使用ATC事务代码管理ATP服务器）。但RESB表、预留逻辑、BAPI_RESERVATION_CREATE1接口依然可用。

区别在于：

• 可用量计算方式更高效，但“预留占可用量”的基本原则没变。
• 检查范围配置界面的字段顺序和名称有变化，但“检查范围、检查规则、需求类型分配”的逻辑骨架依然存在。
• S/4里MD04/MD07还在，但表现层和部分字段有调整。

如果你最近在升级S/4项目，建议重点验证三件事：一是历史预留是否有遗留数据问题，二是新ATP配置下261/201/281等移动类型的预留是否按预期占用可用量，三是BAPI_RESERVATION_CREATE1在升级后返回的消息类型是否有变化（比如原来警告现在变错误，或反过来）。

6.3 用MD07做上线前的可用量验证

每次做完ATP或预留的配置调整，我都会做一轮“前后对比”验证。具体做法是：

1. 在MD07里导出当前所有物料的库存/需求汇总，记为基线。
2. 通过BAPI_RESERVATION_CREATE1创建一批预留。
3. 再跑一次MD07导出，对比同一物料的可用量变化。
4. 如果可用量下降值等于预留需求值，说明链路是通的。
5. 如果下降值大于或小于预期，立刻排查检查范围里是否多纳入了元素或漏掉了元素。

这个方法比单纯看RETURN消息可靠得多，因为它验证的是整个ATP业务链路，而不仅仅是BAPI本身的执行。

6.4 几条“带过血”的经验

最后分享几条我在项目里总结出来的经验，都是踩过坑才记住的：

第一，需求日期一定要传业务真实日期。很多开发在测试时随手传SY-DATUM，上线后也懒得改，结果所有预留都落在当天，可用量被瞬间打爆，MRP跑出来的采购建议一团糟。

第二，RESERVATIONX和RESERVATION_ITEMSX不要嫌麻烦省略。有些开发只传RESERVATION，不传X结构，偶尔能跑通，但一旦SAP版本升级或遇到特殊移动类型，就会出现“字段无更新标记”的诡异报错。规范写法永远是最省心的。

第三，预留创建后要定期清理。创建了预留但长期不发货，会一直占用可用量。很多公司库存明明不缺，销售却一直接不了单，排查半天发现是一堆过期预留占着可用量。在MD07里能看到这些“僵尸预留”，业务上要和计划部门确认后及时删除或用MB22修改。

第四，接口调用前先做BAPI的权限检查。BAPI_RESERVATION_CREATE1涉及到物料、工厂、移动类型、科目分配等多个权限对象，外围系统集成用户经常会遇到“部分工厂无权限”的报错。项目上线前把接口用户的权限矩阵列出来，逐项测试，比上线后再补权限要省事得多。

我在实际项目里发现，ATP和预留这套机制，真正难的不是配置或代码，而是业务部门没意识到“预留也会占用可用量”这件事。每次上线前，我都会拉着计划、销售、仓库一起看MD07的汇总报表，演示一次“创建预留后销售订单ATP结果变化”的全过程。当大家都理解了预留不是“记个账”而是“占个坑”，很多关于可用量的扯皮自然就少了。这套从配置到BAPI落地的路径，如果你也在做SAP的可用性检查项目，完全可以直接拿来复制。