企业官网建设流程全解析

简介：SAP-SD交货单类型专题PDF，面向SAP实施顾问及SD模块业务人员，系统讲解交货单类型的定义与关键配置参数。资源为单份PDF文件，大小191KB，内容精炼便于查阅；已有985人学习下载。文档按凭证类别、数字系统、订单参考、凭证内容、错误处理、特殊功能、事务流等模块展开：逐一说明J、7、T、G四类凭证（正常交货、内向收货、退货、零售）的适用场景，讲解NR内部分配与外部范围号，订单参考中的“要求订单”“省缺订单类型”及项目需求201/202规则；凭证内容部分涉及库存选址、输出确定、文本确定、应用程序V2、途径确定等设置，特殊功能涵盖交货分解-仓库编号、自动包装、包装物料项目生成、再计划、分配模式等，并对000043路径报错和WM仓库冲突提示给出处理逻辑。读者可据此快速定位配置项，理解各参数对销售发货、退货、库存转移等业务的影响，减少上线与运维期的配置疏漏。

1. 交货单类型配置翻车：同样是开出货单，为什么你的 VL01N 一直报错

每次做 SAP SD 模块上线或运维，最容易被低估的就是交货单类型。它看起来只是后台配置里的几个字段，但凭证类别、编号规则、订单参考、库存选址、途径确定这些选项一旦组合不当，VL01N 建单就会直接报错——有的提示参考单据不允许，有的编号范围溢出，有的干脆行项目区域一片空白。SAP 在这里的报错往往只给一个消息号，不给解决方案，查到最后才发现根因全在交货单类型这一屏配置里。这篇笔记把交货单类型里每个字段都拆开讲，配上报错对照和排查顺序，新手能照着后台一步一步改，老手也能补上几个平时容易忽略的关联字段。

2. 凭证类别 J/7/T/g 与编号范围：选错类别，交货单根本建不出来

2.1 凭证类别不是业务类型：J、7、T、g 各管什么场景

很多人第一次打开交货单类型的后台配置，看到凭证类别一栏的候选值只有 J、7、T、g，会以为是系统里的乱码或者编号占位符。实际上凭证类别才是这张出货单最底层的身份标识，业务上常说「这是正常发货」「这是退货」，系统只认这个字段。

• J：正常出货单。绝大多数标准销售发货走这个类别，开销售订单、做交货过账、生成应收，整条链路默认按 J 处理。
• 7：内向收货单。这个类别最容易误解，它常常出现在 STO（库存转储）业务里，工厂 A 发出货物用 J 类别的外向交货，工厂 B 收货对应的就是类别 7 的内向交货单，也用来处理向供应商收货的场景。
• T：退货单。客户退货时用，后续要不要做质检、要不要触发退货补发，都由这个类别背后的流程决定。
• g：零售行业使用。注意配置里显示的是小写 g，不是大写，复制类型时下拉列表里不仔细看很容易选错。

凭证类别决定了这张单据后续往哪走，而不是「这张单子属于哪个业务部门」。真实项目里最常见的翻车方式，是把退货单类型复制后忘了核对类别，结果退货单走成了正常发货的流程，仓库按销售发货去拣配，财务还按正常收入去开票，等到月底对账才发现整条链路都是歪的。所以建新类型时，第一件事就是确认凭证类别没有被复制错。

还有一点要记住：凭证类别和货物移动类型的搭配是系统层面的规则。类别 7 的内向收货单如果配上了一个外向交货的移动类型，过账时会出现移动类型与凭证类别不匹配的报错。这类报错不是业务数据问题，是类型定义问题，排查时要往配置层看。

2.2 数字系统：NR 内部分配、外部范围号、项目号增量怎么配

「数字系统」这一块是交货单类型里编号相关参数的集合，它决定了一张交货单的号码从哪来、以什么规则递增。配置区域里包含三个关键项：

NR 内部分配是最常用的做法。系统维护好之后，VL01N 建单会自动取号，业务人员不需要关心单据编号。这里的关键操作在编号范围维护，需要给交货单类型分配一个合法的编号范围区间，并且分配给对应的公司代码或工厂。如果编号范围区间用完，前台表现就是「建单到一半系统报错，提示编号范围溢出」，后台日志里能看到具体的编号范围对象。

