深入解析SAP GN_DELIVERY_CREATE：如何通过BADI增强内向交货单自定义字段

1. 为什么我们需要给内向交货单“加料”？

干了这么多年SAP，我发现在物流执行模块里，内向交货单（Inbound Delivery）的处理是个高频且容易出“幺蛾子”的地方。标准SAP功能确实强大，但架不住每个公司的业务都有自己独特的“脾气”。比如，你可能需要记录供应商的预约送货时间窗，或者跟踪货物在途的多个关键港口节点（像什么起运港、目的港、预计到港时间等等），这些信息在标准的采购订单或交货单里根本没地方存。

这时候，自定义增强字段就成了我们的“救命稻草”。但问题来了，你光在数据库表里加个字段（比如在LIPS或LIKP里通过Append Structure或者CI_结构增强）是没用的。数据怎么进去？这才是关键。SAP标准的事务代码VL31N、VL32N或者直接调用函数GN_DELIVERY_CREATE创建交货单时，可不会自动认识你新加的字段。你必须通过一个“后门”——也就是BADI（Business Add-In）——把数据“塞”进去。

这个“后门”就是LE_SHP_GN_DLV_CREATE。它专门拦截内向交货单的创建和修改过程，让你有机会在数据正式保存进数据库前，把你自定义的那些字段值，从你传入的接口参数里，搬运到交货单的表结构里。听起来是不是有点像“数据搬运工”？没错，但这个“搬运工”的活儿要想干得漂亮，里面的门道可不少。接下来，我就带你一步步拆解，把这个过程弄得明明白白。

2. 动手前的准备：字段增强与结构映射

在写任何代码之前，我们得先把“场地”准备好。这个场地就是数据最终要存放的数据库表，以及函数GN_DELIVERY_CREATE能接收数据的接口结构。

2.1 第一步：找到目标表并增强

内向交货单的数据主要存储在两张表：LIKP（抬头数据）和LIPS（行项目数据）。你的自定义字段应该加在哪张表，取决于字段的业务属性。如果是整个交货单级别的信息（比如一个特殊的运输批次号），就增强LIKP；如果是行项目级别的信息（比如每行物料的特殊质量状态），就增强LIPS。

增强的方法，我强烈推荐使用Append Structure或者CI_（Customer Include）结构。这是最标准、对系统影响最小的方式。以LIPS为例，你可以通过SE11事务码，找到LIPS的结构，然后在其中找到名为CI_LIPS的包含结构，在里面添加你的自定义字段，比如ZZ_ETDPORT（预计离港时间）、ZZ_ATAPORT（实际到港时间）等。

重要提示：添加字段时，字段名最好遵循你们公司的命名规范（比如用Z或Y开头），数据类型和长度要规划好。这一步做完，只是意味着数据库表有了“坑”，等着数据来填。

2.2 第二步：让GN_DELIVERY_CREATE认识你的新字段

光有“坑”不行，我们还得有“铲子”把数据运过去。GN_DELIVERY_CREATE函数是通过内表XKOMDLGN来接收行项目数据的。查看这个结构（KOMDLGN），你会发现它也有自己的CI包含结构，比如CI_KOMDLGN。

这里的操作是关键：你必须确保在KOMDLGN的CI结构里，添加完全同名、同类型的字段。也就是说，你在LIPS里加了ZZ_ETDPORT，在KOMDLGN里也要加一个一模一样的ZZ_ETDPORT。

为什么？因为后续BADI里的数据传递，依赖于SAP隐式的字段匹配搬运（MOVE-CORRESPONDING）。如果两边的字段名对不上，数据就“搬”不过去，你的努力就白费了。我早期就踩过这个坑，两边字段长度差了一位，导致数据截断，排查了好久。

完成这一步后，你的程序在调用GN_DELIVERY_CREATE之前，就可以像原始文章示例代码里那样，给你自定义的字段赋值了：

ls_komdlgn-zz_etdport = gs_inbound-zz_etdport. ls_komdlgn-zz_ataport = gs_inbound-zz_ataport. APPEND ls_komdlgn TO lt_komdlgn.

