简介：本资源是一份聚焦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路径不一致）根因与规避策略，是SAP SD模块配置落地与问题排查的实用型参考指南。
1. SAP-SD里的“交货单类型”到底是什么：就像快递公司的运单模板，选错就发不了货
你有没有遇到过这种场景：在系统里点开“创建交货单”，刚输完订单号，系统突然弹出红色报错——“凭证类型不匹配”“无法参考该订单”“项目不可编辑”……明明货都备好了，单子却卡在第一步？这不是操作手误，而是你没看清背后那个隐形的“指挥官”：交货单类型（Delivery Type）。它不是个普通下拉选项，而是SAP-SD模块中控制整张交货单行为逻辑的“基因编码”。打个比方：它就像快递公司给不同业务配的运单模板——普通电商发货用“标准件运单”（J），退货用“逆向物流单”（T），门店调拨用“内部转运单”（7），而生鲜超市凌晨补货可能要用专属的“冷链零售单”（G）。选错类型，系统连仓库怎么找、包装怎么打、文本怎么印、甚至能不能手动加一行货，全都会按错的模板执行。很多人以为只是改个字母，结果上线后才发现：退货单不能自动带包材、跨公司调拨单漏了路径重算、零售单打印时缺了促销标签……这些都不是Bug，是类型配置没对上业务真实动作。搞懂它，不是为了背下J/7/T/G四个字母，而是掌握一套“让系统听懂你要干什么”的翻译规则。这份资料，就是把这套规则从SAP后台的参数迷宫里拎出来，用你能立刻对照、马上验证的方式讲清楚。
2. 凭证类别与数字系统：为什么J/7/T/G这四个字母能决定整张单的命运
2.1 凭证类别：四张“身份证”，每张对应一套独立行为规则
SAP-SD里所有交货单都必须挂靠一个凭证类别（Document Category），它用单个字母标识，但背后是一整套预设逻辑。这不是命名习惯，而是系统硬编码的触发开关：
- J（Normal Delivery）：最常用的“常规发货单”。它默认启用库存选址、自动包装、路径重算（A模式）、合作伙伴确定等全套功能。当你在销售订单行项目上双击“创建交货单”，系统默认弹出的就是J类型——因为它假设你正要把货发给客户。
- 7（Inbound Delivery）：专为“内向收货”设计。注意，它和采购收货（如MIGO）不同，特指销售端发起的内部调拨，比如A工厂把货调给B仓库。它禁用客户相关字段（如付款条件），但强制启用WM仓库校验（交货分解-仓库编号勾选），因为内部调拨对仓码一致性要求极高。
- T（Returns Delivery）：退货单的“反向引擎”。它自动反转库存移动类型（从+101变成-101），禁用标准输出（不打印运单），但激活退货专用文本确定过程（比如自动生成“退货原因说明”段落）。如果这里误配成J，系统会试图按发货逻辑扣减库存，导致账实严重不符。
- G（Retail Delivery）：零售行业的“特供版”。它默认启用UALL显示范围（所有行项目强制可见），关联POS系统接口字段，并在输出确定过程中跳过部分税务校验——因为超市扫码结账的退货，和工厂发货的流程根本不在一个维度上。
提示：这四个字母不是随便定的。SAP底层用它们索引不同的程序出口（User Exit）和增强点（BADI）。改一个字母，相当于换了一套发动机控制系统，不是换个车标那么简单。
2.2 数字系统：三套编号规则，管住“谁来编号、怎么编号、编到哪”
交货单必须有唯一编号，但编号权可以交给系统或外部。数字系统（Number Range）就是分配这个权力的裁判：
- NR 内部分配（Internal Number Assignment）：系统自动生成流水号。比如设定范围1000000–1999999，那么第1张J单是1000001，第2张是1000002……它保证绝对不重复，但号码无业务含义。适合对编号无特殊要求的场景，比如内部调拨单。
- 外部范围号（External Number Assignment）：由用户或上游系统（如电商平台）输入编号。比如淘宝订单号TB202405001直接作为交货单号。此时系统只做格式校验（长度、字符），不参与生成。但风险在于：若人工输错，系统无法自动纠错，后续对账会卡死。
- 项目号增量（Item Number Increment）：控制行项目编号的步长。默认是10（10,20,30…），这样方便在中间插入新行（比如在10和20之间插一行，编15）。如果业务需要按批次分组（如1001-1099为A批次，2001-2099为B批次），这里就要改成100。否则后期想按批次筛选，数据库里全是散乱数字。
# 示例：SAP后台配置中数字系统的关键字段（事务码OVLP） # NR_INTERNAL = 'X' # 启用内部分配 # NR_EXTERNAL = ' ' # 禁用外部输入 # ITEM_INCR = 10 # 项目号步长为10 # NUMBER_RANGE = 'ZDEL' # 指向编号范围对象ZDEL（含1000000-1999999）这段配置代码说明：当NR_INTERNAL='X'时，系统会从ZDEL范围里取下一个可用号；若ITEM_INCR=10，则第一行项目号为10，第二行为20。如果某次配置把ITEM_INCR错设为1，后续所有行项目号变成1,2,3……表面看没问题，但当业务要按“10开头的项目”批量修改时，SQL查询WHERE ITEM_NO LIKE '10%'将完全失效——因为根本不存在10开头的号。
2.3 订单参考：三道“闸门”，决定这张单能不能脱离订单独立存在
交货单和销售订单的关系，不是简单的“父子”，而是可配置的“契约”。订单参考设置就是签这份契约的条款：
- 要求订单（Order Reference Required）：最严格的“绑定模式”。一旦勾选，创建交货单时必须输入销售订单号（VA01生成的SO），且该订单的类型必须匹配此处定义的“允许的订单类型”。比如这里只允许OR（标准订单），但你输了个RE（退货订单），系统立刻报错：“凭证类型不兼容”。这是防止销售部绕过信用检查直接发货的铁闸。
- 省缺订单类型（Default Order Type）：最灵活的“松绑模式”。勾选后，创建交货单时可以不输订单号（即“无单发货”），但后续开票（VF01）时，系统会强制要求你指定一张订单来生成发票。典型场景是STO（公司间调拨）：工厂A先发一车货到工厂B（无销售订单），等货到了，B再根据实际收货量创建采购订单并开票。这里的“省缺订单类型”就决定了VF01默认带出的发票类型（如IV）。
- 项目需求（Item Determination）：最精细的“行级锁”。设为201时，交货单抬头创建后，行项目区域完全灰显，无法手动新增、删除或修改任何行——所有项目必须从源头订单带过来。设为202则开放编辑。很多企业用201防业务员私加赠品或替换物料；但若遇上紧急补货需临时加一行，201就成了绊脚石。
注意：这三项不是互斥的。比如某零售客户要求“必须有订单才能发货（要求订单=ON），但允许在订单基础上增减数量（项目需求=202）”，就需要同时开启前两项，关闭第三项的限制。
3. 凭证内容与特殊功能：从仓库选址到自动打包，一张单背后的20个决策点
3.1 库存选址规则：系统怎么知道该去哪个仓库捡货？
“库存选址”（Stock Determination Rule）不是简单查库存表，而是一套多层过滤器。它按优先级顺序执行：
- 首选：MRP区域+存储地点（如工厂0001的成品仓1000）
- 次选：批次管理规则（如优先发生产日期最新的批次）
- 兜底：动态计算（如按最小拣货路径，选离打包台最近的仓位）
配置时选中的规则ID（如0001），实际指向后台表T189（库存确定规则）。如果规则里没定义“按批次有效期排序”，而业务要求“先进先出”，那系统永远按入库时间排，过期品可能被优先发出。更隐蔽的坑是：规则本身正确，但未在交货单类型中激活——就像给汽车装了GPS，却忘了打开导航开关。
3.2 输出确定过程：运单、发票、短信，谁先发谁后发？
“输出确定”（Output Determination）本质是事件驱动的自动化流水线。它监听交货单的特定状态变化（如“已保存”“已过账”），然后触发预设动作：
- 时机：
V2（交货单保存时） vsV3（交货单过账时） - 媒介：
LOCL（本地打印机） vsMAIL（邮件） vsEDI（电子数据交换） - 内容：
LD00（标准运单） vsZRET（定制退货通知）
关键陷阱在于：同一张单可能触发多个输出。比如J类型配置了V2+LOCL+LD00（保存即打运单）和V3+MAIL+ZRET（过账后发邮件），但如果网络打印机故障，V2步骤失败，整个交货单保存会被阻塞——因为SAP默认将输出设为“同步执行”。解决方案是把V2改为异步（在输出类型配置中勾选“发送后台作业”），但这就要求运维团队监控后台作业队列，否则运单可能延迟数小时才打出。
3.3 自动包装与包装物料项目：为什么你的包材没自动出现？
自动包装（Automatic Packing）功能依赖三个条件同时满足，缺一不可：
- 包规已建（事务码POP1）：为物料主数据维护包装层级（如1箱=24瓶，1托=40箱）
- 包规已激活（事务码POF1）：在工厂层面启用该包规
- 交货单类型中勾选“自动包装”且“生成包装物料项目”
最常踩的坑在第3步：很多配置员只勾了“自动包装”，却忘了勾“生成包装物料项目”。结果系统计算出需要2个纸箱，但行项目里只有商品，没有纸箱物料行。这是因为“自动包装”只做计算，“生成包装物料项目”才是把计算结果落地为实际行项目的开关。而后者生效还有隐藏条件：包材物料主数据（MM02）中必须维护销售视图，且“包装物料类型”字段（VHAR）不能为空——否则系统认为“这不是可销售的包材”，拒绝生成行项目。
-- 验证包材是否满足条件的SQL（需在SAP HANA或ABAP层执行） SELECT MATNR, VHAR, VTWEG, SPART FROM MARA WHERE MATNR = 'PACK_BOX_001' -- 包材料号 AND VHAR <> '' -- 包装物料类型非空 AND EXISTS ( SELECT 1 FROM MVKE WHERE MATNR = MARA.MATNR AND VTWEG = '10' -- 销售组织10已维护 );这段查询检查包材PACK_BOX_001是否同时满足：有包装类型定义、且在销售组织10下启用了销售视图。如果返回空集，自动包装功能必然失效。
3.4 途径确定：重量组重算路径，A/B模式差在哪？
“途径确定”（Route Determination）解决的是“货走哪条路”的问题。它和订单上的运输路径不是简单继承，而是可重算的：
- 空白：完全继承订单路径，哪怕订单路径是错的也照搬
- A模式：按重量组（Weight Group）重新计算路径，且允许人工覆盖为任意有效路径
- B模式：按重量组重新计算路径，但人工只能覆盖为“计划路径”（Planned Route）
什么是“计划路径”？它定义在表TROAL中，是预先配置好的、经物流部审批的合规路径库。比如：
- 计划路径
R001：上海→南京（高速，限重40吨） - 计划路径
R002：上海→南京（国道，限重20吨）
如果订单没填路径（为空），B模式下你可以自由选R001或R002；但如果订单填了R003（一条未审批的野路），B模式会报错000043，提示“订单路径无效”，强制你改用R001/R002。A模式则不管三七二十一，直接让你选任意路径——灵活性高，但合规风险大。
4. 常见误区与易混概念：J不是“发货”，7不是“收货”，T不是“退货单”
4.1 易混点1：J类型 = 正常发货？
→为什么混：中文翻译“正常交货单”让人以为它覆盖所有发货场景。
→怎么区分：J类型默认启用“客户主数据校验”，如果收货方不是客户主数据里的有效客户（如填了供应商编码），系统会报错。而真正的“无客户发货”（如样品寄送）应该用专门的LF类型（虽不在J/7/T/G之列，但属同一配置体系）。J的本质是“面向客户的销售发货”，不是“所有发货”。
4.2 易混点2：7类型 = 内向收货？
→为什么混：摘要描述写“内向收货单”，但SAP里“内向收货”（Inbound Delivery）特指采购收货（MIGO），而7类型实际是“销售端发起的内部交货”。
→怎么区分：7类型的移动类型是601（销售发货），不是采购的101；它的会计科目走销售成本，不是采购应付。它解决的是“销售组织A把货调给销售组织B”的问题，本质是销售内部流转，不是采购入库。
4.3 易混点3：T类型 = 退货单？
→为什么混：名字叫“退货单”，但T类型创建的单据，会计上仍是“销售发货”（移动类型651），只是方向相反。
→怎么区分：真正的财务退货（冲销收入）需要后续开红字发票（Credit Memo），T类型只管实物退回。如果只建T单不过账，库存不回冲；如果过账但没开红票，利润表虚高。T单是物流动作，红票才是财务动作，二者必须配对。
4.4 易混点4：G类型 = 零售行业专用？
→为什么混：看到“零售”就以为只适用于超市、便利店。
→怎么区分：G类型的核心特征是“弱化客户主数据强管控、强化POS集成”。它禁用部分信用检查，但强制启用UALL显示范围（所有行项目可见）。所以某些快消品企业的分销商返利结算单，因需展示全部返利明细行，也会借用G类型——和零售无关，只因显示逻辑匹配。
4.5 易混点5：“省缺订单类型” = 可以不要订单？
→为什么混：字面理解为“不需要订单”。
→怎么区分：它只是放宽了交货单创建时的输入限制，但后续所有凭证链（尤其是开票VF01）仍强制要求关联订单。所谓“省缺”，是指系统自动帮你填上一个默认订单类型（如OR），而不是真能脱离订单闭环。没有订单的交货单，在财务月结时会成为悬案——无法确认收入，也无法结转成本。
5. 什么时候用、什么时候别用：一份来自血泪经验的配置决策清单
5.1 选J类型的黄金场景与死亡红线
该用J的时候：
- 标准B2B销售：客户下单→工厂备货→发货→开票→收款，全流程闭环。
- 客户有完整主数据（含信用额度、付款条件、地址），且所有字段需严格校验。
- 需要全程跟踪：从拣货（WM）→打包→运输→签收（ASN），每个环节都要留痕。
绝对别用J的时候：
- ✖️ 给内部部门发样品（收货方无客户主数据）→ 改用
LF或自定义类型 - ✖️ 处理客户投诉补发（需关联原订单但原订单已关闭）→ 改用
RE（退货相关交货）配合特殊订单类型 - ✖️ 跨公司调拨（收货方是另一家法人）→ 必须用
NLCC（公司间交货），J类型无法过账
血泪教训：某公司曾用J类型处理经销商返利实物兑付，因返利单无正式销售订单，强行关联测试订单。结果月结时系统发现“J单无对应开票凭证”，自动冻结所有J类型交货单过账，导致当月300+张发货单积压，物流停摆2天。从那以后，我们每次配置新业务场景，都强制走一遍“凭证流沙盘推演”：从创建交货单→过账→开票→收款，每一步检查类型是否匹配。
5.2 7类型与T类型的生死边界：一张单，两个世界
7类型（内向交货）的适用边界：
| 场景 | 是否适用 | 原因 |
|---|---|---|
| 工厂A调货给工厂B（同集团） | ✔️ | 属于销售组织内部流转，移动类型601 |
| 供应商直送VMI仓（货权属我司） | ✖️ | 这是采购行为，应走MIGO收货 |
| 客户退货暂存质检区（待判定） | ✖️ | 实物在客户处，应走T类型先收货 |
T类型（退货交货）的适用边界：
| 场景 | 是否适用 | 原因 |
|---|---|---|
| 客户拒收整单货物（货在运输途中） | ✔️ | 创建T单，移动类型651，库存回冲 |
| 客户退回部分货物（需重新发货补足） | ✔️ | T单过账后，立即建新J单补发，形成闭环 |
| 仓库盘点发现短少（无客户退货） | ✖️ | 这是盘亏，应走711移动类型做库存调整 |
关键区别：7类型是“销售组织主动发起的内部调拨”，T类型是“响应客户退货请求的被动接收”。混淆二者，轻则库存账实不符，重则引发集团内关联交易税务稽查风险。
5.3 G类型的隐藏陷阱：零售≠所有线下场景
G类型看似为零售设计，但真正决定是否启用它的，是三个技术参数：
DISPLAY_RANGE = 'UALL'（必须显示所有行项目）OUTPUT_TYPE = 'ZPOS'（必须对接POS系统输出）PARTNER_DETERMINATION = '0002'（合作伙伴确定过程跳过客户主数据校验）
如果某次配置只改了DISPLAY_RANGE，其他两项没配，G单就会：
- 在前台显示所有行（符合预期）
- 但打印运单时崩溃（因ZPOS输出类型未定义）
- 且收货方地址栏为空（因合作伙伴确定失败）
安全替代方案：当只需“显示所有行”时，直接在交货单类型中将DISPLAY_RANGE设为UALL，类型仍用J。G类型应是“三参数齐备”的完整解决方案，而非仅解决显示问题的快捷方式。
5.4 数字系统的致命组合：外部编号+项目号增量=灾难
曾有个案例：某电商客户要求交货单号=淘宝订单号（外部编号），同时因促销活动需频繁拆单，要求项目号步长为1（1,2,3…）。配置员照做了，结果上线后：
- 第1张单：TB1000001，项目1,2,3
- 第2张单：TB1000002，项目1,2,3（因步长1，系统从1开始重计）
- 导致所有报表按项目号排序时，TB1000001的第3行和TB1000002的第1行混在一起，无法区分归属
正确解法：外部编号必须配内部分配的项目号（即NR_INTERNAL='X'+ITEM_INCR=10）。系统会为每张单独立生成项目号（TB1000001:10,20,30；TB1000002:10,20,30），既满足外部单号要求，又保证行项目可追溯。
5.5 最后一道防线：配置前必做的三件事
- 画凭证流图：手绘从销售订单→交货单→发票→收款的每一步，标出每张单的类型、移动类型、会计科目。如果某环节类型缺失或冲突，立刻停止配置。
- 跑沙盒测试：在测试系统用真实数据走一遍全流程，重点验证：
- 创建交货单时能否顺利进入？
- 过账后库存移动是否正确？（用MB51查移动类型）
- 开票时能否自动带出正确发票类型？（VF01抬头字段）
- 查后台表依赖：确认所有启用的功能（如自动包装、途径重算）所依赖的后台表（POP1/POF1/TROAL等）均已维护，且数据状态有效。
希望帮到你。
本文还有配套的精品资源，点击获取