外部范围号适合接口传入单据的场景。有些公司做电商中台，交货单号希望用中台生成的订单号，这时就把外部范围号打开。但这个配置的坑在于：外部编号不是「随便填」，编号必须落在外部范围定义好的区间里，而且不能和已有单据重复。如果外部范围没配好，系统会提示号码不在范围，业务人员完全看不懂这个报错。

项目号增量这块，正文里说的是「子项目增加规则」。最直白的理解是：行项目编号的步长。假如增量是 10，那么第一个行项目编号是 10，第二个是 20，中间留出的空间可以给后来插入的行项目。如果增量是 1，项目编号就是 1、2、3，插入一行就要把后面的编号全部推移。在频繁需要后补行项目的业务里，项目号增量建议留出余量。

2.3 新建交货单的典型报错对照

交货单类型相关的配置错误，大多在建单或过账时暴露。下面这张表是项目里整理过的报错对照，排查时可以先按这张表定位：

这里想强调一个操作习惯：SAP 的报错文本往往很简短，但消息号是定位的钥匙。遇到报错先记下消息号，再打开消息维护或直接查消息文本，确认这条报错到底校验的是哪个字段。很多字段级的配置错误，光看报错弹窗根本猜不到是交货单类型引起的，必须顺着消息号回查配置字段。

3. 订单参考规则：要求订单和省缺订单类型如何卡死出货单

3.1 要求订单：预定义交付类型与参考单据不匹配，系统直接拒绝

「要求订单」这个字段，字面意思是：这类交货单是否必须参考订单创建。真正容易踩坑的是它和「预定义交付类型」的联动关系。

正文里有一段非常绕的描述：当开出货单时输入预定义交付类型，参考的单据必须符合此处选择的规则；如果参考订单创建，而指定的出货单类型要求参考采购订单创建，就会报错；如果没有输入预定义交付类型，则不受此处规则影响。

拆开来说，VL01N 创建交货单时，抬头位置有一个「按凭证类型的凭证」之类的字段，这个字段允许你预先把交货单类型指定好。一旦指定，交货单类型里的「要求订单」规则就会被激活校验：系统会拿你实际参考的那张单据的类别，去和交货单类型允许参考的类别比对。比如交货单类型被设置成必须参考采购订单创建，但你实际选了一张销售订单作为参考依据，系统直接拒绝创建。

真实项目里最玄学的场景是：同一个交货单类型，业务员有时候能参考销售订单建单，有时候不能。查下来发现，能建单的时候抬头没有输入预定义交付类型，不能建单的时候用户多填了一个类型字段。这个联动关系不做内部培训，用户永远以为是自己操作失误。

排查步骤很简单：先在 VL01N 开单界面看是否输入了预定义交付类型；再回到后台看这个类型的「要求订单」规则；最后比对参考单据的类别是不是规则允许的。如果业务上确实允许参考多种来源，最简单的做法是建单时不强制输入预定义交付类型，让系统按默认逻辑走；如果必须控制，就把「要求订单」的校验类别改成实际业务会用到的订单类别。

3.2 省缺订单类型：STO 业务下公司间发票默认类型从哪来

「省缺订单类型」这个字段的名字容易让新手懵住，其实「省缺」就是「缺省/默认」的意思。它的完整含义是：这类交货单不要求必须参考订单创建，但后续生成的凭证需要参考一个订单类型时，系统默认从这个字段指定的订单类型里继承。

这不是一句空话。正文里给了 STO 的典型例子：使用库存转储订单（STO）业务模式时，开立公司间发票，默认的发票类型来自交货单类型上「省缺订单类型」所指向的订单类型的默认发票类型。

完整链路是这样的：STO 单据产生了交货单，交货单过账后要开公司间发票，开票前系统需要一个订单类型作为默认来源，它不会凭空生成，而是去交货单类型上找「省缺订单类型」，再顺着这个订单类型去取它上面定义的默认发票类型。中间任何一个环节引错了，最终开出来的公司间发票就不是你想要的那个类型。

这个字段的坑在于：它本身不报错，只会让后续单据类型静默地「跑偏」。比如你发现公司间发票默认成了标准订单发票，而不是公司间开票类型，业务上看起来像是输出配置的问题，但查发票类型定义之前，应该先回头看交货单类型的「省缺订单类型」是不是指向了错误的订单类型。正确的配置逻辑是让交货单类型指向那张能代表业务本质的订单类型，再由它带出后续的单据类型，这样整个链条的默认值才一致。

