企业官网建设流程全解析

简介：本资源是一份聚焦SAP SD模块交货单类型配置与应用的深度解析文档，面向SAP ABAP开发人员、SD顾问、实施工程师及企业内部系统运维人员，解决交货单凭证类别、编号规则、订单参照逻辑、库存选址、输出控制、错误处理及WM集成等核心配置难题。文档以PDF格式呈现，共1个文件，大小191KB，内容结构清晰，覆盖J/7/T/G四类凭证标识、NR内部分配与外部范围号机制、201/202项目需求差异、V2输出应用、途径确定规则（A/B空白）、交货分解与自动包装触发条件、合作伙伴确定流程及WMS分配模式等实战要点。已有986人学习下载，读者可直接掌握交货单类型在零售、退货、跨公司调拨等多业务场景下的差异化配置逻辑、典型报错（如000043路径不一致）定位方法，以及屏幕顺序组、显示范围（UALL/UHAU/UMAR）等事务流定制技巧，是SAP SD模块深化理解与高效配置的重要参考。

1. 交货单类型不是“选个编号”：它是一张动态路由表，决定整条出库链路的执行逻辑

你有没有遇到过这样的场景：同一张销售订单，用交货单类型 J 能顺利过账、自动触发拣配、生成运单、同步库存；但换成 T（退货）后，系统却卡在“无法确定仓库”报错，或者明明配置了包装规则，却死活不自动生成包材行项目？更玄的是，有些字段在事务 VL01N 里灰掉不可改，有些却能手动覆盖——而这一切，根本不是界面权限或用户角色的问题，而是交货单类型（Delivery Type）在底层悄悄重写了整条业务流的控制权。它不像销售订单类型（Order Type）那样只管“能不能建单”，而是深度介入从屏幕渲染、数据校验、库存移动、WM集成、输出生成到后续凭证触发的全生命周期。J、7、T、G 这四个字母背后，是 SAP SD 模块最硬核的“业务策略引擎”：它把抽象的业务规则（比如“零售发货必须走特定仓配路径”“内向收货禁止手动加行项目”）编译成可执行的配置参数集，直接映射到 ABAP 内核的凭证处理函数（如LV50AFZZ中的DELIVERY_CREATE）、库存移动逻辑（MB_POST_GOODS_MOVEMENT）、WM 接口（LX01/LX02）和输出条件技术（NAST表驱动）。搞不懂它，你就永远在“试错式配置”里打转；看透它，你才能把 VL01N 从黑匣子变成可编程的流水线。这份资源，就是它的完整指令手册。

2. 凭证类别与数字系统：为什么 J 和 T 的编号规则必须隔离，且不能共用一个号段？

交货单类型的凭证类别（Document Category）绝非仅用于界面上显示一个字母。它在 SAP 底层是LIKP-TRATY字段的取值来源，直接参与凭证主数据（LIKP表）的创建校验、库存移动类型（MSEG-BWART）的推导、以及后续财务凭证（BKPF/BSEG）的过账逻辑。而数字系统（Number Range）则是这套分类体系的物理锚点——它让不同业务语义的单据，在数据库层面就彻底隔离，避免任何跨类型的数据污染或序列冲突。

2.1 凭证类别如何驱动库存移动与财务过账？

凭证类别决定了交货单过账时调用的移动类型（Movement Type），而移动类型又绑定具体的会计科目（T030表）和库存更新逻辑。以 J（正常交货）和 T（退货）为例：

* 在标准程序 LV50AFZZ 中，凭证类别 TRATY 参与移动类型推导 CASE likp-traty. WHEN 'J'. " 正常出货：调用移动类型 601（发货） bwart = '601'. WHEN 'T'. " 退货：调用移动类型 651（客户退货入库） bwart = '651'. WHEN '7'. " 内向收货：调用移动类型 101（采购收货）或 501（库存转移收货） bwart = '101'. " 具体取决于订单类型 ENDCASE.

提示：BWART值一旦确定，系统即从T030表读取对应移动类型的评估类（KDFIV）、特殊库存标识（SOBKZ）及会计科目（HKONT）。若 J 和 T 共用同一号段，当某张 T 单因错误被回滚，其编号可能被 J 单复用，导致LIKP表中TRATY = 'J'但BWART = '651'的逻辑矛盾——这会直接破坏MB51库存移动查询的准确性。

