SAP批量创建外向交货单：BAPI函数清单与VL01N替代方案实战

1. 先把需求讲清楚：销售订单怎么变成出库单

做SD模块的接口和报表开发，迟早会遇到一个需求：把销售订单批量生成外向交货单，也就是常说的“根据订单创建出库单”。在SAP里，这一串动作的标准事务代码是VL01N，属于SD和LE的整合场景。很多刚接触的同事会问，这不是手工敲个回车就行吗？写程序是不是过度设计了？实际上，只要跑过几千行订单的批量交货，你就能明白，这个需求一旦出现，往往是业务量逼着你上程序。

先统一一下术语。不同行业叫法很乱，有的叫发货单，有的叫出库单，SAP标准名称是“外向交货单”，抬头表是LIKP，行项目表是LIPS，事务代码VL01N创建、VL02N修改或过账、VL03N查看。程序里做的核心动作，就是把已审批的销售订单（VBAK/VBAP）以及订单计划行（VBEP）里的交货信息，转换成一张有独立编号的外向交货单，写进LIKP/LIPS，并且在凭证流表VBFA里挂上与销售订单的前后继关系。

这个系列在第1篇里已经把订单读取、凭证流这些前置内容铺开了，这篇我就把重心放在“创建出库单”这个动作上，重点讲清楚函数清单、参数结构、完整代码示例，以及我在项目里踩过的坑。

1.1 为什么放着VL01N不用，非要写函数

手工VL01N适用于零星补单，一天几十单还行。但现实业务往往是这样：电商中台把上千张订单推给SAP，系统做完可用性检查后，物流计划部要在半小时内生成交货单，再推给仓库执行。这时候靠财务、计划员一个个敲屏幕，既不现实也容易漏单。我见过最夸张的场景是一个单子有三十多个行项目，光数量滚动就得核对半天，人工操作完全扛不住。

另外，SAP标准其实给了批量交货方案，比如事务代码VL10A、VL10B、VL10C，它们在后台也可以跑批。那为什么还要自己写函数？因为标准批量方案的筛选条件是写死的，很多客户有自己的一套规则：某些自定义字段值为空的不允许交货，信用冻结的订单要跳过，交货数量要按照客户指定比例拆分，创建完成后还要回写外部系统状态。这些诉求靠VL10的增强也能做，但维护成本高、排障不透明，项目组权衡下来往往会选择写一个自有的批量创建程序。我的建议始终是：先看标准功能能不能满足，满足不了再自研，不要一上来就写BAPI。

1.2 创建出库单涉及的数据链路和状态位

调用函数之前，先得把这个业务动作涉及的数据链路搞懂，不然排错的时候会很痛苦。

销售订单这边，抬头表VBAK里要重点关注VSTEL（发运点）、VBTYP（销售凭证类型）、LIFSK（抬头交货冻结）、VKORG等；行项目表VBAP里要看WERKS（工厂）、LFSTA（交货状态）、ABSTA（拒绝状态）、LIFSK（行项目交货冻结）、PSTYV（行项目类别）；计划行表VBEP里是WMENG（计划行数量）、BMENG（已确认数量）、EDATU（计划行日期）。交货单生成后，写进LIKP/LIPS，同时VBFA里会多出一条“交货单后单据”的凭证流记录。

比较容易被忽略的是状态表VBUK和VBUP。很多异常单，表面看数据都正常，一调用BAPI就报“交货冻结”或者“订单未释放”，其实状态就藏在这些表里。例如订单若被信用管理卡住，或者有“全部交货冻结”，VBUK里的交货状态字段会挂上冻结标识。批量创建程序里最好先查一遍这些状态，能省下很多BAPI调用费。还有可用性检查，标准流程里BAPI创建交货时会自动再做一次ATP检查，数量、日期一变，有可能出现警告甚至错误信息，这些都要在返回结构里处理。

2. 核心函数清单：一个创建动作背后还站着哪些函数

标题既然是“相关的函数列表介绍”，这部分我把实际项目里围绕“订单创建出库单”用到的函数按用途分了几类，整理成了一张清单。这也是我建议每个新人都要存一份的速查表。

下面把重点的几个展开讲。

2.1 创建主函数怎么选

创建外向交货单的主函数，标准BAPI是BAPI_OUTB_DELIVERY_CREATE_SLS。这个BAPI接收销售订单号和行项目号，核心输入是一个内表结构BAPISDLS，每个条目代表一个销售订单行，可以一次性传多行、多单。系统会按照交货类型、发运点、收货方等条件自动拆分或合并，结果在输出内表DELIVERYS里返回，如果是正常创建，里面会有交货单号。这个函数是我日常的主力。