配置时还有一个容易被忽略的点：这个字段只影响「不参考订单创建」的情况。如果交货单在创建时已经参考了真实订单，后续凭证的默认类型会优先跟随参考的订单，而不是这里配置的类型。所以真正让「省缺订单类型」发挥作用的场景，就是那些允许无单发货、后续再补单据的业务流程。

3.3 项目需求 201/202：能否手动加行项目的开关

项目需求这个字段直接控制交货单行项目的可编辑性。正文给的定义非常直接：如果设置为 201，则无法手动在交货单中增加项目；设置为 202 则可以。

场景上，201 适合严格按订单交货的业务。比如电商大促发货，订单上有几个行项目，仓库就得按这几个行项目拣货，不允许现场加赠品、补物料。一旦允许手动添加行项目，可能出现订单上没有的料被发出去，后续开票、成本归集全部对不上。202 则给了仓库现场灵活性，缺一个料可以临时补一行，或者加一行包装材料费。

这个字段带来的报错不是那种红色报警弹窗，而是「想干的事做不了」：拣配时发现少一个料，用户在交货单行项目里点了增加按钮，发现行项目区域是只读的，或者保存时被系统拦下来，提示不能增加项目。第一次遇到的人会觉得是权限问题，跑到权限角色里查了半天，实际上根因在交货单类型的项目需求配置。

调整建议：如果业务确实允许添加行项目，把 201 改成 202 之前，先确认行项目类别确定（item category determination）配置是完整的。因为手动新增的行项目会重新触发项目类别确定，如果这条路径没配好，即使允许添加，新增行也会因为项目类别问题保存失败。改完这个字段后，建议在测试环境完整跑一遍：创建交货单、手动增行、拣配、过账、开票，确认整条链路没有报错再切生产。

4. 凭证内容里的隐藏开关：途径确定、仓库分解、自动包装为什么总在过账时报错

4.1 途径确定三种模式：空白、A、B 到底差在哪

途径确定解决的问题是：交货单的运输路径从哪里来。这个字段看着不起眼，但它直接影响运输计划、运费结算和装运安排。正文给出了三种模式，区别必须掰清楚。

• 空白：不重新确定路径。交货单的路径直接从订单带出。这里正文特别强调了一句：即使按照重量组定义了出货单路径，只要这里是空白，出货单类型里定义的那套路径也不生效。也就是说，订单上没路径，交货单就没路径；订单上有路径，交货单就继承订单的路径。
• A：按重量组规则重新确定路径。系统会根据货物重量等条件重新算出一条路径，而且算出来之后，用户还可以手动把路径改成任意一条。灵活度高，适合运输路线经常变化的业务。
• B：按重量组规则重新确定路径，但不能随便改。系统按重量组算好路径后，用户只能在「被认可的路径」范围内切换。能改成哪些路径，由路径认可配置表（表名 TROAL）决定，表里的内容是通过已处理路径定义出来的实际路径。

很多项目把途径确定配置成空白，理由是「省心、不干预系统默认」。但风险在于，订单上的路径一旦过时（比如供应商的常用路线变了），交货单还在沿用老路径，运输组按老路径派车，等到发现路线不对再改，已经开始产生额外运费了。A 模式适合路径管理比较松散的企业，B 模式适合运输成本管控严格、只允许在固定路网里走的业务。

4.2 000043：订单路径与交货单路径冲突的根因和改法

报错 000043 是路径相关的高频错误，正文特别说明了一点：出错时系统提示的文本指向的就是订单上面的路径。也就是说，当系统认为交货单的路径和订单上的路径不一致，且当前配置不允许这种差异时，它会用 000043 把订单上的路径抛出来。

最常见的触发场景就是途径确定配成 B：订单上已经维护了一条计划路径，重量组规则算出的交货单路径和订单路径不同，用户在交货单上手工把路径改成了别的值，而这个值不在 TROAL 认可的范围内。保存时系统就报 000043，消息内容会明确告诉你订单上的路径是什么，言下之意是「只认订单这条」。

解决路径有三条，按业务管控要求选：