2.2 数字系统（Number Range）的三层隔离机制

数字系统并非简单分配一串连续数字，而是通过三重维度实现强隔离：

2.3 为什么“7”内向收货单必须与采购订单类型强绑定？

内向收货单（类别 7）的本质是“模拟采购收货”，其凭证类别直接关联采购订单类型（EKPO-BSART）和移动类型（T030-BWART）。系统在创建时强制校验：

* 核心校验逻辑位于函数模块 'SD_DELIVERY_CHECK_ORDER' IF likp-traty = '7'. " 读取订单抬头数据 SELECT SINGLE bsart FROM ekko INTO lv_bsart WHERE ebeln = likp-vbelv. CASE lv_bsart. WHEN 'NB'. " 标准采购订单 " 允许创建，移动类型设为 101 WHEN 'UB'. " 库存转储订单 " 移动类型设为 301/309 WHEN OTHERS. MESSAGE 'E000(00)' WITH '内向收货单必须基于有效采购订单类型'. ENDCASE. ENDIF.

注意：此处的liqp-vbelv（参考订单号）字段，正是“订单参考”配置中“要求订单”开关的底层实现依据。若该开关未启用，系统跳过此校验，但BWART仍按默认值（如 101）生成，可能导致财务过账科目错误。

3. 订单参考与凭证内容：当“省缺订单类型”被触发时，系统如何动态补全缺失的业务上下文？

订单参考配置（Order Reference Settings）是交货单类型最易被低估的“上下文注入器”。它不只控制“能不能建单”，更在单据创建瞬间，为后续所有环节（库存、财务、输出）预埋关键元数据。其中，“省缺订单类型”（Default Order Type）是典型的“隐式依赖注入”机制——它让一张看似独立的交货单，自动获得销售订单（VBAK）或采购订单（EKPO）的完整业务上下文。

3.1 “要求订单”开关的底层校验链：从屏幕字段到数据库锁

当“要求订单”设为X时，系统在 VL01N 屏幕初始化阶段即启动强校验：

* 屏幕 PBO 逻辑（程序 SAPMV50A，屏幕 1000） MODULE check_order_required OUTPUT. IF v50a-traty = 'J' AND tvko-ordreq = 'X'. " tvko 来自 TVKO 表，存储交货单类型配置 " 检查屏幕字段 V50A-VBELV（参考订单号）是否为空 IF v50a-vbelv IS INITIAL. MESSAGE 'E001(V50A)' WITH '必须输入参考订单号'. ELSE. " 执行后台校验：读取 VBAK 表确认订单存在且状态有效 SELECT SINGLE auart FROM vbak INTO lv_auart WHERE vbeln = v50a-vbelv. IF sy-subrc <> 0 OR lv_auart NOT IN ('OR', 'TA'). " 仅允许标准订单/三方订单 MESSAGE 'E002(V50A)' WITH '参考订单无效或类型不匹配'. ENDIF. ENDIF. ENDIF. ENDMODULE.

避坑 / 常见问题 / 排查
现象 1：VL01N 中输入 J 类型交货单，填入有效销售订单号后仍报错“参考订单类型不匹配”。
原因：销售订单类型（VBAK-AUART）未在交货单类型配置的“允许订单类型”列表（TVKO-AUART表）中维护。系统校验时lv_auart NOT IN tvko-auart为真。
解决：事务 OVLP 进入交货单类型配置，为 J 类型维护允许的订单类型（如 OR、TA、RE）。

现象 2：开启“要求订单”后，STO（公司间销售）业务无法创建交货单，报错“无可用订单”。
原因：STO 订单类型（如OR）虽在TVKO-AUART中，但其抬头字段VBAK-LIFSK（交货冻结）为X，或行项目VBAP-LFSTA（交货状态）非空，系统认为订单已部分交货。
解决：检查 STO 订单状态，确保LFSTA = ' ',LIFSK = ' '；或临时关闭“要求订单”开关，改用“省缺订单类型”+ 后续凭证触发。

