简介本资源是一份聚焦SAP SD模块交货单类型配置与应用的深度解析文档面向SAP ABAP开发人员、SD顾问、实施工程师及企业内部系统运维人员解决交货单凭证类别、编号规则、订单参照逻辑、库存选址、输出控制、错误处理及WM集成等核心配置难题。文档以PDF格式呈现共1个文件大小191KB内容结构清晰覆盖J/7/T/G四类凭证含义、NR内部分配与外部范围号机制、201/202项目需求差异、V2输出应用、途径确定规则A/B空白、交货分解仓库校验、自动包装与包材项目生成、合作伙伴确定、再计划提示及屏幕显示范围UALL/UHAU/UMAR等16项关键参数的实际配置逻辑与业务影响。已有986人学习下载读者可直接掌握交货单类型在销售出库、退货、内向收货及零售场景下的差异化设置要点、典型报错如000043路径不一致的定位方法以及WM与WMS协同下的交货分解与时间分配策略是SAP SD模块配置落地与问题排查的实用参考。1. 交货单类型不是“选个模板就完事”它是一套运行时决策引擎直接决定出库路径、包装逻辑、甚至凭证能否保存你填完一个交货单抬头点下保存——系统没报错单据生成了。但你可能完全没意识到就在那毫秒级的后台处理中SAP SD 已经根据你选的「交货单类型」比如 J 或 T动态加载了至少 12 个独立配置模块并按严格优先级顺序执行了 37 步校验与推导逻辑。这不是静态表单映射而是一次完整的业务规则编排J 类型触发自动仓库选址 包材带出 路径继承T 类型则跳过选址、禁用包材、强制重算退货路径G 类型甚至绕过标准库存检查直连零售 POS 接口。更关键的是这些行为全部发生在数据库 commit 前——一旦某步失败比如 WM 仓码冲突被勾选但实际不一致整个事务回滚且错误码 000043 不是告诉你“哪里错了”而是暴露了底层路径继承链断裂的瞬间。很多开发者直到上线后客户投诉“退货单突然不能保存”才翻出这份配置文档发现当初只改了凭证类别却漏配了「途径确定」里的 B) 模式和 TROAL 表关联。这根本不是配置疏忽而是对交货单类型本质的误判它不是标签是运行时策略容器。2. 凭证类别与数字系统为什么 J/7/T/G 四个字母能驱动截然不同的业务流交货单类型的凭证类别Document Category看似只是四个字母实则是整个 SD 交货流程的入口开关。它不存储业务数据却像一把密钥解锁后续所有配置模块的加载权限。而数字系统Number Range则是这套机制的“时间戳发生器”——它确保每个决策动作都绑定唯一可追溯的编号让审计、冲销、接口对账成为可能。2.1 凭证类别的四重语义从物理单据到业务意图的映射J、7、T、G 这四个字符在 SAP 内部并非随意分配而是承载着明确的业务语义层JNormal Delivery代表“正向履约”。它激活的不仅是出库动作更是一整套销售主数据联动逻辑必须存在有效的销售订单SOBK、行项目必须有可用库存MARD、合作伙伴功能SP必须包含售达方WE和送达方RE。若未配置「订单参考→要求订单」系统会在保存时抛出V1032错误“无有效参考单据”而非简单提示“请填订单号”。7Inbound Delivery本质是“内部物流指令”。它绕过销售定价KOMP、不校验信用额度KNVV但强制校验采购信息记录EKPO和收货工厂库存MCHB。当「交货分解-仓库编号」被勾选时系统会对比抬头 WM 仓LIPS-LGNUM与首行项目 WM 仓LIPS-LGORT若不一致则触发警告WM001但允许继续保存——因为内向收货的核心约束是“实物接收”而非“单据一致性”。TReturns Delivery这是最危险的类别。它反向调用销售订单历史VBFA强制校验原发货单LFST状态是否为“已发货”LIPS-WBSTK C同时禁用所有正向流程的增强点如USEREXIT_SAVE_DOCUMENT_PREPARE中的包装逻辑。若「项目需求」设为 201系统在屏幕初始化阶段PAI 事件 PBO就隐藏了“添加行项目”按钮而非等用户输入后报错——这是 UI 层的预判式拦截。GRetail Delivery专为高频小批量设计。它跳过标准拣配LTAP表更新直接写入零售专用表ZRET_DELIVERY并启用「显示范围UHAU」仅主项目避免 POS 系统拉取时因数据量过大超时。其输出类型默认绑定RETAIL_EMAIL而非通用V2确保发票文本走零售定制模板。提示凭证类别变更不可逆。若已保存 J 类型交货单后续无法通过修改抬头字段转为 T 类型——系统会校验LIKP-VBTYP字段的初始值直接拒绝更新。必须通过冲销VL09 重开实现。2.2 数字系统NR 内部分配如何保证并发安全与审计穿透数字系统Number Range是交货单类型背后真正的“秩序维护者”。它分为三类但核心目标统一在高并发场景下为每个业务动作生成全局唯一、时序可溯、语义明确的编号。* 示例NR 内部分配逻辑简化自 SAP 标准函数 NUMBER_GET_NEXT DATA: lv_nr_range_obj TYPE nriv-objnr VALUE V1, lv_number TYPE numc10. CALL FUNCTION NUMBER_GET_NEXT EXPORTING nr_range_obj lv_nr_range_obj object V1 交货单对象 IMPORTING number lv_number EXCEPTIONS interval_not_found 1 number_range_not_intern 2 OTHERS 3.NR 内部分配Internal Number Assignment使用V1对象编号由 SAP 内存缓冲区ENQUEUE_EOBJ管理。每次获取前先锁住当前号段如 1000000–1000999分配后立即更新缓冲区指针。这避免了数据库锁表但要求号段足够大——若日均单量 5000号段长度小于 10000 将导致频繁缓冲区刷新引发NUMBER_RANGE_EXHAUSTED错误。外部范围号External Number Assignment对接第三方 WMS 或 TMS 系统。此时V1对象被禁用系统调用EXIT_SAPLV60A_001增强点由客户代码返回外部系统生成的编号如WMS-2024-001234。关键约束该编号必须满足LIKP-VBELN字段的 10 位长度限制超长需截断或映射否则触发V1008截断警告。项目号增量Item Number Increment控制行项目编号POSNR的生成规则。若设为00010则首行项目为00010次行为00020。这并非简单加法而是调用ITEM_NUMBER_GET_NEXT函数校验LIPS-POSNR是否已被其他交货单占用。若出现重复如两个用户同时创建单据系统抛出V1021错误“行项目编号已被使用”强制用户重试。注意数字系统配置错误会导致灾难性后果。曾有某公司误将 T 类型退货单的 NR 对象设为V2发票对象结果退货单编号与发票号池混用财务月结时发现 37% 的发票号缺失最终需人工核对 2 万张单据补录。3. 订单参考与凭证内容当“必须参考订单”变成系统级硬约束订单参考Order Reference配置表面看是业务规则开关实则是 SAP SD 架构中“单据依赖链”的锚点。它决定了交货单能否脱离销售订单独立存在更深层地它控制着后续所有凭证如发票 VF01的参照关系生成逻辑。而凭证内容Document Content中的库存选址、输出确定等模块则是这套依赖链在执行层的具体落地。3.1 订单参考的三种模式从强耦合到弱关联的渐进式解耦订单参考配置的三个选项本质是定义交货单与销售订单之间的“耦合强度”要求订单Mandatory Reference这是最强耦合。系统在交货单抬头屏幕VL01N的VBELN字段设置INPUT 1必输且在 PAI 事件中调用DELIVERY_CHECK_ORDER_REFERENCE函数。该函数不仅校验订单是否存在更深度解析VBFA关系表若交货单类型为 J必须存在VBFA-VBTYP_N J且VBFA-VBELN_V 订单号的正向关系若为 T 类型则必须存在VBFA-VBTYP_N T且VBFA-VBELN_V 原发货单号的反向关系。若不满足直接抛出V1033错误“参考单据类型不匹配”而非模糊提示。省缺订单类型Default Order Type这是“弱耦合”。交货单可独立创建VBELN字段INPUT 0但系统在保存时自动生成VBFA关系。关键逻辑在DELIVERY_CREATE_DEFAULT_ORDER若交货单类型为 J且未输入订单号系统查找TVAK-AUART表中AUART OR标准订单类型的默认值若为 STO公司间调拨则读取T180表中KDFLG X的默认订单类型如UB并据此生成VBFA关系。此模式下后续开票VF01时系统自动将LIKP-VBELN作为VBRK-AUBEL填入实现无缝衔接。项目需求Item Requirement这是“UI 层预判”。当设为201时系统在屏幕绘制阶段PBO即执行IF ls_vbak-auart OR AND ls_lips-vbeln IS INITIAL. LOOP AT SCREEN. IF screen-name LIPS-POSNR. screen-input 0. 禁用行项目输入框 MODIFY SCREEN. ENDIF. ENDLOOP. ENDIF.用户根本看不到“添加行项目”按钮而非等输入后报错。这是 SAP 对业务规则的极致前置化——把错误消灭在交互发生前。3.2 库存选址规则为什么同一个交货单类型在不同工厂会走向不同仓库库存选址规则Stock Determination Rule是交货单类型配置中最具迷惑性的模块。它不直接指定仓库而是定义一套“决策树”在保存时实时计算最优库存位置。其核心是T189表库存确定规则与T189A表规则步骤的联合查询。以 J 类型为例典型配置如下步骤条件字段条件值库存类型移动类型1工厂1000UNR6012存储类型001F6013批次*Q601执行逻辑首先查MARD表筛选WERKS 1000且LGORT在T189A定义的存储类型列表中的记录若多条记录按CHARG批次排序取最早生产日期的批次MCH1-DATUV若仍有多条按LABOR质检状态过滤优先取Q质检合格状态最终锁定MARD-MATNRMARD-CHARGMARD-LGORT组合写入LIPS-LGORT。避坑 / 常见问题 / 排查现象 1J 类型交货单保存后LIPS-LGORT为空但库存充足。原因T189A规则中步骤 1 的“工厂”条件值填为1000 末尾空格导致MARD-WERKS比较失败ABAP 字符串比较严格。解决用CONDENSE函数清理空格或在T189A维护时用 F4 帮助选择工厂。现象 2同一物料在工厂 1000 有库存但交货单始终分配到工厂 2000 的仓库。原因T189主规则中“应用工厂”字段未勾选系统默认使用交货单抬头的工厂LIKP-WERKS但T189A步骤中又写了WERKS 2000造成逻辑矛盾。解决要么在T189中勾选“应用工厂”要么删除T189A中的工厂条件。现象 3启用 WM 后交货单分配到LGORT 0001但 WM 系统中该仓位不存在。原因T189A规则未关联T320WM 存储类型表系统分配的是 IM 层仓库未校验 WM 层有效性。解决在T189A步骤中增加条件字段LGTYP存储类型值设为T320-LGTYP中的有效值。4. 途径确定与交货分解当重量组规则撞上 WM 仓库系统如何抉择途径确定Route Determination和交货分解Delivery Split是交货单类型配置中技术复杂度最高的模块。它们共同解决一个核心问题如何将一张逻辑上的交货单拆解为多张物理上可执行的运输单据这不是简单的“按仓库拆分”而是融合了重量、体积、运输方式、WM 仓位、客户优先级的多维决策。4.1 途径确定的三种模式A/B/空白背后的算法差异途径确定配置中的 A、B、空白选项对应三种完全不同的路径计算引擎空白No Route Determination最简单也是性能最好的模式。系统直接继承销售订单抬头的VBAP-ROUTE值不做任何校验或重算。适用于标准化运输场景如所有订单走固定快递公司。AWeight Group Based, Manual Override启用完整重量组算法。系统执行以下步骤读取T683S表获取交货单中所有行项目的MATKL物料组和BRGEW毛重根据T683S-VRKME计量单位和T683S-BRGEW计算总重量查询T683T重量组-路线表匹配T683T-GEWGR重量组与T683S-GEWGR若匹配成功将T683T-ROUTE写入LIKP-ROUTE并开放LIKP-ROUTE字段编辑权限。关键细节A 模式下用户可手动修改LIKP-ROUTE为任意有效路线T005T表中SPRAS SY-LANGU的路线系统不校验该路线是否在T683T中定义。BWeight Group Based, Restricted Override算法同 A但覆盖逻辑受TROAL表严格约束。TROAL表结构如下ROUTE订单路线ACTUAL_ROUTE允许改为的路线VALID_FROMVALID_TOAIR-001TRUCK-0022024010199991231AIR-001SHIP-0032024010199991231当订单路线为AIR-001时用户只能将交货单路线改为TRUCK-002或SHIP-003。若尝试改为RAIL-004系统抛出000043错误“路线不在允许列表中”。此错误码直接指向TROAL表查询失败是排查 B 模式问题的第一线索。4.2 交货分解-仓库编号WM 时代下“单据一致性”的终极防线「交货分解-仓库编号」Split by Warehouse Number勾选后系统在保存前执行一次 WM 专项校验* 简化逻辑校验抬头 WM 仓与所有行项目 WM 仓是否一致 DATA: lv_header_lgnum TYPE lgnum, lv_item_lgnum TYPE lgnum. SELECT SINGLE lgnum INTO lv_header_lgnum FROM lips WHERE vbeln ls_lipk-vbeln AND posnr 00000. LOOP AT lt_lips ASSIGNING FIELD-SYMBOL(fs_lips). SELECT SINGLE lgnum INTO lv_item_lgnum FROM lips WHERE vbeln fs_lips-vbeln AND posnr fs_lips-posnr. IF lv_header_lgnum lv_item_lgnum. MESSAGE WM 仓码不一致抬头为 1行项目为 2 TYPE W WITH lv_header_lgnum lv_item_lgnum. ENDIF. ENDLOOP.但真实逻辑更复杂若行项目LIPS-LGORT为空系统会从MARD表反查LGORT再通过T320表确认该LGORT是否属于 WM 管理T320-LGNUM非空若LIPS-LGORT值为0001但T320-LGNUM 则视为非 WM 仓不触发警告头部LIKP-LGNUM取值逻辑取首行项目LIPS-LGORT对应的T320-LGNUM若首行无 WM 仓则LIKP-LGNUM 此时即使其他行有 WM 仓也不报错。避坑 / 常见问题 / 排查现象 1勾选“交货分解-仓库编号”但 WM 仓不一致时无警告。原因首行项目LIPS-LGORT为空或其值对应的T320-LGNUM为空导致LIKP-LGNUM未被赋值系统跳过校验。解决在USEREXIT_SAVE_DOCUMENT_PREPARE中强制填充首行LIPS-LGORT或在T320中为该LGORT维护LGNUM。现象 2警告弹出但LIKP-LGNUM显示为0001而实际行项目LIPS-LGORT是0002。原因LIKP-LGNUM取值逻辑是“首行LIPS-LGORT对应的T320-LGNUM”而非LIPS-LGORT本身。若0001和0002在T320中指向同一LGNUM如WM01则LIKP-LGNUM WM01但LIPS-LGORT仍不同。解决校验逻辑应比对LIPS-LGORT而非LIKP-LGNUM或在T320中为不同LGORT分配不同LGNUM。现象 3未勾选该选项但系统仍报WM001错误。原因T001W工厂表中LGNUM字段被维护且LIKP-WERKS对应的工厂启用了 WM系统自动激活 WM 校验。解决清空T001W-LGNUM或在交货单类型配置中明确关闭 WM 相关校验。5. 自动包装与合作伙伴确定从物料主数据到单据行项目的隐式生成链自动包装Automatic Packing和合作伙伴确定Partner Determination是交货单类型配置中“最易被低估的自动化模块”。它们不产生可见的 UI 元素却在后台静默完成从物料属性到单据结构的完整映射。理解其触发条件与失败路径是避免“单据莫名少行项目”或“合作伙伴信息错乱”的关键。5.1 自动包装POP1/POF1 背后的三层校验与行项目注入逻辑自动包装功能依赖三个核心配置点物料主数据中的包装规格POP1、交货单类型的“自动包装”开关、以及“生成包装物料项目”的勾选。其执行逻辑是典型的“条件链式触发”第一层校验POP1 维护物料MM02中必须维护VHAR包装属性视图且VHAR-PACKTYPE包装类型非空。若VHAR-PACKTYPE BOX系统会查找TVEP表中PACKTYPE BOX的包装规格。第二层校验POF1 激活在POF1事务码中必须为该物料工厂组合激活包装规格。系统检查TVEP表中MATNR MAT001且WERKS 1000的ACTIVE X。若未激活即使 POP1 维护正确也不触发包装。第三层校验交货单类型配置若仅勾选“自动包装”系统在LIPS表中为每行物料生成LIPS-PACKNO包装号但不新增行项目若同时勾选“生成包装物料项目”则调用PACKING_CREATE_ITEMS函数执行a) 查询TVEP获取包装物料号TVEP-PACKMATb) 校验该包装物料是否在MVKE表中维护了相同销售组织MVKE-VKORGc) 校验TVEP中PACKQTY每包装数量是否大于 0d) 若全部通过向LIPS表插入新行LIPS-MATNR TVEP-PACKMATLIPS-ARKTX PACKAGINGLIPS-POSNR按增量规则生成。提示包装物料行项目的LIPS-POSNR与主物料行项目LIPS-POSNR不连续。例如主物料为00010包装物料可能为00015这是为后续可能的包装层级嵌套预留空间。5.2 合作伙伴确定过程如何从销售订单的 WE/RE推导出交货单的 ZS/ZR合作伙伴确定Partner Determination是 SAP SD 中最精妙的规则引擎之一。它不依赖硬编码而是通过TVKP合作伙伴确定过程和TVKPT过程步骤表的组合实现动态推导。以标准过程0001为例其步骤如下步骤来源字段说明1销售订单抬头VBKD-KUNAG取售达方AG2销售订单行项目VBPA-KUNNR若步骤 1 为空取行项目中PARVW AG的客户号3工厂主数据T001W-KUNNR若前两步为空取工厂T001W表中维护的默认客户当交货单类型配置了合作伙伴确定过程0001后系统在保存时执行初始化LIKP-KUNAG 按TVKPT步骤顺序执行步骤 1SELECT SINGLE kunnr INTO li_kunag FROM vbkd WHERE vbeln ls_lipk-vbeln AND posnr 00000若li_kunag为空执行步骤 2SELECT SINGLE kunnr INTO li_kunag FROM vbpa WHERE vbeln ls_lipk-vbeln AND parvw AG若仍为空执行步骤 3SELECT SINGLE kunnr INTO li_kunag FROM t001w WHERE werks ls_lipk-werks将最终li_kunag写入LIKP-KUNAG。避坑 / 常见问题 / 排查现象 1交货单中LIKP-KUNAG为空但销售订单抬头有售达方。原因TVKPT步骤 1 的“来源”字段填为VBKD-KUNNR错误字段而正确字段应为VBKD-KUNAG。KUNNR是客户主数据号KUNAG才是售达方字段。解决在OVKK事务码中检查TVKPT步骤修正字段名。现象 2交货单合作伙伴与销售订单不一致但TVKPT配置无误。原因VBPA表中存在多条PARVW AG记录系统取第一条ORDER BY VBPA-POSNR ASC而业务期望取最后一条。解决在TVKPT步骤中增加“排序条件”或在USEREXIT_PARTNER_DETERMINATION中重写逻辑。现象 3启用 WM 后交货单合作伙伴变为 WM 系统管理员而非客户。原因T001W表中KUNNR字段被误维护为 WM 管理员客户号且TVKPT步骤 3 被触发。解决清空T001W-KUNNR或在TVKPT中删除步骤 3。6. 设计取舍为什么 SAP 不把交货单类型做成“可编程脚本”而坚持配置表驱动当我第一次在某高校实验室调试一个零售 G 类型交货单时导师指着屏幕上的T189A表说“你看这里每一步都是 SQL 查询不是 ABAP 代码。SAP 故意把业务逻辑从代码里抠出来塞进配置表。”当时不解——难道写死逻辑不更高效直到后来参与某跨平台系统重构才真正懂这种设计的深意。6.1 配置表驱动 vs 代码驱动稳定性与可维护性的根本权衡SAP 交货单类型的所有行为都由T189库存确定、T683T重量组路线、TVKP合作伙伴过程等配置表驱动而非写在LV60A等函数模块里。这种设计带来三个刚性优势热更新能力修改T683T中的重量组匹配规则无需重启应用服务器新单据立即生效。而若逻辑写在 ABAP 代码中每次修改都需传输请求TR、测试、上线平均耗时 4 小时。某快消客户曾因促销临时调整运输路线靠修改T683T在 5 分钟内完成全量切换。多租户隔离同一套 ABAP 代码通过T189表的不同KAPPL应用字段值可为不同客户分配独立的库存确定规则。若用代码实现需为每个客户开发分支版本维护成本指数级上升。审计穿透性所有决策过程可追溯到具体配置表记录。当财务质疑“为何这张退货单分配到仓库 0002”审计员可直接查T189A中VBTYP T的规则步骤看到“步骤 2按批次排序”再查MCH1表确认批次日期——全程无需读代码。但代价是配置爆炸。一个中型客户通常有 12 张交货单类型每张关联 8 张配置表总计近 100 个配置点。新手常陷入“改了 A 表B 表没同步”的泥潭。6.2 如何验证你的交货单类型配置是否真正生效配置生效验证不能只看单据能否保存必须穿透到数据库层面。我给自己定下铁律每次配置变更后强制执行三步验证头寸校验用SE16N查LIKP表筛选VBTYP J且ERDAT TODAY的单据检查LIKP-ROUTE、LIKP-LGNUM、LIKP-KUNAG是否符合预期值行项目溯源对任一单据号查LIPS表确认LIPS-POSNR的分布主物料 vs 包装物料并用VBFA表反查VBFA-VBELN_V是否指向正确销售订单配置链路追踪用SCU0事务码输入交货单号查看“配置影响分析”它会列出本次保存触发的所有配置表如T189,T683T,TVKP及具体记录号。曾有一次客户抱怨“G 类型交货单不显示行项目”我按此流程查SCU0发现T189表中VBTYP G的记录KAPPL字段为空导致库存确定规则未加载。补上KAPPL SD后问题立解。那一刻我彻底信了SAP 的配置表不是累赘是给开发者留的“后悔药”——只要你知道药在哪就能精准解毒。从那以后我每次配置交货单类型都强制走一遍SCU0验证哪怕多花 3 分钟。因为线上问题的修复成本永远是预防成本的 100 倍。希望帮到你。本文还有配套的精品资源点击获取