如果是库存转储订单（STO），也就是两个工厂之间的调拨，不能直接用上面这个，要用BAPI_OUTB_DELIVERY_CREATE_STO。这两兄弟参数结构很像，但业务逻辑来源不同：一个是销售订单，一个是采购申请或转储单。项目里遇到跨工厂补货场景，别搞混了。

另外在存量系统里可能还会看到SD_DELIVERY_CREATE这个传统函数。它年纪很大，参数相对简练，也能从销售订单建交货单，但返回消息是老式结构，调试起来不如BAPI直观。新代码里不建议再用，但接手旧程序时如果看到它，要能认出来。

2.2 围绕创建动作的周边函数

BAPI本身不是一个独立事务。调用创建BAPI之后，如果业务逻辑正确，还要调BAPI_TRANSACTION_COMMIT提交，否则卢指导说的“工作台更新但数据库没提交”就会发生。提交前如果发现返回里有错误，一般调BAPI_TRANSACTION_ROLLBACK回滚。很多新手漏掉COMMIT，创建完在程序里看到的单号，跑完程序去VL02N里查却什么都没有，就是这个原因。

并发场景下还要考虑锁。交货单创建和过账都会锁表EVVBLBE，对应的函数是ENQUEUE_EVVBLBE和DEQUEUE_EVVBLBE。批量程序虽然是顺序执行的，但报表界面和定时任务可能同时触发，不加锁可能出现同一个订单被创建出两张交货单。我一般在程序开头对要处理的订单号范围加锁，创建完成再释放，比单纯靠业务校验更保险。

还有一类周边函数是消息处理。BAPI返回的RETURN是标准BAPIRET2内表，字段包括TYPE（消息类型）、ID（消息类）、NUMBER、MESSAGE以及MESSAGE_V1到V4，MESSAGE通常已经是格式化后的完整文本。如果程序还要兼容老接口，可能碰到BAPIRETURN结构，那就要用消息转换函数处理。实际项目里我更喜欢直接循环RETURN拼消息，然后扔到自建日志表或者ALV展示，既简单又直观。

2.3 创建之后：过账与确认相关函数

创建交货单只是第一步。很多项目要做的其实是“创建并过账”，也就是VL02N里那个“发货过账”动作，在交付流程里叫PGI（Post Goods Issue）。过账后库存正式减少，物料凭证产生，财务后续才能开票。

新项目中官方推荐的过账BAPI是BAPI_DELIVERYPROCESSING_EXEC和BAPI_OUTB_DELIVERY_CONFIRM_DEC。前者的签名比较绕，输入是嵌套的BAPIIDPR结构，需要填处理类型和交货单号；后者名字直白，确认拣配并过账，很多外贸或电商项目直接用它完成PGI。老系统里更常见的是WS_DELIVERY_UPDATE，这个函数直接更新交货单状态并过账，不少大客户的旧接口就是这么跑的，虽然SAP后来有了新BAPI，但这个函数仍然活跃。

这里必须提醒一句：交货过账之前，如果系统启用了WM或EWM，仓库层面的确认步骤没做，直接调过账BAPI很可能报错。所以不要急着在“创建”程序里顺手把PGI也做了。除非业务明确要求创建后立即过账并且不走仓库执行，否则我建议只创建到交货单，过账动作留给仓库或下一个接口环节。做接口设计时，把“创建”和“过账”拆成两个明确步骤，后续排障会轻松很多。

3. 实操：用BAPI_OUTB_DELIVERY_CREATE_SLS完整跑一个批量创建程序

理论讲完，上一段代码。下面这套逻辑我最近一个项目里还在用，经历了多轮需求变更，整体比较稳。虽然每家客户增强不一样，但框架可以直接抄。

3.1 参数结构和字段准备

先看BAPI_OUTB_DELIVERY_CREATE_SLS最常见的几个参数：