现象 3：手动输入交货单号（外部编号）时，“要求订单”校验未触发，导致后续发票（VF01）无法引用该交货单。
原因：“要求订单”仅校验VBELV字段，而外部编号模式下VBELV为空，系统跳过校验，但LIKP-VBELV未写入，导致VBRK-VBELN关联失败。
解决：外部编号模式必须配合“省缺订单类型”，由系统自动填充VBELV。

3.2 “省缺订单类型”的动态上下文补全：从交货单到发票的隐式链路

“省缺订单类型”（Default Order Type）的核心价值在于：它让交货单成为“可追溯的中间凭证”。当交货单不直接引用订单时，系统通过该配置，为后续发票（Billing Document）预设源头：

* 发票创建时（VF01），系统自动回溯交货单的省缺订单类型 SELECT SINGLE auart FROM tvko INTO lv_default_auart WHERE traty = lips-traty. " lips-traty = 交货单类型 IF lv_default_auart = 'OR'. " 尝试从交货单抬头 LIKP-VBELN 关联销售订单 VBAK-VBELN SELECT SINGLE vbeln FROM vbfa INTO lv_vbeln WHERE vgbel = lips-vbeln AND vgtyp = 'J'. " J = 交货单 -> 订单关系 IF sy-subrc = 0. " 成功获取订单号，用于发票抬头 VBRK-AUBEL vbrk-aubel = lv_vbeln. ENDIF. ENDIF.

提示：VBFA表是 SAP 的凭证流关系表，VGREL（源凭证）与VGBEL（目标凭证）构成有向边。VGTYP = 'J'表示“交货单 → 销售订单”关系。若“省缺订单类型”未配置，VBFA查询返回空，VBRK-AUBEL为空，导致发票无法过账（报错VF003）。

3.3 项目需求（Item Requirement）：201 与 202 如何控制行项目编辑的底层权限？

项目需求（Item Requirement）参数（TVKO-ITR）直接映射到屏幕字段的INPUT属性控制，而非简单的业务逻辑开关：

* 屏幕 PAI 逻辑（程序 SAPMV50A，屏幕 1000） MODULE user_command_0100 INPUT. CASE tvko-itr. WHEN '201'. " 禁用所有行项目新增按钮 LOOP AT screen. IF screen-name = 'LIPS-POSNR' OR screen-name = 'LIPS-MATNR'. screen-input = 0. " 置为不可输入 MODIFY SCREEN. ENDIF. ENDLOOP. WHEN '202'. " 允许新增，但校验物料主数据销售视图 PERFORM check_material_sales_view. ENDCASE. ENDMODULE.

注意：ITR = '201'时，系统不仅禁用新增，还会在保存前校验LIPS表中是否存在行项目（SELECT COUNT(*) FROM lips WHERE vbeln = liqp-vbeln），若为 0 则报错。这是防止“空交货单”进入系统的关键防线。

4. 输出确定过程与途径确定：当“B)”路径重定失败时，系统如何定位TROAL表中的计划路径冲突？

输出确定（Output Determination）和途径确定（Route Determination）是交货单类型中耦合度最高、排查最复杂的两个模块。它们共同决定了“这张单子要发给谁、怎么发、发什么”，而TROAL表（Transportation Route Allocation）正是二者交汇的“决策仲裁中心”。

4.1 输出确定过程：从NAST表到实际输出的四层条件链

输出确定不是简单地选个打印机，而是基于条件技术（Condition Technique）的四级匹配：

* 输出触发核心逻辑（程序 RSNAST00） SELECT * FROM nast INTO TABLE lt_nast WHERE otype = 'V2' AND app = 'V2' AND objky = liqp-vbeln " 交货单号 AND kschl IN s_kschl " 输出类型选择屏 AND vmsta = '01'. " 已激活状态 LOOP AT lt_nast ASSIGNING <fs_nast>. CASE <fs_nast>-medio. WHEN '1'. " 打印 CALL FUNCTION 'PRINT_DELIVERY' EXPORTING im_vbeln = <fs_nast>-objky. WHEN '3'. " 邮件 CALL FUNCTION 'SO_NEW_DOCUMENT_SEND_API1' EXPORTING document_data = ls_doc. ENDCASE. ENDLOOP.

提示：NAST-VMSTA = '01'（已激活）是输出执行的前提。若配置了输出类型但未激活，RSNAST00不会处理该记录，导致“配置了却没输出”的假象。

