1. 先说个业务背景，STO到底卡在哪
做SAP供应链这些年，STO（Stock Transfer Order，库存转移订单）应该是最常被问到的功能之一了。很多人一上来就问我“STO和普通采购订单到底有什么区别”“为什么公司间转储非要搞个交货单”“BAPI_OUTB_DELIVERY_CREATE_STO这一长串名字看着就头大，到底怎么用”。这些问题的背后，说白了就是一个场景：集团下面两个工厂，A工厂有货，B工厂缺货，要把货从A调到B，账要算清，货要跟上，单据链还得完整。
在这个场景里，如果两家工厂属于同一个公司代码，那是工厂间库存转储，逻辑相对简单；但如果A工厂和B工厂分属不同公司代码，业务上就变成了一笔“买卖”——A公司把货卖给B公司，这时候就不再是单纯的内部调拨，而是要走公司间交易。我在实际项目里见过很多顾问和开发在这里绕弯子，要么把STO当成普通采购订单来做收货，要么在公司间场景下还在用工厂间转储那套模式，结果凭证流缺了发票、缺了交货单，后续对账一团糟。
这里要明确的第一个概念是：STO本身就长着一张“采购订单”的脸，但它的单据类型、项目类别、检查规则和普通采购完全不是一个套路。当公司间STO创建完成之后，后续的交货、发货、收货、开票，是围着“外向交货单”来转的。而BAPI_OUTB_DELIVERY_CREATE_STO，就是SAP专门为“从STO创建公司间外向交货单”这个动作封装的函数模块。它解决的是自动化和接口化的问题——你不想每次都在VL10B里手工选单、不想让业务员在SAP GUI里点来点去，那就用这个BAPI去批量生成交货单，或者从外围系统发一个请求过来触发交货。
这个BAPI的适用人群很典型：SAP开发顾问、MM模块顾问、做外围系统接口的集成开发，以及负责企业内部供应链流程优化的人。如果你被分配到一个“自动化创建STO交货单”的需求，那这文章就是给你准备的。
2. 从业务本质看：为什么公司间STO必须走交货单
2.1 库存转移订单的业务逻辑拆解
先拆一下单据流。公司间STO（IBT）从业务形态上看，像极了采购流程：收货方工厂作为“采购方”建一张采购订单，供应商其实是“兄弟工厂/关联公司”。但和真正的供应商采购不同，这张订单不会触发真实的外部采购，它走的是内部的货物移动和公司间结算。
关键点在哪？在于这张STO的“交货方式”。如果只是工厂间转储，有些企业会简化为“一步法”——发货方直接做发货过账，收货方直接做收货过账，订单就算完了。但公司间STO是不允许这样玩的，因为这里涉及两个公司代码，涉及公司间结算价格、涉及增值税处理、涉及双方各自的库存账目。SAP的标准做法是：发货方创建外向交货单，做发货过账（也就是出库），收货方基于交货单做收货（入库），然后由系统生成一笔公司间发票（Intercompany Invoice），完成双方应收应付的清算。
也就是说，交货单是连接“发货方出库”和“收货方入库”的枢纽。没有交货单，双方的业务凭证就无法在系统里形成完整的闭环，审计的时候你会发现整个链条是断掉的。
2.2 为什么用BAPI而不是标准事务代码
标准事务代码VL10B（针对采购订单的交货处理）是MM顾问每天可能都要用的，它可以按采购订单号筛选并生成交货单，看起来很方便。但问题来了：如果企业有大量STO订单需要批量处理，或者这些订单来自外围系统（比如电商平台、SRM系统、MES系统），不可能让人每天对着GUI反复点击。标准事务代码也无法提供同步的返回值给外围系统——外围系统发完请求，需要立刻知道“交货单建出来没有”“报错在哪个环节”。
这时候就需要BAPI_OUTB_DELIVERY_CREATE_STO登场。它把VL10B的逻辑做了函数化封装，允许你在ABAP程序里直接调用，也允许你通过RFC让外围系统远程调用。返回数据里带上了创建成功的交货单号，也带上了报错信息，这样外围系统就能自动捕捉结果。这是从“人工操作”走向“系统集成”最标准的一条路。
3. BAPI_OUTB_DELIVERY_CREATE_STO核心参数拆解
3.1 最关键两个入参：STO单号与交货单类型
这个BAPI一共就两个必要的输入参数，看起来极其简单，但很多新手就挂在最简单的地方。
CALL FUNCTION 'BAPI_OUTB_DELIVERY_CREATE_STO' EXPORTING IV_DOC_NUMBER = LV_STO_NO IV_BO_NUMBER = LV_DLV_TYPE * IV_CREATE_BATCH = ' ' * IV_SUPPRESS_CREATE_BATCH_INCOMPLETE = ' ' TABLES IT_RETURN = LT_RETURN.先说IV_DOC_NUMBER，这个参数填的是STO采购订单号（不是销售订单号，也不是交货单号）。有些开发第一次接触，以为是交货单号，填了一个不存在的单号，然后找半天报错原因，其实把这个字段搞明白就省了一半排查时间。
再看IV_BO_NUMBER，这个参数填的是交货单类型。标准公司间场景下，交货单类型一般是“NL”或者“NLC”，但具体要看后台配置。这里有个非常坑的地方：有的项目复制了标准类型之后做成了自定义类型（比如ZNL），如果你在调用BAPI时不传这个参数，系统会尝试按默认规则自动确定交货单类型，很多情况下会带出一个和你预期不一致的类型，导致后续单据流走错。
我建议的做法是：在调用时明确传IV_BO_NUMBER，不要偷懒。这个参数就是用来指定“传STO创建什么类型的交货单”，传对了，后面少一堆麻烦。
3.2 SHIPMENT对象结构：处理一组交货单的关键
BAPI_OUTB_DELIVERY_CREATE_STO还有一个导出参数ES_SHIPMENT，类型为BAPISHIPMENTOBJ。这个结构用来存储系统生成的交货单信息。你有可能一次调用创建多个交货单（比如一个STO行项目特别多、库存地点不同、需要拆分交货），那么这些交货单信息就以内部表的形式放在这个结构里。
实际开发中，有的人只用IT_RETURN里的交货单号字段（注意，RETURN里未必有交货单号，别指望那里），正确的做法是从ES_SHIPMENT里取。这里的经验是：ES_SHIPMENT里有多个交货单的场景很常见，特别是当STO订单上多个行项目无法在同一个工厂/库存地点/批次下合并发货时，系统会自动拆成几张交货单。如果你在程序里直接把ES_SHIPMENT当成一个单值来处理，取到的可能只是最后一张交货单，前面的就漏掉了。
正确的处理逻辑是遍历ES_SHIPMENT的内部表，把每一张交货单号都记录下来，再继续后续的批次、WM任务创建等操作。
3.3 创建批次和反同步标志：容易被忽略的两颗雷
IV_CREATE_BATCH这个参数很有趣，它在“按批次管理”的物料场景下才真正有意义。如果你启用了批次管理，但物料主数据没有强制“创建批次”的要求，那么这个参数传空也没有问题。一旦物料是“批次必填”的，BAPI在执行时发现无法自动确定批次，就会报错。
IV_SUPPRESS_CREATE_BATCH_INCOMPLETE是一个比较少见的参数，英文全称直译是“抑制创建不完整批次的标志”。在某些情况下，系统自动创建批次时，批次主数据可能因为分类特性缺失导致不完整，标准逻辑会重新触发一个批次创建，这个参数就是用来控制这个行为的。大多数项目用不到，但如果你所在的企业启用了复杂的分类特性，并且出现“批次创建卡住”或者“交货单已生成但批次状态异常”的问题，可以回过头来检查这个参数。
这里顺手强调一下：这个BAPI的错误处理是典型的BAPI风格——报错信息放在IT_RETURN里，只有TYPE为‘E’的报错才代表“整体失败”，如果只是‘W’警告，交货单可能已经正常生成了，只是有些附属信息没补全。开发时不应该一看到RETURN里有内容就觉得失败了，要看清楚TYPE字段。
4. 实操过程：从调用BAPI到拿到交货单
4.1 一个可以直接改用的ABAP示例代码
下面这个例子来自我的实际项目，做了简化但保留了核心逻辑。场景：外围系统传入STO订单号，程序调用BAPI创建公司间交货单，然后将结果返回。
DATA: LV_STO_NO TYPE EKKO-EBELN, LV_DLV_TYPE TYPE LIKP-LIFSK, LS_SHIPMENT TYPE BAPISHIPMENTOBJ, LT_RETURN TYPE STANDARD TABLE OF BAPIRET2, LV_DLV_NO TYPE VBELN_VL. PARAMETERS: P_STO TYPE EKKO-EBELN OBLIGATORY. " 建议开发时先确认STO单据类型和交货单类型 SELECT SINGLE BSART FROM EKKO INTO @DATA(LV_BSART) WHERE EBELN = @P_STO. IF SY-SUBRC = 0. IF LV_BSART = 'UB'. LV_DLV_TYPE = 'NL'. " 公司间STO标准交货类型，实际项目以配置为准 ELSE. MESSAGE '此单据非公司间STO，请检查' TYPE 'E'. ENDIF. ENDIF. CALL FUNCTION 'BAPI_OUTB_DELIVERY_CREATE_STO' EXPORTING IV_DOC_NUMBER = P_STO IV_BO_NUMBER = LV_DLV_TYPE IMPORTING ES_SHIPMENT = LS_SHIPMENT TABLES IT_RETURN = LT_RETURN. " 取交货单号：遍历SHIPMENT对象 LOOP AT LS_SHIPMENT DELIVERY INTO DATA(LS_DLV). LV_DLV_NO = LS_DLV-DELIVERY_NUMBER. WRITE: / '交货单创建成功:', LV_DLV_NO. ENDLOOP. " 检查返回消息 LOOP AT LT_RETURN INTO DATA(LS_RETURN) WHERE TYPE = 'E'. WRITE: / '报错:', LS_RETURN-MESSAGE. ENDLOOP. IF SY-SUBRC = 0. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'. ENDIF.这个示例里有两个“额外动作”是很多人容易忽略的。
第一个是调用前检查STO单据类型。我传的是UB（公司间STO标准类型），但很多项目自定义了单据类型，比如ZUB、ZIB，如果单据类型不符合预期，后面创建交货单时项目类别确定会出问题。开发前一定要去配置表里查清楚，不要在代码里写死类型。
第二个是建议在正式调用BAPI之前用BAPI_TRANSACTION_COMMIT来提交。如果不调用提交，交货单虽然在BAPI内部生成了，但没有真正落库。调试时你会看到内表里已经有数据了，但VL10N里查不到，这种“看似没生效”的诡异现象基本都是漏了COMMIT。
4.2 调用后必查的三张表：LIKP、LIPS、VBUK
BAPI返回成功后，不要只看了交货单号就完事。公司间STO交货单涉及后续的Picking、发货过账（PGI）、公司间开票，任何一个环节的配置不对，都会在后面的流程里炸雷。
我的习惯是检查三张表：
- LIKP：确认交货单抬头存在，交货类型、发货工厂、接收工厂是否正确。
- LIPS：确认行项目完整，物料号、数量、批次、库存地点是否和STO一致。
- VBUK：确认交货单的状态，特别是“Picking状态”和“GI状态”是否为初始值。
如果你发现LIPS里行项目缺失，常见原因是STO上有些行项目的“项目类别”没有被正确确定为“TAS”（这是STO公司间特有的项目类别）。TAS项目类别意味着“库存转移的收货方，在交货时进行收货过账”，如果你后台的Item Category Determination出了问题，系统可能把它当成了普通销售订单的TAN（标准销售订单行项目），交货单虽然是建出来了，后续收货逻辑就完全不对。
检查项目类别的办法：事务代码MM03查看物料，转到“销售：一般/工厂”视图，检查“项目类别”字段，或者直接用SE16N查表TVEP、TVTAN。而STO订单行项目上的项目类别可以从EKPO-PSTYP看，如果PSTYP=9，一般对应STO相关逻辑（具体后缀要结合笔数确定）。
4.3 交货单创建后自动发货过账：为什么建议用增强
BAPI_OUTB_DELIVERY_CREATE_STO本身只创建交货单，不执行PGI（发货过账）。但在实际项目中，有很多企业希望“创建完交货单之后直接同步发货过账”，省去后来再跑VL02N或者再次调BAPI_OUTB_DELIVERY_CONFIRM_DECENTRALIZED的步骤。
要实现这个效果，有两个办法。第一个是在BAdI里做增强，在LE_SHP_DELIVERY_PROC（交货处理增强）的SAVE_VEHIKLES方法里，或者在交货单创建完成之后调用BAPI_OUTB_DELIVERY_CONFIRM_DECENTRALIZED来做发货过账。
第二个办法是直接在外面再掉一次BAPI，两个函数前后脚调用：
CALL FUNCTION 'BAPI_OUTB_DELIVERY_CONFIRM_DECENTRALIZED' EXPORTING DELIVERY = LV_DLV_NO GOODS_MOVEMENT_DATE = SY-DATUM TABLES RETURN = LT_RETURN_PGI.这里有个先后顺序的坑：如果交货单创建成功但PGI失败（比如库存不足、批次找不到、序列号缺失），这时候返回给外围系统的信息要特别小心。你如果只把“交货单创建成功”返回给外围系统，外围系统以为万事大吉，实际上后续PGI没做，实物没发出去，库存也没扣，后面再做对账就乱了。正确的做法是把BAPI创建结果和PGI结果作为一个整体业务事务来处理，任何一步失败，都要让外围系统知道整个链路没完成。
5. 常见报错与排障实录
5.1 “项目类别无法确定”类问题的祖传解法
我在支持项目里遇到最多的报错是“项目类别无法确定”或者“交货单类型无法确定”。这类问题表面上看是BAPI调用参数问题，实际上90%是后台配置缺失。
排查路径是这样的：
- 第一步，检查STO订单类型（EKPO-PSTYP），确认它的项目类别是否是9开头或特定于STO的类型。
- 第二步，看交货类型配置（Transaction代码：OVLX或者NACE查看交付类型）。
- 第三步，查项目类别确定（销售和分销→销售→销售凭证→销售凭证项目类别→定义项目类别，以及确定项目类别）。
这里面有三个后台表经常需要交叉验证：TVAP（销售凭证项目类型）、TVEP（项目类别）、TVTA（销售区域）。STO的交货单创建本质上是“销售订单”发货流程的一个特殊分支，所以后台配置都躺在SD的配置路径下面。很多MM顾问不熟悉这一块，遇到问题容易去改MM配置，结果越改越乱。
一个实用的排查技巧：事务代码VL10B手工执行一遍，看系统能不能建出交货单来。如果手工能建，那就是BAPI调用参数的问题；手工也建不出来，那肯定是后台配置有问题，BAPI不过是一个“背锅”的。
5.2 “库存不足”或“批次不一致”的坑：数量和分配
公司间STO交货单创建的时候，系统默认调用ATP检查（可用性检查）。如果发货工厂库存不够，BAPI会直接报“可用性检查未通过”之类的错。
但实际上，很多项目里的STO是不做ATP检查的，因为企业内部调拨本来就允许“先建单后补货”或者“负库存/零库存”冲销。这种场景下，如果你的BAPI调用没有正确继承STO上的检查规则，创建交货单时还是会走ATP检查，然后卡住。
解决办法是用事务代码OVZ9检查“可用性检查控制”，确认STO单据类型对应的检查规则为“空”或“无检查”；另外检查物料主数据MRP3视图的“可用性检查”字段，别让它设成了“02（个体需求）”。还有一个细节：STO交货单创建时，系统会检查“WMS/库存地点转移”，如果你为发货工厂启用了WM，却没有给它指定仓储类型、仓位，那批次还是没有办法确定，同样导致报错。
5.3 批次与序列号的特殊场景：创建了但找不到批次
启用批次管理的公司间STO，在创建交货单时，系统会尝试自动确定批次。如果物料主数据MRP4视图里“自动批次确定”没有设定，也没有指定按什么规则来选批次（比如FIFO），那么BAPI创建交货单时可能会顺利通过，但交货单里就没有批次号。后面PGI的时候系统才会报“批次缺失”。
在项目里如果遇到这种“创建成功但批次为空”的情况，不要慌张，也不要去改BAPI调用，先问业务方：批次到底是由后勤人员手工指定，还是系统自动确定？如果是手工指定，那在BAPI后面再加一步“批量库存地点转移”（BAPI_MATERIAL_AVAILABILITY或MBTransfer）就可以。如果是自动确定，检查OMB2之类的批次策略规则即可。
还有一个容易被忽略的参数IV_CREATE_BATCH：有些顾问在调用BAPI时把它传为‘X’，结果发现系统自动创建新批次，生成一个怪异的批次号，比如“批次0000000123”，前缀都是系统自动带的。业务方看着很不顺眼，其实这个参数如果传空，系统会尽量匹配已有批次而不是新建。除非你有“必须要由系统创建批次”的需求，否则这个参数建议不传。
6. 与其他SAP模块的联动：别再让交货单调成孤岛
6.1 库存可用性检查联动：从MD07说起
最近搜索词里MD07（库存/需求分析）出现得很频繁，正好和公司间STO的场景挂得上钩。MD07是MM模块查看库存/需求情况的一个利器，它能把物料在各个工厂/库存地点的库存、采购订单、销售订单、计划独立需求、交货单等全部汇总在一张表里。
如果你用BAPI_OUTB_DELIVERY_CREATE_STO创建了公司间交货单，你可以在MD07里看到这个交货单对应的“需求”数量。换句话说，MD07是验证你BAPI调用“是否正确影响物料供需平衡”的现场。很多开发为了确认BAPI是否生效，跑去用VL03N查交货单，其实在MD07里看需求变化会更直观——交货单创建后，STO需求会从“采购订单需求”转变成“交货单需求”，这个变化的出现就是“流程往前走了一步”的铁证。
反过来，如果MD07里公司间STO对应的需求一直挂在采购订单上，说明交货单根本就没建出来或者建出来后物料分配没有更新，这时候就不要继续往下查PGI了，根源还在这里。
6.2 批次和WM/EWM的钩子：和MSC3N对峙要注意什么
如果你所在企业启用了WM甚至EWM，STO交货单创建只是第一步。系统会根据交货单和WM配置生成转运单（Transfer Requirement），然后仓库人员再执行拣配、装车、发货过账。
但注意，BAPI_OUTB_DELIVERY_CREATE_STO本身完全不触发WM动作。很多刚做WM集成的同学以为建完交货单，WM那边就自动有转运单了，其实不是。系统需要你在交货单类型上配置“WM Activity”或者通过后台自动生成TR的规则才行。
我吃过这个亏：在一个项目里STO交货单建了几百张，WM那边一个TR都看不到，排障花了半天，最后发现是交货单类型没有设置WM相关的移动类型映射。给你的建议是：在项目测试阶段，建完STO交货单，马上RUN一次事务代码LTA1/LT04/LT06之类的TR创建程序，确认TR有没有出来，不要等上线后再发现。
6.3 公司间结算价格与会计凭证：不要只看交货单
最后扯一个资金层面的问题：STO公司间交货单创建之后，实物还没有移动，但财务已经在“盯着”了。
公司间STO的定价，不是看交货单里的价格，而是看STO采购订单上的“条件”记录，通常用的是NB00（标准采购价格）或者PB00，配合公司间价格方案。BAPI创建交货单时，会把STO上的价格复制到交货单行项目上，但价格条件不一定100%跟着走。你会发现交货单带出来的价格空着，或者带出来的是“0”，这种情况别急着怀疑BAPI，先看一下STO订单上的Conditions，再检查定价过程（比如事务代码M/08配置）。
等实物发运、收货完成后，系统通过公司间发票（Intercompany Billing）生成应收应付，这个动作和交货单是“各自独立”的PDF环。在实际项目中，公司间STO丢票的情况，90%出在“交货单生成OK、PGI OK、收货OK，但发票没有自动生成”。这不是BAPI能解决的问题，要去查“开票计划”“订单类型→发票类型”的映射和输出控制。
7. 一些踩过坑之后的个人体会
最后聊点实在的。我在不同项目里调用BAPI_OUTB_DELIVERY_CREATE_STO的次数，加起来也得上千次了。这个函数用熟练了，效率确实高，但前提是你要对STO的底层逻辑有足够深的理解，包括单据流、项目类别、库存分配、WM联动、发票生成。它的参数看上去只有两个，像是一个很简单朴素的门锁，但门后面的房间大得很。
我的建议是，第一次接触这个BAPI的同事，不要在ABAP调试器里反复试错，先在系统里手工把整套流程跑通：创建STO、VL10B建交货、VL02N发货过账、MIGO收货、VF01开公司间发票。等你把这一条链路都跑得滚瓜烂熟了，再来看BAPI，你会突然觉得它的参数和返回结构清晰得不能再清晰了。BAPI只是把你在GUI里的一整套操作做成了函数，它本身并不神秘，真正有价值的是你对业务流程的理解。
另外，如果你们项目里需要高频调用这个BAPI，建议在外围接口层加一层“幂等控制”。什么意思？如果外围系统因为网络超时把同一个请求发送两次，你的接口代码要能够判断“这个STO已经生成过交货单了”，直接返回已有的交货单号，而不是再创建一张重复交货单。SAP原生并没有帮你做这个去重，需要你在接口代码里通过采购订单查询交货单的方式（例如VBFA、LIKP和EKKO关联）提前做检测。这一点在上线后的日常运维中非常起作用，别等出了重复交货单再去找程序员改代码，那是很痛的教训。
