简介：本资源是一份聚焦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/7/T/G背后是整套物流控制逻辑的开关
你有没有在SAP SD模块里点开VL01N建交货单时，对着那个“交货类型”下拉框发过呆？选个J就发货，选个T就退货——看起来只是四个字母的事。但某次上线后客户突然发现：同一张销售订单，用J类型能顺利过账，换成G类型却卡在拣配环节；又或者内向收货单（7）明明按流程创建了，系统却拒绝生成发票凭证。这不是配置漏了，而是你没意识到：交货单类型（Delivery Type）根本不是文档标签，而是整条物流链路的控制中枢。它决定着库存移动方向、仓库确认逻辑、包装行为触发、路径重算规则、甚至后续财务凭证的生成路径。J代表标准出库流，7对应内部收货闭环，T强制启用退货质检，G则绕过常规WM校验直连零售POS接口。这份配置不是给用户看的，是给系统引擎下指令的——每个字段都在告诉SAP：“当这个类型被激活时，请按此规则接管拣货、打包、运输、记账全部动作”。适合谁？不是只给ABAP开发看，而是所有SD顾问、物流方案设计师、WMS集成工程师必须亲手调过、测过、翻过日志的底层开关。别再把它当静态主数据，它是动态业务流的DNA。
2. 凭证类别与数字系统：从J/7/T/G到编号规则的硬编码逻辑
交货单类型的凭证类别（Document Category）看似只是四个字母，实则是整个物流凭证生命周期的起点标识。它不参与运算，但像一把钥匙，决定了后续所有编号规则、状态流转、凭证关联的走向。而数字系统（Number Range）则是这套逻辑的执行层——没有它，J类型永远无法生成一个合法的交货单号。这两者必须咬合，否则系统会在VL01N保存瞬间抛出“未维护编号范围”的致命错误。
2.1 凭证类别的四象限控制：J/7/T/G不是并列关系，而是业务流向矩阵
SAP中J、7、T、G并非简单分类，而是按“移动方向”和“业务场景”划分的控制矩阵：
| 凭证类别 | 移动方向 | 典型业务场景 | 关键控制点 | 常见误配后果 |
|---|---|---|---|---|
| J | 销售出库（Plant → Customer） | 标准客户发货 | 触发库存减少、自动拣配、标准输出类型V2 | 若误配为7，系统会尝试做库存增加，过账失败 |
| 7 | 内向收货（Vendor → Plant） | 供应商到货、厂间调拨 | 启用GRN校验、采购订单强关联、禁用销售组织字段 | 当用于客户退货时，物料主数据销售视图未维护导致报错 |
| T | 退货入库（Customer → Plant） | 客户退货、质量退库 | 强制启用退货质检流程、反向库存移动、特殊移动类型651 | 若未配置退货原因代码，系统无法生成会计凭证 |
| G | 零售直送（Store → POS） | 连锁门店补货、POS系统对接 | 绕过WM仓库校验、启用零售特定文本确定过程、支持UALL显示范围 | 在非零售环境启用G，会导致拣配单无法打印（缺少零售输出条件） |
提示：凭证类别在表TVLST中定义，但真正起作用的是其关联的“交货类型”（如J对应LF，7对应RE，T对应LR，G对应GR）。不要只改TVLST，必须同步检查OVLK中交货类型与凭证类别的映射关系。
2.2 数字系统三要素：NR内部分配、外部范围号、项目号增量的协同机制
数字系统不是三个独立配置项，而是一个编号生成流水线。以J类型为例，当你在VL01N输入交货类型J并回车，系统按以下顺序组装单据号：
NR内部分配（Internal Number Assignment）：从编号范围对象（Number Range Object）
DELIVERY中获取下一个可用号，写入交货单抬头字段VBELN。该对象在事务码OVKK中维护，必须为J类型分配独立区间（如10000000-19999999），且状态为“已激活”。外部范围号（External Number Range）：若勾选“外部编号”，系统跳过NR分配，直接使用用户在抬头输入的编号。但此时必须满足：该编号未被其他交货单占用，且符合
VBELN字段长度限制（10位字符）。常见翻车点：用户输入含字母的编号（如J20240001），但VBELN字段为纯数字域，系统静默截断为20240001，导致后续对账混乱。项目号增量（Item Number Increment）：行项目编号（
POSNR）并非简单+10，而是由交货类型参数ITEM_INCR控制。在OVLP中为J类型设置ITEM_INCR = 10，则首行项目为000010，第二行为000020。但若启用了“交货分解”（见第4章），系统会为每个分解后的子交货单重新生成项目号序列，此时ITEM_INCR仅作用于原始交货单的行项目。
验证配置是否生效的最简方法：在VL01N中不输入任何编号，直接按回车，观察抬头编号是否自动生成且连续。若生成失败，立即检查OVKK中编号范围对象DELIVERY的状态及区间是否被其他交货类型复用。
2.3 订单参考的强弱约束：从“必须关联”到“默认继承”的灰度控制
订单参考（Order Reference）配置决定了交货单与上游单据的耦合强度。它不是非黑即白的开关，而是三级灰度控制：
要求订单（Mandatory Reference）：勾选此项后，VL01N中必须输入参考单据（如销售订单VA01的订单号）。若用户试图创建无参考的J类型交货单，系统报错
VL089：“必须输入参考凭证”。但注意：该约束仅对“预定义交付类型”生效。若用户在VL01N中先输入J，再手动清空参考单据字段，系统不会实时校验——直到点击“保存”才抛错。省缺订单类型（Default Order Type）：这是最易被误解的字段。它不控制当前交货单的创建，而是为后续凭证（如VF01开票）提供默认值。例如，在STO（公司间销售）场景中，交货单类型J的“省缺订单类型”设为
UB（公司间订单），则当用户在VF01中为该交货单开票时，系统自动带出订单类型UB，无需手动选择。若此处为空，VF01将弹出订单类型选择框，打断自动化流程。项目需求（Item Requirement）：
201与202的区别在于行项目编辑权限。设为201时，VL01N中“添加项目”按钮置灰，用户无法手动插入新行；设为202则允许。但关键细节是：该控制仅作用于交货单创建阶段（VL01N），对交货单修改（VL02N）无效。某次某公司上线后，业务员抱怨“不能加赠品”，排查发现交货类型J的项目需求被误设为201，而赠品需作为额外行项目加入。
注意：订单参考配置在
OVLP中维护，但实际生效依赖于交货类型与销售订单类型的匹配。例如，J类型要求参考订单，但销售订单类型OR未在OVAK中启用“允许创建交货单”，则即使配置正确，VL01N仍无法引用该订单。
3. 凭证内容与途径确定：仓库选址、路径重算、输出控制的实战配置
凭证内容（Document Content）配置是交货单类型中最厚的模块，它把抽象的业务规则翻译成SAP可执行的动作。这里没有“大概可以”，只有“必须精确”。比如库存选址规则决定拣货从哪个仓库开始找货，途径确定规则决定运输路径是否重算，而输出类型则绑定着发票打印、EDI传输等下游动作。任何一个参数偏差，都会在VL01N保存后、VL06P打印前、甚至VF01开票时集中爆发。
3.1 库存选址规则（Stock Determination Rule）：让系统知道“货在哪，去哪找”
库存选址规则（在OVLP中配置字段STOCK_DETERM）不是简单的仓库代码映射，而是基于库存状态、批次、特殊库存标识的多维决策树。以J类型为例，常见配置组合：
规则Z1（标准销售出库）：
Stock Type = 'Unrestricted'（非限制使用库存）Special Stock = ' '（非特殊库存）Storage Location = 'From Sales Order'（从销售订单行项目取仓）
此规则确保拣货优先使用销售订单指定的仓库，避免跨仓调拨。规则Z2（紧急补货）：
Stock Type = 'Unrestricted'Special Stock = 'Q'（质检库存）Storage Location = '0001'（固定质检仓）
当销售订单承诺交期紧张时，系统允许从质检仓释放库存（需配合QM模块启用）。
配置错误的典型现象：用户在VL01N中输入销售订单，系统自动带出仓库0001，但实际库存全在0002，导致拣配单为空。根源是库存选址规则未包含0002，或规则中Storage Location被硬编码为0001。解决方案不是改仓库代码，而是检查OVLP中J类型的STOCK_DETERM是否指向正确的规则，再进入OVK3确认该规则是否覆盖0002。
3.2 途径确定（Route Determination）：A/B/空白三档策略的物理意义
途径确定（ROUTE_DETERM字段）是交货单类型中最具迷惑性的配置。它不决定运输路线本身，而是决定“是否允许系统根据新条件重算路线”。选项A、B、空白的差异本质是权限控制：
空白（No Route Determination）：系统完全忽略交货单级别的路径重算。路径直接从销售订单继承，哪怕订单路径是
ROAD（公路），交货单重量超限应走RAIL（铁路），系统也强行用ROAD。这是最保守的配置，适用于路径高度稳定的场景（如固定专线运输）。A（Re-determine Route Freely）：系统根据交货单的重量组（Weight Group）、装运点（Shipping Point）、目的地址，重新计算路径。计算结果写入交货单抬头字段
ROUTE，且用户可在VL02N中手动修改为任意有效路径。某次某公司因A配置导致问题：销售订单路径为AIR（空运），交货单因单件超重被重算为SEA（海运），但业务员未注意，仍按空运发货，造成客户投诉。B（Re-determine Route with Restrictions）：系统重算路径，但用户只能修改为
TROAL表中预定义的“认可路径”。例如，TROAL中为重量组HEAVY定义了RAIL和ROAD为认可路径，则即使重算结果为AIR，用户也无法选择，只能在RAIL/ROAD间切换。配置B时必须确保TROAL已维护，否则系统报错000043：“未找到计划路径”。
验证途径确定是否生效：在VL01N中创建交货单，输入销售订单后，观察抬头字段ROUTE是否变化。若不变，检查OVLP中ROUTE_DETERM值及TROAL表是否激活。
3.3 输出确定过程（Output Determination Procedure）与输出类型（Output Type）的绑定逻辑
输出确定过程（OUTPUT_PROC）是交货单的“通知引擎”，它决定何时、以何种方式发送交货信息。而输出类型（OUTPUT_TYPE）是具体的通知载体，如LD00（交货单打印）、EDIFACT（EDI传输）。二者通过条件技术（Condition Technique）绑定：
输出确定过程配置（OVK3）：为J类型分配过程
V30000，该过程包含条件记录（Condition Record），如001（交货单创建时触发）、002（交货单过账时触发）。输出类型配置（V30）：在
V30中为LD00定义输出设备（如打印机LP01）、格式（如SAPscriptRVORDER01）、时间（如1表示立即输出）。
关键陷阱：若J类型的OUTPUT_TYPE在OVLP中设为LD00，但V30中LD00的输出设备未分配或离线，VL01N保存后不会报错，但VL06P打印时提示“输出设备不可用”。更隐蔽的问题是：OUTPUT_PROC中条件记录的“应用”字段（Application）必须为V3（交货单），若误设为V1（销售订单），则交货单永远无法触发输出。
提示：调试输出失败的最快方法是运行
VL02N打开交货单，点击“环境→输出→输出控制”，查看“输出状态”栏。绿色对勾表示已触发，红色叉号表示条件不满足，黄色感叹号表示设备异常。
4. 避坑：交货单类型配置的12个血泪经验与现场排查指南
交货单类型配置是SAP SD中最容易“表面正常、暗地崩坏”的模块。很多问题在VL01N创建时毫无征兆，直到VL06P打印失败、VF01开票报错、甚至月结时发现库存数量对不上。以下是我在多个项目中踩过的坑，按现象、原因、解决三步法整理，每一条都来自真实生产环境。
4.1 现象：交货单创建成功，但VL06P打印时提示“未找到输出类型”
原因：OVLP中交货类型J的OUTPUT_TYPE字段为空，或虽有值（如LD00）但V30中该输出类型未激活（Status =Inactive）。
解决：进入V30，输入输出类型LD00，检查“状态”字段是否为Active。若为Inactive，点击“激活”按钮；若OVLP中OUTPUT_TYPE为空，返回OVLP为J类型填入正确的输出类型代码。
4.2 现象：内向收货单（7）无法过账，报错M7055：“移动类型601不允许用于此凭证类别”
原因：凭证类别7在TVLST中未正确映射到移动类型601（内向收货），或移动类型601在OMJJ中未启用“允许用于交货单”。
解决：先查TVLST，确认凭证类别7的字段BWART（移动类型）是否为601；再进OMJJ，输入移动类型601，在“允许的凭证类型”页签中勾选LF（交货单）。
4.3 现象：G类型交货单在零售门店发货时，行项目不显示（UALL失效）
原因：OVLP中G类型的“显示范围”（Display Scope）字段未设为UALL，或虽设为UALL但OVK4中G类型的屏幕顺序组（Screen Sequence Group）未包含行项目屏幕（如0002）。
解决：在OVLP中确认G类型的DISP_SCOPE为UALL；再进OVK4，为G类型分配屏幕顺序组（如0001），并确保该组在OVK5中已维护行项目屏幕。
4.4 现象：启用“自动包装”后，交货单中未生成包材行项目
原因：包材物料主数据（MM02）中“包装物料类型”（Packaging Material Type）未维护，或虽维护但VHAR（包装属性）字段为空，或交货类型J未勾选“生成包装物料项目”。
解决：用MM02打开包材物料，进入“基本数据2”视图，检查VHAR字段是否填写（如BOX）；再进OVLP，确认J类型的GEN_PACK_ITEM（生成包装物料项目）已勾选。
4.5 现象：交货分解-仓库编号启用后，同一交货单中不同行项目WM仓码不一致，但未报警告
原因：OVLP中J类型的WM_CHECK（WM检查）字段未勾选，或虽勾选但OVLP中“交货分解合作伙伴”配置错误，导致WM校验逻辑未触发。
解决：在OVLP中确认J类型的WM_CHECK为X；再检查OVLP中“交货分解合作伙伴”字段是否与WM模块的合作伙伴功能匹配（通常为WE）。
5. 特殊功能与事务流：从自动包装到屏幕顺序的端到端验证技巧
特殊功能（Special Functions）和事务流（Transaction Flow）配置是交货单类型中“看不见的手”，它们不直接出现在VL01N界面，却在后台默默驱动着业务流。比如自动包装不是点一下按钮就生效，它需要包材主数据、交货类型参数、甚至销售订单行项目的多重校验；而屏幕顺序组则决定了用户在VL01N中看到的字段布局，直接影响操作效率。这些功能的验证不能只靠“能保存”，必须走通端到端业务流。
5.1 自动包装的三层校验：从POF1激活到VL01N生成的完整链路
自动包装（Automatic Packing）的生效不是单点配置，而是三层校验链：
包材主数据层（MM02）：
- 进入包材物料主数据，选择“基本数据2”视图；
- 检查
VHAR（包装属性）字段是否填写（如BOX、PAL）； - 检查“销售”视图中，销售组织、分销渠道、产品组是否维护完整；
- 检查“MRP”视图中，“包装物料类型”（Packaging Material Type）是否为有效值（如
BOX）。
交货类型层（OVLP）：
- 确认J类型的
AUTO_PACK（自动包装）已勾选； - 确认
GEN_PACK_ITEM（生成包装物料项目）已勾选； - 确认
PACKING_CTRL（包装控制）字段是否为1（标准包装）或2（高级包装）。
- 确认J类型的
销售订单层（VA01）：
- 在销售订单行项目中，必须维护“包装物料”字段（
PKMAT），且该物料必须是步骤1中定义的包材； - 行项目类型（Item Category）必须支持包装，如
TAN（标准行项目）；若为TANN（无库存行项目），则不触发包装。
- 在销售订单行项目中，必须维护“包装物料”字段（
验证方法：在VA01中创建销售订单，行项目输入物料+包材（PKMAT），保存后进入VL01N，输入该订单号，系统应自动在交货单行项目中生成包材行（物料号为包材号，数量=计算值）。若未生成，用SE37调用函数RV_PACKING_CREATE，传入交货单号，查看返回消息。
5.2 屏幕顺序组（Screen Sequence Group）与显示范围（Display Scope）的协同效应
屏幕顺序组（SCREEN_SEQ）和显示范围（DISP_SCOPE）共同决定了VL01N的用户体验。DISP_SCOPE控制“显示哪些行项目”，SCREEN_SEQ控制“这些项目以什么顺序、什么分组显示”。二者不协同，就会出现“该显示的没显示，不该显示的堆满屏”。
UALL（显示所有行项目） + 屏幕顺序组0001：
0001组在OVK5中定义为：屏幕0001（抬头）→ 屏幕0002（行项目）→ 屏幕0003（合作伙伴）。此时VL01N打开即显示所有行项目，且按标准顺序排列。UHAU（仅显示主要行项目） + 屏幕顺序组0002：
0002组在OVK5中可能只包含屏幕0001和0002，但0002的“显示条件”设为ITEM_CAT = 'TAN'。此时只有类型为TAN的行项目显示，其他（如赠品TANN）被隐藏。
关键排查点：若配置了UALL但VL01N仍不显示行项目，不是DISP_SCOPE错了，而是SCREEN_SEQ中未包含行项目屏幕（0002）。进入OVK4，为交货类型J分配屏幕顺序组（如0001），再进OVK5，确认0001组中0002屏幕的状态为Active。
5.3 文本确定过程（Text Determination Procedure）的调试心法：从VOFM到VL02N的追踪路径
文本确定过程（TEXT_PROC）常被忽视，但它决定着交货单上客户看到的“发货说明”“运输要求”等关键信息。调试文本不显示，不能只查OVLP，必须走通以下路径：
- 确认文本确定过程分配：在
OVLP中查J类型的TEXT_PROC字段，如V10000； - 检查过程配置：进
VOFM，输入过程V10000，确认其包含条件类型（如001）及访问序列（Access Sequence）； - 验证访问序列：进
VOFM，打开访问序列，确认其包含正确的条件表（如301：交货单+物料）及字段（如VBELN、MATNR）； - 检查文本主数据：用
SO10创建文本，名称为V10000，语言E，内容为测试文本； - 最终验证：在VL02N中打开交货单，点击“编辑→文本→文本概览”，查看文本是否列出。若未列出，用
SE37调用READ_TEXT，传入ID = 'V10000'、OBJECT = 'VBBK'、NAME = '交货单号'，看是否返回文本内容。
从那以后我每次配置新交货类型，都强制走一遍这五步：先在OVLP中填完所有字段，再进OVK3配输出过程，接着用VOFM跑文本链路，然后在VL01N建单测试基础保存，最后用VL02N逐项验证输出、文本、包装。少走一步，上线后就得多花三天排查。希望帮到你。
本文还有配套的精品资源，点击获取
