1. 先说个业务背景STO到底卡在哪做SAP供应链这些年STOStock 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 库存转移订单的业务逻辑拆解先拆一下单据流。公司间STOIBT从业务形态上看像极了采购流程收货方工厂作为“采购方”建一张采购订单供应商其实是“兄弟工厂/关联公司”。但和真正的供应商采购不同这张订单不会触发真实的外部采购它走的是内部的货物移动和公司间结算。关键点在哪在于这张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、VBUKBAPI返回成功后不要只看了交货单号就完事。公司间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看如果PSTYP9一般对应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甚至EWMSTO交货单创建只是第一步。系统会根据交货单和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关联提前做检测。这一点在上线后的日常运维中非常起作用别等出了重复交货单再去找程序员改代码那是很痛的教训。