这样，你的自定义数据就随着标准数据一起，传入了交货单创建函数。

3. 核心引擎：实施BADI LE_SHP_GN_DLV_CREATE

数据已经传到了函数门口，现在需要BADI这个“内部接线员”把数据接进来，并放到正确的位置。我们进入实操环节。

3.1 创建与实施BADI

在事务码SE18（BADI Builder）里，输入LE_SHP_GN_DLV_CREATE，然后点击“实施”（Implementation）。创建一个新的实施，比如ZIM_GN_DLV_CREATE。通常，我们会为这个实施创建一个过滤器（Filter），比如按工厂、移动类型等，这样增强只对特定业务生效，更灵活也更安全。

创建好后，进入实施，你会看到这个BADI只有一个主要接口方法：IF_EX_LE_SHP_GN_DLV_CREATE~CHANGE_DELIVERY_DATA。所有魔法都发生在这个方法里。

3.2 理解方法参数与数据流

双击进入这个方法，你会看到一堆CHANGING参数。别慌，我们重点关注其中几个：

• CS_LIKP：这是正在创建或修改的交货单抬头数据。如果你想填充增强到LIKP表的字段，就在这里操作。
• CT_LIPS：这是交货单行项目数据的内表。绝大多数行项目级别的增强都在这里处理。
• CT_KOMDLGN：这就是我们传入函数的行项目数据内表！BADI会把它提供给你。

数据流动的逻辑是这样的：系统先根据CT_KOMDLGN里的标准字段创建初步的CT_LIPS条目，然后调用你的BADI方法。此时，CT_LIPS里已经有了初步的行项目数据（包括系统自动生成的交货单号、行号等），而CT_KOMDLGN里还存着你当初传入的所有数据（包括自定义字段）。

你的任务就是：把CT_KOMDLGN里每一行对应的自定义字段值，找到CT_LIPS里对应的那一行（通常通过采购订单号VGBEL和行号VGPOS来匹配），然后赋值过去。

3.3 编写数据传递逻辑

下面是一个典型的在BADI实现方法里写的代码片段。我加了详细注释，你可以直接参考：

METHOD if_ex_le_shp_gn_dlv_create~change_delivery_data. DATA: ls_komdlgn TYPE komdlgn, ls_lips TYPE lips. FIELD-SYMBOLS: <fs_lips> TYPE lips. " 循环遍历传入的原始数据行 LOOP AT ct_komdlgn INTO ls_komdlgn. " 在正在创建的交货单行项目中，找到对应的那一行 " 通常用采购凭证（采购订单）号和行项目号来匹配最可靠 READ TABLE ct_lips ASSIGNING <fs_lips> WITH KEY vgbel = ls_komdlgn-vgbel vgpos = ls_komdlgn-vgpos. IF sy-subrc = 0. " 找到了对应的交货单行，现在开始搬运自定义字段 " 这里利用了MOVE-CORRESPONDING的隐式匹配，前提是字段名完全一致 " 你也可以显式地一个一个字段赋值，更清晰 <fs_lips>-zz_etdport = ls_komdlgn-zz_etdport. <fs_lips>-zz_ataport = ls_komdlgn-zz_ataport. <fs_lips>-zz_etaport = ls_komdlgn-zz_etaport. " ... 其他自定义字段赋值 ELSE. " 理论上应该总能匹配上，这里记录个日志或抛出个消息更稳妥 " 在实际项目中，这里可以加一些错误处理逻辑 ENDIF. ENDLOOP. " 如果你有增强到抬头表LIKP的字段，可以直接操作cs_likp " 例如：cs_likp-zz_custom_hdr_field = '某个值'。 " 注意抬头字段的值可能需要从特定行汇总或从其他逻辑获取。 ENDMETHOD.

这段代码的核心就是一个匹配和搬运的过程。我建议在赋值时采用显式赋值（一句句写），而不是用MOVE-CORRESPONDING，虽然麻烦点，但代码可读性更高，未来调试时一眼就能看出哪个字段在处理，避免了隐式匹配可能带来的意外覆盖。