4.2 途径确定（Route Determination）的三种模式解析

途径确定规则（TVKO-ROUTD）直接控制LIKP-ROUTE字段的生成逻辑，其值A)、B)、空白，对应三种完全不同的 ABAP 处理分支：

* 途径确定主逻辑（程序 LV50AFZZ，函数 'DELIVERY_ROUTE_DETERMINE'） CASE tvko-routd. WHEN space. " 空白：继承订单路径 liqp-route = liqp-vbelv_route. " 直接取自订单抬头 ROUTE 字段 WHEN 'A)'. " A)：按重量组重算，且允许手动修改 PERFORM calculate_route_by_weight_group CHANGING liqp-route. " 手动修改权限由屏幕字段属性控制 WHEN 'B)'. " B)：按重量组重算，但仅限白名单路径 PERFORM calculate_route_by_weight_group CHANGING liqp-route. " 校验结果是否在 TROAL 白名单中 SELECT SINGLE * FROM troal INTO ls_troal WHERE route = liqp-route AND vbeln = liqp-vbelv. " 订单号作为白名单上下文 IF sy-subrc <> 0. MESSAGE 'E003(V50A)' WITH '计算路径不在白名单中'. ENDIF. ENDCASE.

4.3TROAL表的白名单机制与错误代码 000043 的根因

TROAL表（Transportation Route Allocation）是B)模式的执行依据，其结构设计直指业务痛点：

错误代码000043的完整含义是：系统尝试为交货单分配路径时，发现订单（VBELN）在TROAL表中未定义任何有效路径（ROUTE），因此无法执行B)模式的白名单校验。

避坑 / 常见问题 / 排查
现象 1：交货单类型设为B)，订单抬头ROUTE为空，保存时报错000043。
原因：TROAL表中VBELN = '0000001234'的记录不存在，系统无白名单可查。
解决：事务OVZ2进入“运输路径分配”，为该订单号添加允许的路径（如R001）。

现象 2：TROAL已维护路径，但交货单仍报000043。
原因：TROAL-VBTYP（订单类型）与当前订单VBAK-AUART不匹配，或TROAL-MANDT（客户端）错误。
解决：检查TROAL记录的VBTYP和MANDT是否与订单一致；使用SE16N直接查表验证。

现象 3：订单有路径，交货单却继承了错误的路径（如R002而非R001）。
原因：B)模式下，系统先按重量组计算路径，再校验是否在TROAL白名单。若计算结果R002不在白名单，系统不会 fallback 到R001，而是直接报错。
解决：确保重量组计算逻辑（T683S表）与TROAL白名单一致；或改用A)模式并手动修正。

5. 特殊功能与事务流：当“交货分解-仓库编号”触发警告时，LIKP与LIPS的 WM 仓码一致性如何被强制校验？

“交货分解-仓库编号”（Delivery Split by Warehouse Number）是一个典型的 WM（Warehouse Management）集成开关，它暴露了 SAP SD 与 WM 模块间最脆弱的数据一致性边界。其警告逻辑并非简单的字段比对，而是深入到LIKP（抬头）与LIPS（行项目）表的 WM 仓码（LGORT/LGNUM）层级，并触发实时库存检查。

5.1 WM 仓码不一致警告的触发条件与 ABAP 实现

该警告（MessageV1001）在 VL01N 保存前校验，核心逻辑在LV50AFZZ的DELIVERY_CHECK_WAREHOUSE函数中：

* 交货单保存前校验（函数 'DELIVERY_CHECK_WAREHOUSE'） IF tvko-wmspl = 'X'. " 交货分解开关启用 " 读取抬头 WM 仓码（LIKP-LGORT） SELECT SINGLE lgort FROM likp INTO lv_header_lgort WHERE vbeln = liqp-vbeln. " 遍历所有行项目，检查 WM 仓码是否一致 SELECT lgort FROM lips INTO TABLE lt_item_lgort WHERE vbeln = liqp-vbeln. LOOP AT lt_item_lgort ASSIGNING <fs_lgort>. IF <fs_lgort>-lgort <> lv_header_lgort. " 发现不一致，但仅当 WM 管理启用时才报错 SELECT SINGLE lgnum FROM t001w INTO lv_lgnum WHERE werks = liqp-werks AND lgort = <fs_lgort>-lgort. IF sy-subrc = 0. " 该仓码确属 WM 管理 MESSAGE 'V1001(V50A)' WITH '行项目仓库与抬头不一致'. EXIT. ENDIF. ENDIF. ENDLOOP. ENDIF.

