★ FEATURED ARTICLE 简介本资源是一份聚焦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它用单个字母标识但背后是一整套预设逻辑。这不是命名习惯而是系统硬编码的触发开关JNormal Delivery最常用的“常规发货单”。它默认启用库存选址、自动包装、路径重算A模式、合作伙伴确定等全套功能。当你在销售订单行项目上双击“创建交货单”系统默认弹出的就是J类型——因为它假设你正要把货发给客户。7Inbound Delivery专为“内向收货”设计。注意它和采购收货如MIGO不同特指销售端发起的内部调拨比如A工厂把货调给B仓库。它禁用客户相关字段如付款条件但强制启用WM仓库校验交货分解-仓库编号勾选因为内部调拨对仓码一致性要求极高。TReturns Delivery退货单的“反向引擎”。它自动反转库存移动类型从101变成-101禁用标准输出不打印运单但激活退货专用文本确定过程比如自动生成“退货原因说明”段落。如果这里误配成J系统会试图按发货逻辑扣减库存导致账实严重不符。GRetail 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控制行项目编号的步长。默认是1010,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_INTERNALX时系统会从ZDEL范围里取下一个可用号若ITEM_INCR10则第一行项目号为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类型配置了V2LOCLLD00保存即打运单和V3MAILZRET过账后发邮件但如果网络打印机故障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 易混点1J类型 正常发货→为什么混中文翻译“正常交货单”让人以为它覆盖所有发货场景。→怎么区分J类型默认启用“客户主数据校验”如果收货方不是客户主数据里的有效客户如填了供应商编码系统会报错。而真正的“无客户发货”如样品寄送应该用专门的LF类型虽不在J/7/T/G之列但属同一配置体系。J的本质是“面向客户的销售发货”不是“所有发货”。4.2 易混点27类型 内向收货→为什么混摘要描述写“内向收货单”但SAP里“内向收货”Inbound Delivery特指采购收货MIGO而7类型实际是“销售端发起的内部交货”。→怎么区分7类型的移动类型是601销售发货不是采购的101它的会计科目走销售成本不是采购应付。它解决的是“销售组织A把货调给销售组织B”的问题本质是销售内部流转不是采购入库。4.3 易混点3T类型 退货单→为什么混名字叫“退货单”但T类型创建的单据会计上仍是“销售发货”移动类型651只是方向相反。→怎么区分真正的财务退货冲销收入需要后续开红字发票Credit MemoT类型只管实物退回。如果只建T单不过账库存不回冲如果过账但没开红票利润表虚高。T单是物流动作红票才是财务动作二者必须配对。4.4 易混点4G类型 零售行业专用→为什么混看到“零售”就以为只适用于超市、便利店。→怎么区分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 数字系统的致命组合外部编号项目号增量灾难曾有个案例某电商客户要求交货单号淘宝订单号外部编号同时因促销活动需频繁拆单要求项目号步长为11,2,3…。配置员照做了结果上线后第1张单TB1000001项目1,2,3第2张单TB1000002项目1,2,3因步长1系统从1开始重计导致所有报表按项目号排序时TB1000001的第3行和TB1000002的第1行混在一起无法区分归属正确解法外部编号必须配内部分配的项目号即NR_INTERNALXITEM_INCR10。系统会为每张单独立生成项目号TB1000001:10,20,30TB1000002:10,20,30既满足外部单号要求又保证行项目可追溯。5.5 最后一道防线配置前必做的三件事画凭证流图手绘从销售订单→交货单→发票→收款的每一步标出每张单的类型、移动类型、会计科目。如果某环节类型缺失或冲突立刻停止配置。跑沙盒测试在测试系统用真实数据走一遍全流程重点验证创建交货单时能否顺利进入过账后库存移动是否正确用MB51查移动类型开票时能否自动带出正确发票类型VF01抬头字段查后台表依赖确认所有启用的功能如自动包装、途径重算所依赖的后台表POP1/POF1/TROAL等均已维护且数据状态有效。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