1. 把途径确定改成空白或 A。空白是让交货单完全跟随订单，A 是允许手动任意改路径，两者都不再有「只能改成特定路径」的限制。适合路线管控要求不高的业务。
2. 维护 TROAL，把需要放行的实际路径加进认可范围。适合希望保留 B 模式管控、但确实有新增路线需求的场景。维护后要让用户重新触发一次路径确定，否则交货单上还是旧路径。
3. 回到订单，把订单上的路径清掉。正文说得很清楚：如果订单上面没有路径，出货单路径可以任意改。所以订单没路径，B 模式的限制就松绑了。这个做法适合那些订单本身不需要规划运输路径的业务。

排查 000043 时，最快的方式是先用事务代码查订单的路径字段，确认订单路径的值到底是什么，再对照交货单类型里的途径确定模式和 TROAL 的认可范围，基本一眼就能定位是哪一层拦住了。

4.3 交货分解-仓库编号：WM 仓码不一致的警告，勾不勾差很远

「交货分解-仓库编号」这个字段控制的是 WM 仓库粒度下交货单的检查行为。正文的描述很具体：勾上之后，开立出货单时，如果输入的仓库使用了 WM 管理，但任意两个行项目输入的 WM 仓码不同，系统会给出警告——行项目中有 WM 仓库与抬头的 WM 仓不符，抬头位置的 WM 仓实际取的是第一个行项目的 WM 仓。如果不勾，这种情况不会出现任何提示。

这个警告的本质，是在交货单层面竖起一道「WM 仓一致性」的检查。勾选后，系统默认抬头的 WM 仓以第一个行项目为准，后续行项目如果出现不同的 WM 仓码，说明这张交货单混了多个仓库的货，系统先警告你确认是不是有意为之。

实际业务里的争议就在这里。有的仓库是单一 WM 仓发货，一张单就是从一个仓码拣货，这种情况勾上是有益的，能把混仓的单子在创建阶段就拦住。但有些业务是「一张交货单从多个 WM 仓拼货发出」，比如电商大卖场，不同行项目分布在电商仓和门店仓，勾上之后每次开单都弹警告，业务人员反而被提醒得麻木，最后直接忽略警告，反而掩盖了真正的问题。

所以在配置这个字段时，要先想清楚仓库作业是单仓还是多仓。单一 WM 仓作业，建议勾上；多仓拼货的场景，不勾或者做好警告的培训，避免警告疲劳。还要注意一点：这个字段影响的是创建时的检查行为，已经创建的混仓交货单不会因为这个配置变化自动拆分，调整前最好确认一下在途单的处理方案。

4.4 自动包装与包装物料项目：POP1、POF1、VHAR 的联动

自动包装是交货单类型里一个「看起来开了就会自动干活」的功能，实际上它有完整的前置链路。正文明确了两层逻辑。

第一层是自动打包：如果物料主数据里建有包规，开出货单时系统会自动打包。包规的维护和激活分别是 POP1 和 POF1 两个功能，POP1 负责建包规，POF1 负责激活。没有激活的包规等于不存在，开单时系统根本不会触发打包动作。

第二层是生成包装物料项目：如果包材的「包装物料类型」属性里的「一般交货项目」有值，且在交货单类型上勾选了「生成包装物料项目」，那么在交货单打包时，系统会自动把包材作为单独的行项目带出来。正文还补了几个前置条件：包材物料属性（MM02）里的选项属性 VHAR 不为空，料号维护了销售组织，行项目类型确定分配正确。这几个条件缺一个，包材都带不到行项目里。

这是一条完整的依赖链，项目里经常出现「打包打了，但包材没出现在交货单行项目里」的情况，排查顺序应该是：

1. 先确认包材物料主数据里 VHAR 属性有没有维护。VHAR 属性是判断这个物料能不能当包材用的标志，没维护就一切免谈。
2. 再确认交货单类型上的「生成包装物料项目」有没有勾上。很多配置是从标准类型复制过来的，功能默认没勾，需要手工打开。
3. 最后看行项目类型确定是否正确。包材行能自动生成，依赖项目类别确定规则把它识别为「包装物料项目」，如果确定出来的是普通销售项目，行项目类型就不对。
4. 不要漏掉包规激活这一步。POP1 建了包规不执行 POF1 激活，自动打包永远不触发，这是最容易被忽略的一环。