4. 避坑指南与实战经验分享

理论看起来挺顺，但一上手总会遇到各种问题。我结合自己踩过的坑，给你总结几个关键注意事项。

4.1 字段匹配与数据一致性

第一个大坑就是字段不匹配。我遇到过最诡异的问题是，自定义字段在LIPS和KOMDLGN里明明都加了，但BADI里就是取不到值。后来发现，是激活顺序的问题。修改了结构CI_KOMDLGN后，必须重新激活使用它的所有对象，特别是函数组GN_DELIVERY_CREATE所在的函数组。有时候甚至需要重新编译调用它的程序。最稳妥的做法是，加完字段后，跑一下事务码SE38，输入函数组名SAPLGN_DELIVERY，然后执行一下“语法检查”或直接激活，确保更改被完全识别。

第二个是数据一致性。你的自定义字段值从哪里来？在调用GN_DELIVERY_CREATE之前，必须确保这些值已经正确地从上游界面或接口中获取，并填充到LS_KOMDLGN结构里。经常有开发同事忘了给某个自定义字段赋值，导致数据库里存的是空值或初始值，业务部门跑来问“数据怎么没过来？”。所以，在填充LS_KOMDLGN的代码部分，最好加个检查或者日志，确保关键的自定义字段不为空。

4.2 性能与错误处理

BADI里的LOOP AT嵌套READ TABLE，如果交货单行项目很多（比如上百行），会有一定的性能开销。虽然对于单次创建操作来说通常可以接受，但如果你批处理成千上万张交货单，就需要留意了。确保你的匹配键（VGBEL,VGPOS）是有效的，并且CT_LIPS内表不要有重复项。可以考虑使用SORT和READ TABLE ... BINARY SEARCH来优化，但在交货单创建的这个时点，CT_LIPS的行数一般不多，简单的循环读取也足够了。

错误处理至关重要。原始文章示例代码的最后部分，就是在处理GN_DELIVERY_CREATE调用后的返回消息表ET_SPE_VBFS。你需要循环这个表，检查消息类型为E（错误）、A（终止）或X（退出）的消息。BADI执行过程中如果发生错误（比如你写的代码有运行时错误），也会通过系统异常或消息反馈到这里。一定要把这些消息捕获并传递给调用者，否则前台用户或接口对方只会看到“交货单创建失败”，却不知道具体原因，排查起来非常困难。我习惯在BADI方法里，对于关键操作也用TRY...CATCH包一下，把异常转换成具体的业务提示消息，追加到系统消息里去。

4.3 测试策略：从单元到集成

测试这种增强，不能只测BADI本身。我推荐一个三层测试法：

1. 单元测试：单独写一个测试程序，模拟构建CT_KOMDLGN和CT_LIPS数据，直接调用你的BADI实现类的方法，检查执行后CT_LIPS里的自定义字段值是否正确。这能快速验证你的数据搬运逻辑。
2. 接口测试：写一个完整的程序，模拟原始文章那样构造数据并调用GN_DELIVERY_CREATE，但先在一个测试客户端或测试物料上进行。创建成功后，立即用SE16N查看LIPS表，确认自定义字段被成功写入。同时检查消息日志，确保没有意外错误。
3. 业务流程测试：这才是最关键的。在你的完整业务场景下测试，比如从采购订单收货、或者从外部系统接口创建交货单，走通整个流程。确保自定义字段在后续的收货过账（MIGO）、发票校验（MIRO）等环节如果需要被用到，也能正常传递或显示。

最后一点心得，这种底层增强一旦投入使用，修改起来成本很高。所以在设计字段时，一定要和业务部门充分沟通，想得长远一点。字段长度留点余量，描述写清楚。文档也要跟上，在BADI实现类的方法开头，用注释写明这个增强的目的、字段对应关系、以及重要的业务逻辑。这样以后别人维护，或者你自己隔了半年再回头看，都能很快上手。