• SALES_ORDERS：输入表，结构BAPISDLS，每个条目对应销售订单行。字段SALES_ORDER是订单号，SALES_ORDER_ITEM是行项目号，DELIVERY_QTY是要创建的交货数量。
• DELIVERY：输入单条结构，BAPIDELIVERY。创建时常见用法是填DELIVERY_TYPE（外向交货类型，标准一般是LF）和PICKING_DATE（拣配日期）。
• SHIPPING：输入结构BAPISHIPPING，SHIP_POINT字段传发运点。如果系统能自动确定，也可以不传，但项目落地时不传的后果通常是BAPI报“无法确定装运点”，所以稳妥起见我都是先读出来主动传进去。
• DELIVERYS：输出表，结构与BAPIDELIVERY一致。创建成功后从第一行取DELIVERY字段就是交货单号。
• RETURN：输出表，BAPIRET2，标准消息结构。

发运点怎么取？销售订单抬头表VBAK本身有VSTEL字段。绝大多数正常单子创建时就已经确定发运点，直接拿出来传给SHIPPING-SHIP_POINT。少数老数据没维护，可以从销售组织对应的表TVTA取默认发运点，实在取不到就报错提示配置问题。这个顺序我在项目里反复验证过，比让BAPI自己去猜要可控。

3.2 创建前要做的数据准备

批量创建不是无脑循环。我写的程序里，每个订单行进入BAPI之前都要过三关。

第一关是冻结检查。读取VBAK-LIFSK和VBAP-LIFSK，如果有值，说明订单层面或行项目层面挂了交货冻结，直接跳过并记录下来。还要看VBAP-ABSTA，如果行项目被拒绝，也别传进去。

第二关是剩余数量计算。交货数量不能拍脑袋传，标准逻辑是“计划行数量减去已交货数量”。计划行数量从VBEP的WMENG或BMENG取，已交货数量可以从LIPS按参考订单号汇总，也可以从VBFA查已流转数量。把我前面提到的数据链路利用起来，这步做扎实了，创建出来的交货单数量才是业务可用的。如果你不传DELIVERY_QTY，BAPI内部也有默认数量逻辑，但那个行为不够透明，生产环境里一旦数据有偏差很难解释，所以我还是建议显式计算并传递。

第三关是重复创建检查。有些定时任务跑着跑着发生异常重跑，就很容易把同一订单再创建一遍。我习惯在创建前先按订单号去查VBFA里有没有已经存在状态正常的交货单记录，有就跳过。这个检查配合锁函数，基本能杜绝重复单。

3.3 代码骨架

给一个可以直接跑通的最小版本。为了看逻辑方便，我把订单来源简化成一段内表赋值，实际项目里改成从选择屏幕、接口表或数据库表读就可以了。

DATA: ls_so TYPE bapisdls, ls_delivery TYPE bapidelivery, ls_shipping TYPE bapishipping, lt_sales TYPE TABLE OF bapisdls, lt_delivery TYPE TABLE OF bapidelivery, lt_return TYPE TABLE OF bapiret2, ls_dlv_out TYPE bapidelivery, lv_vbeln TYPE vbeln_vl. * 准备交货类型和日期 ls_delivery-delivery_type = 'LF'. ls_delivery-picking_date = sy-datum. * 发运点：订单表里读取，取不到则报错跳过 SELECT SINGLE vstel FROM vbak INTO ls_shipping-ship_point WHERE vbeln = p_vbeln. IF sy-subrc <> 0 OR ls_shipping-ship_point IS INITIAL. MESSAGE e001(zsd) WITH p_vbeln '发运点未维护'. ENDIF. * 组装销售订单行 CLEAR ls_so. ls_so-sales_order = p_vbeln. ls_so-sales_order_item = '000010'. ls_so-delivery_qty = 10. " 这里传计算后的剩余可交数量 APPEND ls_so TO lt_sales. * 调用创建BAPI CALL FUNCTION 'BAPI_OUTB_DELIVERY_CREATE_SLS' TABLES sales_orders = lt_sales deliverys = lt_delivery return = lt_return. * 检查错误 IF line_exists( lt_return[ type = 'E' ] ). LOOP AT lt_return INTO DATA(ls_ret) WHERE type CA 'EA'. WRITE: / '创建失败：', ls_ret-message. ENDLOOP. CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'. ELSE. READ TABLE lt_delivery INTO ls_dlv_out INDEX 1. lv_vbeln = ls_dlv_out-delivery. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = 'X'. WRITE: / '交货单创建成功：', lv_vbeln. ENDIF.

这里只演示了一个订单一个行项目的情况。核心要点有两个：一是RETURN里只要出现TYPE为E或A的消息，就要按失败处理，不能只认SY-SUBRC；二是创建成功后必须调BAPI_TRANSACTION_COMMIT，而且建议把WAIT参数设置成‘X’，确保交货单号和物料凭证在提交完成后立即可查。