4.5 再计划与分配模式：日期和 WMS 接口的隐性约束

再计划字段处理的是交货日期与订单计划行日期的关系。正文说的场景是：如果开出货单的时间正好落在订单最后交期期间，也就是订单计划行日期所在的窗口里，系统会提示拣配日期报错。

这背后的业务逻辑是：订单的计划行日期已经确定了生产和拣配的时间底线，交货单上的拣配日期如果和这个底线冲突，仓库按交货单拣配时会打乱原有的排程。再计划这个开关就是用来决定系统对这种「交期内开单」的行为容忍到什么程度。如果开了，日期不对就报错，逼着用户要么调整交货单的拣配日期，要么回到订单改计划行。

分配模式则偏向接口层面。正文解释它是用来指定分配给分散 WMS 中内向交货或外向交货的时间。简单说，如果企业用了分散式 WMS，交货单往 WMS 传输的时机就由这个字段决定。它决定一张交货单什么时候被标记为「可以分配」、什么时候推送给 WMS 做入库或出库作业。实际项目中，接口日志里出现交货单一直没有分配到 WMS，或者 WMS 侧看不到交货单，除了查接口本身，也要回头看交货单类型的分配模式是不是配成了不适合当前接口场景的值。

这两个字段一个管日期、一个管接口分配，平时不出问题，一出问题就是「系统不按预定时间发货」或者「WMS 收不到单」这类需要跨模块排查的疑难杂症。排查时不要一头扎进接口程序里，先确认交货单类型的这两个字段是不是符合业务预期。

5. 交货单类型配置避坑：分销顾问最容易翻车的 5 个常见问题

5.1 显示范围设成 UMAR，开单时行项目区域一片空白

现象：用 VL01N 创建交货单，抬头数据都输完了，进入行项目区域发现整个列表是空的，业务员第一反应是订单数据没传过来，重试了好几遍还是一样。

原因：交货单类型上的「显示范围」字段控制了行项目的展示规则。UALL 是显示所有行项目，UHAU 只显示主要的行项目，UMAR 只显示选择的行。如果配置成了 UMAR，开单时没有预先选择任何行项目，系统自然什么都不显示。

解决：把显示范围改成 UALL。如果业务上确实需要分层显示，可以在开单界面先选中需要处理的订单行，再确认是否要用 UHAU 这类过滤视图。这个字段不会影响数据本身，只影响界面展示，所以先改配置再看界面，不用动订单数据。

5.2 屏幕顺序组没配好，字段在出货单概览里消失

现象：有些字段以前在交货单概览里能输入，比如批次号、拣配数量，某个时间点之后突然找不到了，用户在界面里翻遍了页签也找不到入口。

原因：屏幕顺序组决定了出货单概览的字段布局，交互方式类似于销售订单的屏幕顺序组。新建交货单类型时如果复制的标准类型不带完整的屏幕顺序组，或者后期调整屏幕顺序组时把某些字段的状态改成了隐藏、只读，这些字段就会从界面上「消失」。

解决：复制一个标准类型的屏幕顺序组，或者对照标准配置检查当前屏幕顺序组里字段的状态。注意屏幕顺序组是按字段状态控制的，某个字段是显示、隐藏还是只读，都在字段状态配置里定义。排查时先确认字段在配置里是启用的，再检查是不是被屏幕顺序拦住了。

5.3 应用程序漏配，输出过程定不到输出类型

现象：交货单过账成功了，但该触发的打印、EDI 传输没有执行。到后台看输出确定，找不到任何输出类型，或者输出类型列表是空的。

原因：交货单类型上的「应用程序」字段决定了输出条件使用哪个应用，出货单对应的值固定是 V2。订单、出货单、发票分别对应不同的输出条件应用。如果配置时把应用程序填错或者没有正确关联输出确定过程，系统在执行输出确定时找不到对应的输出类型。

解决：确认应用程序字段的值是 V2，并且交货单类型上挂载了正确的输出确定过程。如果输出过程有多个，还要检查过程里的条件记录是否覆盖了当前销售组织、装运点和客户这几层。输出这块经常出现「配置看起来都对但就是不触发」的情况，建议在测试环境用输出分析功能跟踪一次输出确定，看系统在哪一步找不到条件。

