先讲个我经常遇到的场景销售在系统里看到物料库存明明有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里的可用性检查其实有两条线一条是ATPAvailable to Promise可用量承诺一条是PACProduct Allocation产品分配/配额。PAC按客户、产品组等维度分配可销售配额ATP则看库存和供需的时序账。实际项目里有人把产品分配的“配额不足”也归到ATP头上排查半天才发现走错了模块。本文的ATP指的就是“可用量承诺”这条线它关注的元素包括库存、采购订单、采购申请、计划订单、生产订单、销售订单、预留等。理解了这些元素怎么进出可用量后面的配置和BAPI才讲得通。1.3 可用量不是“所有库存相加”而是一笔时间账SAP的ATP计算不是简单地“现有库存 所有收货 - 所有需求”而是按日期滚动计算。在MD04库存/需求清单里你能很直观地看到每一天的入库、出库、可用量变化。核心公式是可用量某日期 现有库存 计划收货该日期及之前 - 计划需求该日期及之前这个公式看起来简单但有两个关键点收货和需求都有“归属日期”。采购订单有交货日期预留有需求日期销售订单有计划交货日期。系统按这些日期把数落到时间轴上。检查范围决定了什么算、什么不算。比如有的公司希望把安全库存留作缓冲不参与可用量计算有的公司希望把质量检验库存排除在外因为这部分库存还不能直接发货。这些都是在检查范围里配置的。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移动类型生产订单预留分配规则01201移动类型成本中心领料预留分配规则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 TypeRES_TYPE在BAPI里是一个容易出现歧义的字段。常见取值包括空值手动预留、F生产订单预留、A资产相关预留等。不同预留类型决定了预留对应的后续业务场景。移动类型则决定了预留是“发货预留”还是“收货预留”。例如261生产订单发货201成本中心领料311库存转移转出方预留在ATP可用性检查中这些移动类型的预留都会作为需求元素占用可用量。但311这类转移类预留还涉及“转出工厂可用量减少转入工厂可用量增加”的连锁反应配置时要额外关注。4. BAPI_RESERVATION_CREATE1一步一步调通参数细节与ABAP示例4.1 为什么选CREATE1而不是CREATESAP提供了两个经典的预留创建BAPIBAPI_RESERVATION_CREATE老版本基于抬头结构创建单行预留。BAPI_RESERVATION_CREATE1新版本支持通过RESERVATION_ITEMS表传入多行项目灵活性更强。实际项目里我基本都用CREATE1即使只创建一行也统一走多行表代码结构更清晰后续扩展多行也方便。而且CREATE1的返回参数包含了生成的RESB表数据可以用于进一步校验。4.2 核心参数结构拆解BAPI_RESERVATION_CREATE1的参数大致如下参数方向类型说明RESERVATION导入BAPI_RESERVATION_CREATE预留抬头数据也可作为默认单行数据RESERVATIONX导入BAPI_RESERVATION_CREATEX预留抬头字段更新标记RESERVATION_ITEMS表BAPI_RESERVATION_ITEMS预留行项目表RESERVATION_ITEMSX表BAPI_RESERVATION_ITEMSX行项目更新标记表RESERVATION导出数字生成的预留号RESERVATION_ITEMS导出表行项目编号等RESB导出表写入后台表RESB的行数据RETURN返回BAPIRETURN执行消息这里我要特别强调一个容易犯错的地方RESERVATION_ITEMS和RESERVATION_ITEMSX两张表必须一一对应。如果只传ITEM不传XBAPI会报“未定义更新标记”如果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执行到了生成预留的步骤并不能代表所有行都成功。正确做法是检查RETURN表里有没有类型为‘E’的消息。用导出的RESB表实际写入的预留行与输入项逐条核对数量、工厂、物料。再提交事务BAPI_TRANSACTION_COMMIT。在多行场景下如果其中一行有错误但其他行成功系统可能返回部分成功。此时必须把错误的行挑出来回滚或重试不能直接当成全部成功。4.6 一个“教科书里没写”的关系预留与ATP的联动点再说一个容易迷糊的点BAPI_RESERVATION_CREATE1本身不会触发ATP可用性检查它只创建预留需求记录。真正看到预留对ATP的影响要等后续销售订单ATP运行时系统自动把预留作为已有需求占用可用量。也就是说调BAPI时系统不会告诉你说“创建这个预留会让某某订单无法承诺”。预留就像一个安静的需求“钉子”暂时不可见但会在MD04、MD07、销售订单ATP里默默起作用。想要主动验证可用量变化可以用BAPI_MATERIAL_AVAILABILITY或者在MD04里观察前后可用量差。5. 排错记录BAPI创建预留失败的常见原因与排查链路5.1 报错“维护预留抬头数据/行项目数据”这是一个很通用的报错出现原因是抬头结构和行项目表数据不一致或者两者都没传有效数据。排查方向确认RESERVATION_ITEMS里至少有一行物料、工厂、数量非空。确认RESERVATION_ITEMSX里对应的行索引与RESERVATION_ITEMS一致。确认抬头结构里没有填一个与行项目冲突的数量或物料。如果抬头和行项目都传了一定要保证它们“讲同一个故事”。比如抬头里物料是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为空常规预留寄售库存SOBKZK通常用于客户寄售场景管道库存SOBKZP管道业务在途库存SOBKZE跨工厂转储调用BAPI时如果业务物料需要特殊库存必须在ITEM里传入SOBKZ否则系统默认按普通库存校验。这里建议先查表T156移动类型和T157移动类型-科目确定确认组合是否有效。5.4 预留创建成功但MD04里看不到这种问题在接口上线初期特别多。预留创建成功了但业务在MD04里怎么都看不到排查链路如下确认筛选条件MD04的视图范围是否包含“预留”有的用户只勾选了“销售/采购需求”忘了勾预留。确认工厂和库存地点预留创建在工厂1000MD04却查工厂2000当然看不到。确认需求日期预留需求日期如果被传成未来半年默认视图可能没显示那么远。确认后台RESB表查RESB里有没有RSNUM对应的记录。如果RESB有MD04没有多半是视图显示问题或缓存问题。5.5 BAPI成功但预留数量与业务预期不一致比如传了“10 PC”系统里却显示“10 ST”。这是单位换算问题。物料主数据的基本单位是STBAPI传入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引入了嵌入式ATPEmbedded 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或预留的配置调整我都会做一轮“前后对比”验证。具体做法是在MD07里导出当前所有物料的库存/需求汇总记为基线。通过BAPI_RESERVATION_CREATE1创建一批预留。再跑一次MD07导出对比同一物料的可用量变化。如果可用量下降值等于预留需求值说明链路是通的。如果下降值大于或小于预期立刻排查检查范围里是否多纳入了元素或漏掉了元素。这个方法比单纯看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的可用性检查项目完全可以直接拿来复制。 
长河君 · 2026/9/29 23:42:34 · 阅读 1.2k SAP ATP可用性检查与预留创建BAPI详解
先讲个我经常遇到的场景销售在系统里看到物料库存明明有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里的可用性检查其实有两条线一条是ATPAvailable to Promise可用量承诺一条是PACProduct Allocation产品分配/配额。PAC按客户、产品组等维度分配可销售配额ATP则看库存和供需的时序账。实际项目里有人把产品分配的“配额不足”也归到ATP头上排查半天才发现走错了模块。本文的ATP指的就是“可用量承诺”这条线它关注的元素包括库存、采购订单、采购申请、计划订单、生产订单、销售订单、预留等。理解了这些元素怎么进出可用量后面的配置和BAPI才讲得通。1.3 可用量不是“所有库存相加”而是一笔时间账SAP的ATP计算不是简单地“现有库存 所有收货 - 所有需求”而是按日期滚动计算。在MD04库存/需求清单里你能很直观地看到每一天的入库、出库、可用量变化。核心公式是可用量某日期 现有库存 计划收货该日期及之前 - 计划需求该日期及之前这个公式看起来简单但有两个关键点收货和需求都有“归属日期”。采购订单有交货日期预留有需求日期销售订单有计划交货日期。系统按这些日期把数落到时间轴上。检查范围决定了什么算、什么不算。比如有的公司希望把安全库存留作缓冲不参与可用量计算有的公司希望把质量检验库存排除在外因为这部分库存还不能直接发货。这些都是在检查范围里配置的。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移动类型生产订单预留分配规则01201移动类型成本中心领料预留分配规则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 TypeRES_TYPE在BAPI里是一个容易出现歧义的字段。常见取值包括空值手动预留、F生产订单预留、A资产相关预留等。不同预留类型决定了预留对应的后续业务场景。移动类型则决定了预留是“发货预留”还是“收货预留”。例如261生产订单发货201成本中心领料311库存转移转出方预留在ATP可用性检查中这些移动类型的预留都会作为需求元素占用可用量。但311这类转移类预留还涉及“转出工厂可用量减少转入工厂可用量增加”的连锁反应配置时要额外关注。4. BAPI_RESERVATION_CREATE1一步一步调通参数细节与ABAP示例4.1 为什么选CREATE1而不是CREATESAP提供了两个经典的预留创建BAPIBAPI_RESERVATION_CREATE老版本基于抬头结构创建单行预留。BAPI_RESERVATION_CREATE1新版本支持通过RESERVATION_ITEMS表传入多行项目灵活性更强。实际项目里我基本都用CREATE1即使只创建一行也统一走多行表代码结构更清晰后续扩展多行也方便。而且CREATE1的返回参数包含了生成的RESB表数据可以用于进一步校验。4.2 核心参数结构拆解BAPI_RESERVATION_CREATE1的参数大致如下参数方向类型说明RESERVATION导入BAPI_RESERVATION_CREATE预留抬头数据也可作为默认单行数据RESERVATIONX导入BAPI_RESERVATION_CREATEX预留抬头字段更新标记RESERVATION_ITEMS表BAPI_RESERVATION_ITEMS预留行项目表RESERVATION_ITEMSX表BAPI_RESERVATION_ITEMSX行项目更新标记表RESERVATION导出数字生成的预留号RESERVATION_ITEMS导出表行项目编号等RESB导出表写入后台表RESB的行数据RETURN返回BAPIRETURN执行消息这里我要特别强调一个容易犯错的地方RESERVATION_ITEMS和RESERVATION_ITEMSX两张表必须一一对应。如果只传ITEM不传XBAPI会报“未定义更新标记”如果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执行到了生成预留的步骤并不能代表所有行都成功。正确做法是检查RETURN表里有没有类型为‘E’的消息。用导出的RESB表实际写入的预留行与输入项逐条核对数量、工厂、物料。再提交事务BAPI_TRANSACTION_COMMIT。在多行场景下如果其中一行有错误但其他行成功系统可能返回部分成功。此时必须把错误的行挑出来回滚或重试不能直接当成全部成功。4.6 一个“教科书里没写”的关系预留与ATP的联动点再说一个容易迷糊的点BAPI_RESERVATION_CREATE1本身不会触发ATP可用性检查它只创建预留需求记录。真正看到预留对ATP的影响要等后续销售订单ATP运行时系统自动把预留作为已有需求占用可用量。也就是说调BAPI时系统不会告诉你说“创建这个预留会让某某订单无法承诺”。预留就像一个安静的需求“钉子”暂时不可见但会在MD04、MD07、销售订单ATP里默默起作用。想要主动验证可用量变化可以用BAPI_MATERIAL_AVAILABILITY或者在MD04里观察前后可用量差。5. 排错记录BAPI创建预留失败的常见原因与排查链路5.1 报错“维护预留抬头数据/行项目数据”这是一个很通用的报错出现原因是抬头结构和行项目表数据不一致或者两者都没传有效数据。排查方向确认RESERVATION_ITEMS里至少有一行物料、工厂、数量非空。确认RESERVATION_ITEMSX里对应的行索引与RESERVATION_ITEMS一致。确认抬头结构里没有填一个与行项目冲突的数量或物料。如果抬头和行项目都传了一定要保证它们“讲同一个故事”。比如抬头里物料是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为空常规预留寄售库存SOBKZK通常用于客户寄售场景管道库存SOBKZP管道业务在途库存SOBKZE跨工厂转储调用BAPI时如果业务物料需要特殊库存必须在ITEM里传入SOBKZ否则系统默认按普通库存校验。这里建议先查表T156移动类型和T157移动类型-科目确定确认组合是否有效。5.4 预留创建成功但MD04里看不到这种问题在接口上线初期特别多。预留创建成功了但业务在MD04里怎么都看不到排查链路如下确认筛选条件MD04的视图范围是否包含“预留”有的用户只勾选了“销售/采购需求”忘了勾预留。确认工厂和库存地点预留创建在工厂1000MD04却查工厂2000当然看不到。确认需求日期预留需求日期如果被传成未来半年默认视图可能没显示那么远。确认后台RESB表查RESB里有没有RSNUM对应的记录。如果RESB有MD04没有多半是视图显示问题或缓存问题。5.5 BAPI成功但预留数量与业务预期不一致比如传了“10 PC”系统里却显示“10 ST”。这是单位换算问题。物料主数据的基本单位是STBAPI传入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引入了嵌入式ATPEmbedded 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或预留的配置调整我都会做一轮“前后对比”验证。具体做法是在MD07里导出当前所有物料的库存/需求汇总记为基线。通过BAPI_RESERVATION_CREATE1创建一批预留。再跑一次MD07导出对比同一物料的可用量变化。如果可用量下降值等于预留需求值说明链路是通的。如果下降值大于或小于预期立刻排查检查范围里是否多纳入了元素或漏掉了元素。这个方法比单纯看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的可用性检查项目完全可以直接拿来复制。