提示：T001W表存储工厂（WERKS）与仓库号（LGNUM）的映射。只有当行项目LGORT在T001W中存在对应LGNUM时，才视为 WM 管理仓，此时不一致才触发警告。普通库存仓（LGORT但T001W无记录）不触发。

5.2 自动包装与包装物料项目的联动机制：POP1/POF1如何驱动LIPS行项目生成？

自动包装功能是交货单类型与物料主数据（MARA/MVKE）深度耦合的典范。其触发链路为：交货单类型开关（TVKO-AUTPK）→ 物料包规（MARA-PACK）→ 包装物料类型（TVEP-VEPRT）→ 行项目自动生成（LIPS插入）。

* 自动包装主逻辑（函数 'DELIVERY_AUTO_PACKAGING'） IF tvko-autpk = 'X'. " 读取行项目物料号 SELECT matnr, lgort FROM lips INTO TABLE lt_lips WHERE vbeln = liqp-vbeln. LOOP AT lt_lips ASSIGNING <fs_lips>. " 检查物料是否维护包规（MARA-PACK = 'X'） SELECT SINGLE pack FROM mara INTO lv_pack WHERE matnr = <fs_lips>-matnr. IF lv_pack = 'X'. " 读取包规（TVEP 表） SELECT SINGLE veprt FROM tvep INTO lv_veprt WHERE matnr = <fs_lips>-matnr. " 检查包装物料类型是否允许交货项目（TVEP-VHAR = 'X'） IF lv_veprt = 'X'. " 自动生成包材行项目 ls_lips-matnr = lv_veprt_matnr. " 包材物料号 ls_lips-posnr = <fs_lips>-posnr + 10. " 新增行项目号 APPEND ls_lips TO lt_lips_new. ENDIF. ENDIF. ENDLOOP. " 批量插入新行项目 INSERT lips FROM TABLE lt_lips_new. ENDIF.

注意：TVEP-VHAR（一般交货项目）字段必须为X，否则即使包规存在，系统也不生成行项目。这是防止非销售包材（如内部转运托盘）误入交货单的关键闸门。

5.3 屏幕顺序组与显示范围：UALL/UHAU/UMAR如何控制LIPS表的初始加载？

屏幕顺序组（Screen Sequence Group）和显示范围（Display Range）共同决定了 VL01N 屏幕上LIPS表数据的加载策略，直接影响性能与用户体验：

避坑 / 常见问题 / 排查
现象 1：VL01N 中看不到任何行项目，屏幕一片空白。
原因：显示范围设为UMAR，但未在选择屏输入POSNR，导致SELECT语句WHERE posnr IN ()返回空集。
解决：切换显示范围为UALL或UHAU；或在选择屏输入具体行项目号。

现象 2：UHAU模式下，赠品行项目（PSTYV = 'TANN'）未显示，但业务要求必须可见。
原因：UHAU的硬编码逻辑仅筛选PSTYV = 'TAN'（标准行项目），赠品被过滤。
解决：改用UALL；或自定义显示逻辑（增强LV50AFZZ中的DISPLAY_LIPS函数）。

现象 3：UALL模式下，打开大交货单（>1000 行）卡顿严重。
原因：全表SELECT导致数据库压力过大。
解决：启用UHAU并优化PSTYV筛选逻辑；或实施数据库索引（LIPS~VBNR_POSNR）。

6. 设计取舍与验证方法：为什么“途径确定”不提供C)模式，以及我如何用SE37快速验证任意配置组合？

SAP 交货单类型的设计，处处体现着“业务刚性”与“系统柔性”的艰难平衡。最典型的例子，就是途径确定（TVKO-ROUTD）只提供A)、B)、空白三种选项，却唯独没有C)——即“按重量组重算，若不在白名单则 fallback 到订单路径”。这个看似合理的功能缺失，实则是 SAP 架构师深思熟虑后的主动放弃。

6.1 为什么没有C)模式？—— 从审计合规到系统可预测性的三重约束