5.4 合伙人确定过程不一致，送达方为空且改不掉

现象：交货单创建后，售达方、送达方等合作伙伴为空，或者创建时手工填了送达方，保存后又被系统清掉。

原因：交货单类型的「合伙人确定过程」决定了交货单上的合作伙伴从哪来。如果这个过程里没有包含售达方、送达方这类合作伙伴角色，或者过程和订单上使用的合伙人确定过程不一致，系统就不会自动带出，而且保存时可能因为校验不通过把手工维护的值也清掉。

解决：检查合伙人确定过程中的合作伙伴角色清单，确认包含销售业务需要的售达方、送达方、收货方等角色。然后对比订单和交货单的合伙人确定过程，正常情况下交货单会从订单复制合作伙伴，两张单据的过程定义不一致就会出现带不出来的问题。这块改完可以开一张新交货单测试，旧单需要手动补合伙人数据。

5.5 要求订单规则冲突，参考销售订单建单却被拒

现象：业务员用 VL01N 参考销售订单创建交货单，系统提示参考单据不允许创建；但换成采购订单来参考就能建，用户百思不得其解。

原因：交货单类型上的「要求订单」字段把允许参考的单据类别限制成了采购订单，而用户实际参考的是销售订单。还有一种可能：开单界面里已经预先输入了预定义交付类型，系统拿预定义类型上的规则和实际参考单据做比对，发现不一致就报错。

解决：先回到后台确认这类交货单到底应该参考什么类型的订单，把「要求订单」的规则改成符合业务实际的值。同时检查 VL01N 抬头是否输入了预定义交付类型字段，如果业务上不需要强制指定，就清空这个字段再建单。这里最容易反复踩坑，因为「偶尔能建、偶尔不能建」的表现太像权限问题了，实际上和权限毫无关系。

6. 快速定位：一张出货单开不出来，我按这个顺序查配置

遇到交货单建不出来、过账报错、或者界面显示异常时，我一般会按下面的顺序排查，这个顺序能覆盖绝大多数根因。

第一步：记消息号，别看弹窗文案猜原因。弹窗里的中文文本往往只是表面描述，真正有用的是消息号。用事务代码 SE91 查消息文本，能看到这条消息校验的是哪个字段、哪个程序里抛出来的。很多交货单报错消息号背后对应的就是后台表的字段校验。

第二步：确认开单界面有没有输入预定义交付类型。这个字段是「要求订单」规则的触发开关，也是最容易被忽略的变量。用户在界面上多填了一个类型字段，行为就可能从「允许建单」变成「拒绝建单」。先别动后台，让用户把预定义交付类型字段清掉再试一次，能建就说明是输入方式和规则冲突。

第三步：按报错阶段回查交货单类型字段。建单失败，优先级是凭证类别 → 编号范围 → 订单参考 → 项目需求；过账失败，优先级是途径确定 → 仓库分解 → 移动类型搭配；界面显示异常，优先级是显示范围 → 屏幕顺序组。

第四步：用事务代码直接进后台配置核对。我常用的定位入口是这样的：

# SAP 交货单类型配置与排错常用事务代码 VL01N # 创建交货单：复现报错，检查预定义交付类型字段 VL03N # 显示交货单：确认路径、仓库、合作伙伴的实际值 SE91 # 消息号查询：看懂报错校验的字段 SNRO # 编号范围维护：检查交货单编号区间是否耗尽 MM02 # 物料主数据：查看包材 VHAR 属性是否维护 POP1 # 包装指令建立：确认包规是否存在 POF1 # 包装指令激活：确认包规是否真正生效

这些事务代码的顺序是有讲究的：先用 VL01N 复现问题，拿真实报错；再用 SE91 查消息号；然后回到 VL03N 看单据数据；最后才去 SNRO、MM02 这类配置和主数据维护界面。不要一上来就打开后台一顿改，那样很容易改错目标。

第五步：看对照表，快速锁定优先查的字段。

从那以后，我每次上线前都会把交货单类型里最容易被业务忽略的三个字段强制走一遍确认：显示范围是不是 UALL、途径确定是不是符合运输管控要求、订单参考规则和开单界面的预定义交付类型会不会打架。这三项只要有一项没对上，后续一定会有人来敲门问为什么建不了单。这套检查流程救过我很多次，希望帮到你。

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