简介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 内部分配打勾表示使用内部编号规则系统从编号范围自动取号编号范围耗尽后所有建单都会失败报编号范围溢出外部范围号使用外部编号规则建单时手工输入编号且号码必须落在外部范围内外部号重复或不在范围内保存时直接被拒项目号增量行项目编号的递增规则决定第一行、第二行的项目号间隔增量设置太小后续插入行项目时没有空间NR 内部分配是最常用的做法。系统维护好之后VL01N 建单会自动取号业务人员不需要关心单据编号。这里的关键操作在编号范围维护需要给交货单类型分配一个合法的编号范围区间并且分配给对应的公司代码或工厂。如果编号范围区间用完前台表现就是「建单到一半系统报错提示编号范围溢出」后台日志里能看到具体的编号范围对象。外部范围号适合接口传入单据的场景。有些公司做电商中台交货单号希望用中台生成的订单号这时就把外部范围号打开。但这个配置的坑在于外部编号不是「随便填」编号必须落在外部范围定义好的区间里而且不能和已有单据重复。如果外部范围没配好系统会提示号码不在范围业务人员完全看不懂这个报错。项目号增量这块正文里说的是「子项目增加规则」。最直白的理解是行项目编号的步长。假如增量是 10那么第一个行项目编号是 10第二个是 20中间留出的空间可以给后来插入的行项目。如果增量是 1项目编号就是 1、2、3插入一行就要把后面的编号全部推移。在频繁需要后补行项目的业务里项目号增量建议留出余量。2.3 新建交货单的典型报错对照交货单类型相关的配置错误大多在建单或过账时暴露。下面这张表是项目里整理过的报错对照排查时可以先按这张表定位报错现象根因解决方向建单时报编号范围溢出内部/外部编号范围耗尽或编号范围未分配给对应公司代码在编号范围维护里扩充区间检查分配关系提示交货单类型未定义或无效类型不存在或凭证类别字段值异常复制一个标准类型重新配置不要手工硬建参考单据不允许创建交货单「要求订单」规则与实际参考凭证类型冲突查交货单类型的订单参考设置见第 3 章过账时移动类型与凭证类别不匹配凭证类别与货物移动类型搭配错误回查凭证类别确认 J/7/T/g 选的是哪一项000043 路径报错订单路径与交货单路径不一致B 模式下尤为常见调途径确定字段或维护路径认可表见第 4 章这里想强调一个操作习惯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消息内容会明确告诉你订单上的路径是什么言下之意是「只认订单这条」。解决路径有三条按业务管控要求选把途径确定改成空白或 A。空白是让交货单完全跟随订单A 是允许手动任意改路径两者都不再有「只能改成特定路径」的限制。适合路线管控要求不高的业务。维护 TROAL把需要放行的实际路径加进认可范围。适合希望保留 B 模式管控、但确实有新增路线需求的场景。维护后要让用户重新触发一次路径确定否则交货单上还是旧路径。回到订单把订单上的路径清掉。正文说得很清楚如果订单上面没有路径出货单路径可以任意改。所以订单没路径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 不为空料号维护了销售组织行项目类型确定分配正确。这几个条件缺一个包材都带不到行项目里。这是一条完整的依赖链项目里经常出现「打包打了但包材没出现在交货单行项目里」的情况排查顺序应该是先确认包材物料主数据里 VHAR 属性有没有维护。VHAR 属性是判断这个物料能不能当包材用的标志没维护就一切免谈。再确认交货单类型上的「生成包装物料项目」有没有勾上。很多配置是从标准类型复制过来的功能默认没勾需要手工打开。最后看行项目类型确定是否正确。包材行能自动生成依赖项目类别确定规则把它识别为「包装物料项目」如果确定出来的是普通销售项目行项目类型就不对。不要漏掉包规激活这一步。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 这类配置和主数据维护界面。不要一上来就打开后台一顿改那样很容易改错目标。第五步看对照表快速锁定优先查的字段。症状优先检查的交货单类型字段建单报参考单据不允许订单参考下的「要求订单」、开单界面的预定义交付类型建单报编号溢出NR 内部分配、外部范围号、编号范围分配行项目区域空白显示范围 UALL/UHAU/UMAR某些字段在界面消失屏幕顺序组过账报路径错误 000043途径确定空白/A/B、TROAL 认可范围过账报移动类型错误凭证类别 J/7/T/g 与移动类型搭配打印/EDI 不触发应用程序字段 V2、输出确定过程WMS 收不到交货单分配模式、仓库编号分解从那以后我每次上线前都会把交货单类型里最容易被业务忽略的三个字段强制走一遍确认显示范围是不是 UALL、途径确定是不是符合运输管控要求、订单参考规则和开单界面的预定义交付类型会不会打架。这三项只要有一项没对上后续一定会有人来敲门问为什么建不了单。这套检查流程救过我很多次希望帮到你。本文还有配套的精品资源点击获取