3.4 多订单、多行项目怎么拆单

生产环境里，一个销售订单经常有十几个行项目，一次批量程序可能处理成百上千个订单。直接把所有行塞进SALES_ORDERS内表，BAPI会按系统交货拆分规则自动分组。大多数情况下，同一个订单、同一个发运点的行项目会合并到同一张交货单；但如果行项目工厂不同或发运点不同，就会被拆成多张交货单。这本身不是错误，但业务预期要提前对齐，别等上线后业务拿着单号来问“为什么一个单子拆了三次”。

我常用的策略是一个销售订单一个销售订单地处理，每个订单内部所有行项目一次性传给BAPI，拿到返回结果后再处理下一个订单。这样既保证了一个订单内部逻辑上的整体性，又方便定位失败原因。如果你把几百个订单一次性传给BAPI，返回的DELIVERYS和RETURN混在一起，你想知道哪个失败对应哪个订单，处理起来非常痛苦。

提交策略同样要讲。每个订单创建成功后立刻COMMIT，失败则ROLLBACK。有人喜欢全批量做完再统一COMMIT，一旦中途有锁等待或者运行到一半程序崩了，之前创建的几百张交货单全部回滚，业务那边很难接受。分单提交看起来多消耗一点数据库操作时间，但换来的是每单独立、失败户可控，生产环境里最重要。

4. 常见报错与业务数据问题的排查实录

这块内容是我个人最想写的部分。BAPI的代码逻辑相对固定，真正折腾人的都是各种业务数据问题和配置问题。

4.1 创建报错总是一个E，但具体原因藏在消息里

很多初学者看到RETURN里有E就慌了，直接把MESSAGE整段抛给业务，业务也看不懂。这里分享一个排查顺序：先看消息类ID和消息号，再上SE91查消息详情，最后结合后台配置确认。

比如常见的VL 581 错误“交货冻结被设置”，多半是订单抬头的LIFSK挂了值，信用管理释放或财务释放没有过；VL 348 错误提示可用性检查异常，那就是ATP数量不够或检查范围配置问题。BAPIRET2的MESSAGE字段虽然是格式化好的文本，但真正精确到原因是ID和NUMBER组合。日志里建议把TYPE、ID、NUMBER、MESSAGE四个字段都记录下来，方便事后翻查。

4.2 交货冻结、信用冻结、项目被拒

这类问题出现频率非常高。订单在VA01创建后，如果信贷检查没过，或者销售未释放，抬头状态就会挂上冻结。批量程序创建时直接报“订单被冻结”。我的做法是在创建前查询VBAK-LIFSK和VBAP-LIFSK，有值就跳过，并通过日志告诉业务“这张单因为什么冻结被跳过了”。这样业务可以去后台处理，程序也不会傻傻地一直报错重试。

还有一种情况是行项目被整体拒掉，判断条件是VBAP-ABSTA非空。这类行项目即使传进去，BAPI也会返回错误。创建前拦掉，程序执行效率和可读性都更好。

4.3 可用性检查不通过和批次拆分

可用性检查不通过有两种表现。一种是直接报错，比如“物料 XXX 没有库存”，这种好理解，就是ATP范围里找不到足够库存。另一种是BAPI返回警告，提示“缺货数量多少”，但交货单还是创建出来了，交货数量被系统自动扣减。这种最危险，因为你以为创建成功数量就对，实际上数量已经变了。

处理方式有两种：一种是创建前自己跑一遍可用性检查，数量不够就跳过；另一种是创建后对比SALES_ORDERS传入数量与交货单实际行项目数量，不一致就记录告警。我倾向于后一种，因为前一种要额外维护一套ATP检查逻辑，而后直接利用BAPI创建时的检查结果，代码改动小、逻辑可靠。

批次拆分问题也很常见。物料启用了自动批次确定，但客户希望在创建交货时按指定批次创建。BAPI本身不直接接收批次信息，需要走增强或者先强制固定批次。遇到这种情况，我一般先确认是否必须按批次交货，如果是，就得在增强点MV50AFLL或BADI LE_SHP_DELIVERY_PROC里处理。

4.4 发运点、工厂、库位没配齐

“装运点未定义”“无法确定工厂”这类错误，九成是后台配置缺失。BAPI的逻辑是死的，它必须在配置表里找到对应的发运点、工厂、库位，找不到就报错。