C)模式（Fallback to Order Route）的缺席，源于三个不可妥协的底层约束：

1. 审计刚性（Audit Rigidity）：
   在医药、航空等强监管行业，运输路径必须 100% 可追溯、不可篡改。若允许C)模式，当重量组计算路径R002不在TROAL白名单时，系统自动 fallback 到订单路径R001，这会导致实际执行路径与TROAL白名单记录不一致，违反“路径变更必须经审批后显式维护”的合规要求。

2. 系统可预测性（System Predictability）：
   A)和B)的行为边界清晰：A)允许人工干预，B)强制白名单。而C)引入了“条件性 fallback”，使系统行为变成if (calculated_route in TROAL) then use_it else use_order_route。这种分支逻辑会显著增加测试用例数量（需覆盖in/not in两种状态），并让 ABAP 开发者难以编写确定性的增强（Enhancement），因为 fallback 行为本身就成了新的“隐藏配置”。

3. WM 集成复杂度（WM Integration Complexity）：
   B)模式下，TROAL表的VBELN字段与订单强绑定，确保路径分配与订单生命周期一致。若引入C)，系统需在TROAL中同时维护“计算路径白名单”和“fallback 路径白名单”，并保证二者在订单变更（如取消、修改）时同步更新，这会极大增加TROAL表的维护负担和数据不一致风险。

6.2 用SE37验证配置组合：一个可复用的 ABAP 快速验证模板

与其在生产系统反复试错，不如用SE37构建一个轻量级验证沙盒。以下是我日常使用的Z_VERIFY_DELIVERY_TYPE函数模块模板，它能一键验证任意交货单类型配置在特定输入下的行为：

FUNCTION Z_VERIFY_DELIVERY_TYPE. *"---------------------------------------------------------------------- *"*"Local Interface: *" IMPORTING *" VALUE(IV_TRATY) TYPE LIKP-TRATY " 交货单类型 *" VALUE(IV_VBELV) TYPE VBELN_VL " 参考订单号（可选） *" VALUE(IV_WERKS) TYPE WERKS_D " 工厂 *" VALUE(IV_LGORT) TYPE LGORT " 抬头仓库 *" EXPORTING *" VALUE(EV_ROUTE) TYPE ROUTE " 计算路径 *" VALUE(EV_OUTPUT) TYPE STRING " 输出类型列表 *" VALUE(EV_ERROR) TYPE STRING " 错误信息 *"---------------------------------------------------------------------- DATA: ls_tvko TYPE tvko, lt_nast TYPE STANDARD TABLE OF nast, lv_route TYPE route. " 1. 读取交货单类型配置 SELECT SINGLE * FROM tvko INTO ls_tvko WHERE traty = iv_traty. IF sy-subrc <> 0. ev_error = |交货单类型 { iv_traty } 未配置|. RETURN. ENDIF. " 2. 模拟途径确定 CASE ls_tvko-routd. WHEN space. ev_route = '继承订单路径'. WHEN 'A)'. " 调用标准函数模拟重量组计算 CALL FUNCTION 'SD_ROUTE_DETERMINE_BY_WEIGHT' EXPORTING i_werks = iv_werks IMPORTING e_route = lv_route. ev_route = lv_route. WHEN 'B)'. " 检查 TROAL 白名单（此处简化为查表） SELECT SINGLE * FROM troal INTO @DATA(ls_troal) WHERE route = @lv_route AND vbeln = @iv_vbelv. IF sy-subrc = 0. ev_route = lv_route. ELSE. ev_error = |路径 { lv_route } 不在 TROAL 白名单中|. ENDIF. ENDCASE. " 3. 模拟输出确定 SELECT otype, kschl, medio FROM nast INTO TABLE @lt_nast WHERE otype = 'V2' AND app = 'V2' AND objky = @iv_vbelv. LOOP AT lt_nast ASSIGNING FIELD-SYMBOL(<fs_nast>). CONCATENATE ev_output <fs_nast>-kschl ',' INTO ev_output. ENDLOOP. ENDFUNCTION.

使用方法：

1. 在SE37中输入函数名Z_VERIFY_DELIVERY_TYPE；
2. 填入IV_TRATY = 'J', `IV_VBELV = '0000001234'

本文还有配套的精品资源，点击获取