排查顺序：先看销售订单里有没有维护好销售组织、分销渠道、部门，再看VBAK-VSTEL是否有值，没有就去TVTA里按销售组织匹配发运点。工厂和库位层面，要检查订单行项目里的WERKS是否在交货单相关配置中存在，行项目默认的库位LGORT是否维护到物料主数据，自动批次确定是否配好了。这些配置问题在测试环境就要反复验证，别等到生产批量作业跑挂了再去查。

4.5 受托项目等特殊业务场景

如果你的客户做受托代销业务，也就是“受托项目”，这个场景必须单独说。受托业务下，库存是客户的，SAP里的处理逻辑和标准销售订单交货不同。订单的凭证类型、行项目类别都有特殊性，直接从销售订单调用标准创建BAPI，很可能创建出来的交货单不符合受托业务要求，或者干脆不允许走标准发货流程。

以前遇到过一个需求，业务方坚持认为“订单能建出来，出库单就能建出来”，结果上线后一堆受托订单在创建交货时被拦，报错信息指向“不能与SD发货一起返回”这类的业务约束。后来我们统一做了行项目类别判断，VBTYP和PSTYV匹配受托业务时，直接走另一套处理逻辑，或者跳过由专门接口处理，问题才解决。教训就是：批量创建程序不要一视同仁，先把业务模式和项目类别分清楚。

4.6 并发重复创建

批量程序跑批一般放在半夜，但有些客户报表和生产导入任务会同时触发，两个程序都读到了同一个未交货订单，结果就是创建出两张交货单。这种问题在测试环境很难复现，生产上出现一次就够头疼。

解决办法是加锁。在程序处理单个订单前，调用ENQUEUE_EVVBLBE锁住订单对应的交货单范围，创建成功并COMMIT后再调用DEQUEUE_EVVBLBE释放锁。如果加锁时返回加锁失败，说明有其他进程正在处理，程序直接跳过这个订单。同时在数据层面，用VBFA做重复检查兜底。双保险下来，并发重复创建的问题基本能杜绝。

5. 批量作业上线前，一定要做的几项检查

最后结合我自己的交付经验，给大家列一个上线前检查清单。这些内容不是教科书上的，是大大小小项目里踩坑换来的。

第一，日志务必结构化。批量创建程序必须有日志表或者ALV输出，至少要记录：处理时间、销售订单号、行项目号、传入数量、创建出的交货单号、返回消息类型、消息文本、处理状态。业务人员不需要懂ABAP，看到一张表就知道哪些成功、哪些失败、为什么失败。很多项目上线初期，业务天天来找开发问“昨天跑批结果咋样”，就是因为日志没做好。

第二，测试数据要覆盖特殊场景。普通订单只是最基本的情况，测试时要专门准备：有交货冻结的订单、可用性不足的订单、跨工厂多行项目的订单、批次物料订单、受托业务订单、已经部分交货的订单。每个场景走一遍，程序才不会上线后四处冒烟。

第三，考虑重跑机制。程序要设计成可重跑的。如果某个时段跑批失败，修复问题后重新执行，不能重复创建出库单。这就需要前面说的重复检查逻辑兜底。我的习惯是，在程序里把“已成功创建交货单”的订单存入日志表，重跑时先读日志表排除，再结合VBFA查一遍，双保险。

第四，过账动作谨慎开启。除非业务非常明确，否则创建程序里默认只创建交货单，不做过账。过账环节单独一个函数或接口，由仓库或下一步流程触发。我曾经见过一个程序创建完自动过账，结果因WM未确认导致大量错误单，最后业务手工补救了两周。把动作拆开，风险面积小很多。

第五，性能控制在可接受范围。BAPI调用本身有开销，尤其几百上千个订单循环调用时，不能一台服务器硬扛。我一般建议批量程序分批处理，比如一次循环50个订单，每批COMMIT一次，外加大量数据时用并行进程，但并行的前提是对锁和日志做好并发控制。性能优化有一个原则：先保证正确性，再谈速度。

回到创建出库单这件事本身，SAP的标准功能和增强点已经提供了足够多的支撑，BAPI_OUTB_DELIVERY_CREATE_SLS只是其中最关键的一环。真正决定项目质量的是数据准备、异常处理和日志设计这些外围工夫。把这一整套流程想明白，不要说接一个销售订单创建交货单的接口，就是以后让你接EWM、接SRM、接电商中台的交付流程，心里都有底。