企业官网建设流程全解析

SAP SD模块的配置一直是个“看着简单、做起来全是细节”的活。不少刚转行做SD顾问的朋友，拿到项目的第一件事就是打开SPRO，照着路径一个一个点进去，定义公司代码、定义销售组织、定义分销渠道，感觉流程都跑通了。但等到业务顾问开始录客户主数据、录物料主数据，或者在VA01里创建销售订单的时候，各种“没有允许的销售范围”“定价过程未找到”“交货类型不可用”就全冒出来了。问题出在哪？多半是在配置三大核心板块的时候，只做了“点选动作”，没把组织架构、主数据和销售凭证这三条主线之间的耦合关系理清楚。

这篇内容我围绕组织架构、主数据、销售凭证与流程控制三大板块展开，把每条SPRO标准路径背后的配置逻辑、操作顺序和常见坑说明白，适合正在做SD模块实施的顾问、刚入行的功能顾问，以及企业内部的IT支持人员参考。我不会堆一堆“点击下一步”式的废话，而是把配置的“为什么”讲清楚，你照着做完之后，至少能保证标准销售流程从VA01到VL01N再到VF01是通的。

1. 组织架构配置：先搭骨架，再谈业务

1.1 销售范围三要素的配置逻辑

SAP SD的组织架构本质上是回答三个问题：谁在卖？通过什么渠道卖？卖给什么产品线？对应到系统里就是销售组织、分销渠道、产品组这三个对象。

销售组织的路径在 SPRO → 企业结构 → 定义 → 销售和分销 → 定义/分配销售组织 → 定义销售组织。实操上不建议轻易用“复制功能”去快速创建销售组织，因为复制只能把组织单元的参数带过去，但公司代码、工厂、分配关系这类跨模块的关联还得手动维护。销售组织在系统里代表企业中负责销售合同谈判的顶级组织单元，你可以把它理解成“销售公司”。一个集团公司下如果有多个销售公司，每个销售公司就是一个销售组织。

分销渠道的路径是 SPRO → 企业结构 → 定义 → 销售和分销 → 定义/分配分销渠道 → 定义分销渠道。批发、零售、直销、电话销售、电商，每种渠道都可以维护独立的定价、交货流程和客户主数据。实际项目里最常见的坑是“渠道定义太多，主数据维护量爆炸”。我见过一个快消企业定义了六七个分销渠道，结果每个客户在每个渠道下都要维护一套销售视图数据，业务部门录入量翻了几倍，后来才在运维阶段做渠道合并。所以定义分销渠道的时候，先想清楚现有业务到底需要几条渠道，别替业务部门做“多余的设计”。

产品组（也称产品线）的配置路径与前面类似，在 定义/分配产品组 → 定义产品组。产品组用于统计和利润分析，某些行业也把它当事业部用。注意产品组与MM模块中的物料组是两个概念：产品组是SD组织架构元素，物料组是物料主数据分类属性。二者经常被人搞混，后面做条件记录的时候也容易选错维度。

1.2 分配关系的顺序不能错

组织架构定义了对象之后，必须做分配，否则系统里根本不存在“可用的销售范围”。分配关系分三层：

第一层：分配销售组织到公司代码，路径 SPRO → 企业结构 → 分配 → 销售和分销 → 分配销售组织到公司代码。这里要把销售组织与财务上的公司代码挂上钩。挂错的话，后续销售订单过账时收入科目会抛到错误的公司代码，AR凭证也找不到对应的统驭科目。

第二层：分配分销渠道到销售组织，路径 SPRO → 企业结构 → 分配 → 销售和分销 → 分配分销渠道到销售组织。这一步决定某个销售组织下可用哪些分销渠道。

第三层：分配产品组到销售组织，路径 SPRO → 企业结构 → 分配 → 销售和分销 → 分配产品组到销售组织。

这里有个关键经验：分配关系全部配好后，最终形成的“销售范围 = 销售组织 + 分销渠道 + 产品组”会作为主数据维护和定价过程确定的维度。你可以在事务码V.03里查看已经存在的销售范围。如果项目里有多个销售组织，务必在分配表里按实际业务把每个组合都配好，漏掉任何一个组合，对应销售范围的客户主数据就维护不了。

1.3 销售办公室、销售组与销售代表的补充说明

销售办公室、销售组和销售代表是SD组织架构中偏“报表统计”的一层，很多项目为了简化直接不启用。但如果业务部门要求按区域、按业务员统计业绩，就需要配这一层。路径在 SPRO → 销售和分销 → 主数据 → 销售支持 → 销售办公室/销售组/销售代表。

我个人的建议是：这一层配置不要放到项目初期做死，可以在上线后根据销售管理部门的报表需求再补充。原因是销售办公室和销售组往往跟着组织架构调整频繁变动，初期配死反而增加变更工作量。系统里它们是“可选主数据”，即使不启用也不影响销售订单的基本流程。

1.4 工厂、装运点与跨模块依赖

SD离不开工厂，因为销售订单必须指定“从哪个工厂发货”，而工厂本身由MM或者后勤模块维护，SD顾问要做的只是确认工厂与公司代码的分配关系已经配置，并且后续在销售凭证里能通过“装运点确定规则”找到实际发货地点。

装运点定义路径在 SPRO → 企业结构 → 定义 → 后勤-常规 → 定义、复制、删除、检查装运点。装运点代表真实发货的地点，比如中心仓库、港口、第三方物流合作仓。定义装运点之后，还要把工厂分配给它，路径 SPRO → 企业结构 → 分配 → 后勤-常规 → 分配装运点到工厂。装运点确定规则在 SPRO → 后勤执行 → 装运 → 基本装运功能 → 装运点确定 → 定义装运点确定规则。规则里可以根据“发货工厂 + 装载组 + 运输组 + 国家”等条件确定默认装运点。

补充一个重要经验：组织架构配置在后端启动前必须冻结。SAP项目里的组织架构一旦开始录入主数据，改动成本极高。一个项目里因为销售范围调整，导致客户主数据销售视图全部失效的例子并不少见。所以在配置组织架构之前，先和业务方、财务顾问、物流顾问坐下来对一张组织架构图，确认销售公司、工厂、发货仓库的对应关系，再动手配SPRO，能省掉后面一大半返工。

2. 客户主数据与物料主数据：配置往下走之前先想清楚数据长什么样

2.1 客户账户组：分类定所有

客户主数据是SD主数据里的重头。配置的第一步不是创建客户，而是定义“客户账户组”。路径 SPRO → 销售和分销 → 主数据 → 业务合作伙伴 → 客户 → 准备客户主数据 → 定义客户科目组。

账户组的作用是给客户分类：标准销售客户、一次性客户、内部关联客户、运费结算对象等等。不同账户组的客户可以有不同的编号范围、不同的屏幕字段控制、不同的伙伴功能。所以账户组定义得好不好，直接决定后续客户主数据维护的效率和销售流程的规范性。

实操中常见的分组方式是：

• 标准销售客户（开户客户）
• 一次性客户（现金销售、零星业务）
• 关联方客户（公司间销售，母公司/子公司）
• 外部代销客户

一次性客户这个账户组值得单独讲。很多企业会忘记配一次性客户，导致现金销售、小型零散单没法处理。一次性客户的物料信息、公司信息都放在主记录里，客户号往往是一个汇总编号，销售订单中实际客户信息在单据头层级维护。配好一次性客户账户组之后，还要注意给它单独分配一个编号段，方便报表筛选。

2.2 屏幕格式与字段状态组

客户主数据并不是一张简单的表，而是分成通用数据、公司代码数据、销售范围数据三层。SD配置重点在销售范围内客户的“销售视图”“配送视图”“开票视图”。路径 SPRO → 销售和分销 → 主数据 → 业务合作伙伴 → 客户 → 准备客户主数据 → 为账户组定义屏幕格式。

屏幕格式里可以控制每个字段在客户维护时的状态：必输、隐藏、可选。这个逻辑其实很好理解，就像填表时有些字段是星号必填，有些字段直接被隐藏不看。例如某企业对国内客户，销售视图里的“国际贸易条件”字段根本不关心，就可以隐藏；对出口客户，这些字段必须显示且必输。屏幕格式配置完成之后，需要按账户组分配屏幕格式，路径 SPRO → 销售和分销 → 主数据 → 业务合作伙伴 → 客户 → 准备客户主数据 → 分配屏幕格式到客户账户组。这里最容易出的问题是：忘记了“销售/配送/开票”三个视图的屏幕格式都要给账户组分配，最后只配了销售视图，进XD01/VD01时配送、开票视图字段全部空白，业务无法维护。

2.3 客户编号范围分配

客户主数据编号范围在 SPRO → 销售和分销 → 主数据 → 业务合作伙伴 → 客户 → 准备客户主数据 → 创建和分配客户编号范围。这里有两个动作：先创建编号范围（比如外部给号01~99999），再把编号范围分配给账户组。

判断用内部给号还是外部给号，取决于企业现有客户号是否要沿用历史编号。如果企业内部已有成熟的客户编码体系，建议外部给号；如果完全新建，用内部给号更省心。混合模式也可以——标准客户用外部号段，一次性客户用内部号段，通过账户组分离。

新项目里最容易忽略的是“编号范围分配”这一步。账户组配了，屏幕格式也配了，但编号范围没分配，创建客户时系统直接报“没有为客户科目组定义编号范围”，这是一个非常典型的初学错误。

2.4 物料主数据销售视图与字段参考

物料主数据在SD这边涉及的配置，核心是“销售视图”和“字段参考”。路径 SPRO → 销售和分销 → 主数据 → 物料主数据 → 定义物料主数据的销售视图和 SPRO → 销售和分销 → 主数据 → 物料主数据 → 定义物料主数据的字段参考。

物料主数据销售视图里有几个字段对SD流程影响非常大：

• 项目类别组：这个字段直接决定销售订单行项目的默认类别。
• 产品组：对应组织架构里的产品组。
• 装载组和运输组：影响装运点和交货流程。
• 物料组：用于物料主数据分类和条件记录维度，注意与组织架构的产品组区分。

字段参考D1是标准销售视图分配的最常用字段状态组，控制销售、配送、开票三个视图里各字段的必输/隐藏/可选。如果企业希望某些物料必须维护毛重、净重、海关代码，可以在字段参考里把这些字段设成必输。配置物料主数据字段参考时，建议和内部物料管理负责人确认一下录入规范，避免上线后物料团队录入大量无效数据。

2.5 客户-物料信息记录的补充说明

客户-物料信息记录（客户物料信息）虽然不是“基础配置”里必须配的对象，但对很多B2B业务来说是刚需。因为同一个客户往往使用自己的内部物料编码，订货时用客户物料号发订单，企业要通过客户物料信息记录把“客户物料号 → 我方物料号”对应起来。路径 SPRO → 销售和分销 → 主数据 → 客户物料信息 → 定义客户物料信息记录。配置相对简单，重点是培训业务人员养成维护客户物料信息的习惯，否则销售订单里客户物料号带不出来，容易导致发货出错。

主数据这块我的体会是：配置节奏要和数据迁移计划对齐。很多项目把客户主数据、物料主数据的字段状态配得很细，但到了数据迁移阶段，几百上千条主数据根本录不完，最后又放松字段必输性。与其这样反复拉扯，不如一开始就区分“上线期主数据”和“正常运行期主数据”的字段状态策略，把压力放在关键字段上。

3. 销售凭证与项目类别：单据流转的第一道闸门

3.1 销售凭证类型：标准订单OR的配置要点

销售凭证类型定义了销售订单的“模板”。路径 SPRO → 销售和分销 → 销售 → 销售凭证 → 销售凭证头 → 定义销售凭证类型。

标准订单OR、退货单、免费订单、借贷项申请单等，每一种凭证类型的核心控制参数包括：

• 编号范围：销售凭证的编号段。
• 项目类别用法：决定创建销售订单时，行项目类别的基础确定维度。
• 销售凭证类型文本：是否允许维护抬头文本、项目文本。
• 信用检查组：是否启用信用控制。
• 屏幕控制：创建、修改时的界面字段状态。

一个常见误区是觉得凭证类型可以随便复制修改。其实凭证类型里有一堆后台开关，比如“交货”“开票”“定价”几个复选框，控制了该凭证类型能否触发后续流程。如果你在复制标准订单OR创建自定义订单类型时，不小心把“开票”勾去掉，那么这张单据永远无法进入VF01开票流程，业务跑完才发现已经晚了。

3.2 项目类别与项目类别组：SAP销售行项目的灵魂

行项目类别（Item Category）是销售凭证行项目的“行为模板”。路径 SPRO → 销售和分销 → 销售 → 销售凭证 → 销售凭证项目 → 定义项目类别。

每个项目类别都控制着大量开关：

• 是否有计划行（是否有“交货计划”这个概念）
• 是否需要进行交货
• 是否开票
• 是否允许退货
• 定价是否生效
• 库存移动类型（发货过账时的移动类型）
• 是否允许折扣、返利

项目类别之间差别巨大。标准项目TAN有交货、有开票、有定价；免费项目TANN有交货、有开票但不计入收入；退货项目REN有反向库存移动。把项目类别理解成“行级别的小单据模板”，可能更直观一些。

项目类别确定则按照“项目类别组 + 项目类别用法”来自动带出行项目类别。项目类别组维护在物料主数据里，项目类别用法维护在销售凭证类型里。系统里有一张“项目类别确定表”，通过二者的组合确定最终的项目类别。路径 SPRO → 销售和分销 → 销售 → 销售凭证 → 销售凭证项目 → 定义项目类别确定。

3.3 项目类别确定的实操理解

举一个真实场景：某企业销售标准物料，VA01创建标准订单OR，行的项目类别应该是TAN。系统内部是怎么判断的？前提是物料主数据销售视图里“项目类别组”字段是NORM（标准物料），销售凭证类型OR里“项目类别用法”是A（标准用法）。项目类别确定表里，“NORM + A → TAN”。所以任何一个环节变了，结果都会变。

例如物料主数据里项目类别组没有维护，或者被维护成了“未知”，销售订单创建时系统找不到可匹配的项目类别，行项目内容可能空白，根本无法保存。这类问题不像报错那么明显，往往要到交货环节才发现行项目无法复制。

所以项目类别配置的关键路径是：

1. 确认物料主数据里项目类别组的取值范围；
2. 确认凭证类型的项目类别用法；
3. 在“项目类别确定”里检查每个组合最终指向的项目类别是否合理；
4. 为需要交货的项目类别选择正确的计划行类别。

3.4 计划行类别与销售凭证编号范围

有了交货需求的销售订单，行项目下还有一个“计划行”。计划行代表按日期交货的承诺，例如某订单要求5月10日交300件、5月20日交200件，计划行会生成两行。计划行类别控制计划行的行为：是否允许修改交货日期、是否触发自动可用性检查、交货类型等。路径 SPRO → 销售和分销 → 销售 → 销售凭证 → 计划行 → 定义计划行类别。

标准项目TAN默认用计划行类别CP，免费项目TANN用CN。计划行类别里有一个“可用性检查”开关，决定了创建销售订单时是否自动做ATP检查（可用量检查）。很多项目上线后抱怨“交期没有参考库存”，很可能就是计划行类别里可用性检查规则设错了，或者压根没勾。

销售凭证的编号范围配置在 SPRO → 销售和分销 → 销售 → 销售凭证 → 销售凭证头 → 定义销售凭证的编号范围。这一步是纯编号维护，建议给每个凭证类型单独分配一个编号段，方便从单据号大致判断单据类型。曾经有项目把所有销售凭证类型共用一个编号段，结果财务查单时完全无法从单据号看出是退货还是正常订单，每天都要靠报表筛。

销售凭证类型的配置总结下来就是：类型负责头，项目类别负责行，计划行负责交期计划。这三层配置在初期容易被混淆，但把层次关系理清楚之后，后续流程控制就在掌控之中。

4. 复制控制、交货与开票：把单据之间的“管路”接好

4.1 复制控制的定位：从上一步复制到下一步

销售订单不是一张孤立单据。从销售订单传到交货单，再从交货单传到开票凭证，数据沿用的规则就是“复制控制”。路径 SPRO → 销售和分销 → 销售 → 销售凭证 → 销售凭证流 → 定义复制控制。

复制控制有多个方向：

• 从销售凭证到交货单
• 从销售凭证到开票凭证（可绕过交货，比如服务类物料直接开票）
• 从交货单到开票凭证
• 从销售凭证到销售凭证（用于“参考创建”或后续的退货冲销流程）

复制控制里还包含“副本控制”和“数据传递表”。副本控制决定以什么复制规则取数；数据传递表决定具体字段的传递逻辑。大部分项目的复制控制以沿用标准配置为主，真正需要改的是少数特殊流程，例如“退货订单参照原交货单创建”时，需要定义从交货单到退货销售订单的复制规则。

4.2 交货类型与分配交货类型到销售凭证

定义交货类型路径 SPRO → 后勤执行 → 装运 → 交货 → 定义交货类型。标准交货类型是LF，核心控制参数包括：

• 编号范围
• 交货项目类别确定规则
• 库存处理：是否做可用性检查、是否允许部分交货
• 发货过账的移动类型
• 装运点确定逻辑

然后必须把交货类型分配给销售凭证类型。路径 SPRO → 后勤执行 → 装运 → 交货 → 分配交货类型到销售凭证类型。这里要注意，这张分配表是按“销售凭证类型 + 交货物料类别”来指定交货类型的。如果某个物料类别是“特殊库存”或“服务物料”，可能要走不同的交货类型或直接不走交货。

项目里常见的问题在于：销售凭证类型已经创建好了，但忘记把交货类型分配过去。结果VA01创建销售订单一切正常，等到VL01N创建交货单时，系统提示“没有找到交货类型”或“该销售凭证无交货流程”。查配置时优先看这张分配表。

4.3 开票类型与分配逻辑

定义开票类型路径 SPRO → 销售和分销 → 开票 → 开票凭证 → 定义开票凭证类型。标准开票类型是F2（标准发票）。开票类型控制编号范围、开票的基准对象、科目确定规则、税务处理逻辑等。

开票类型需要与销售凭证类型和交货类型分别挂钩，路径在 SPRO → 销售和分销 → 开票 → 开票凭证 → 分配开票类型到销售凭证类型 和 分配开票类型到交货类型。

这两张分配表配好了，后面VF01开票才能正确带出F2。同理，贷项凭证、借项凭证也要对应到相应的开票类型上。如果只配了销售凭证类型到开票类型的分配，忘记配交货单到开票类型的分配，销售订单走完交货之后再开票时系统无法识别开票类型，业务卡在最后一步。

4.4 装运点确定与流程衔接

装运点确定这项配置虽然不起眼，但它在“销售订单 → 交货单”的流程衔接上扮演关键角色。路径 SPRO → 后勤执行 → 装运 → 基本装运功能 → 装运点确定 → 定义装运点确定规则。

系统在创建交货单时，根据销售订单上的“装运条件 + 发货工厂 + 装载组 + 运输组 + 收货国家”等信息，自动找出发货装运点。如果找不到，后面创建交货单时会报“装运点未确定”或带出空白装运点。

配置建议：把装运点确定规则表设得宽一些，不要一上来就写上百个组合条件。先按工厂 + 渠道确定主要装运点，上线后根据实际业务补充分支条件，比一开始就预判所有条件组合更落地。

流程控制部分还有一项值得一提：销售凭证流的可跟踪性。配好复制控制后，销售订单、交货单、开票凭证之间会自动形成“凭证流”，在VA03/VL03N/VF03里都能追溯到上游和下游单据。如果发现凭证流断开，排查思路优先盯复制控制，而不是去查数据。复制控制的实际内容虽然冗长，但多数项目只需要理解标准配置并做少量增强，真正从零配置的场景很少。所以不必过度恐惧，先跑通标准链路，再考虑定制。

5. 定价与条件技术：价格从哪来、怎么算

5.1 定价三要素：条件类型、访问顺序、条件记录

如果销售订单里的价格带不出来，或者价格算得不对，问题基本都出在定价配置的三要素上。

第一个要素是条件类型。条件类型代表一种“定价成分”，比如PR00是销售价格，K007是客户折扣，MWST是销售税，KOFI是运费附加。路径 SPRO → 销售和分销 → 基本功能 → 定价 → 定价控制 → 定义条件类型。

条件类型里定义了计算规则、正负号（是加价还是减价）、是否允许手工维护、是否采用“金额/百分比”格式、是否可以作为后续折扣或返利的基准值。新增条件类型时最稳妥的方式是从一个已有的近似条件类型复制，并检查复制出来的计算规则是否符合需求。

第二个要素是访问顺序。系统拿到一张销售订单，发现定价过程里有PR00，就需要查找PR00对应的条件记录。访问顺序就是告诉系统“按什么先后顺序去查”。比如销售价格PR00的访问顺序通常是先查“物料/客户”专属价格，再查“物料”标准价格，最后查“客户组/物料组”等兜底价格。路径 SPRO → 销售和分销 → 基本功能 → 定价 → 定价控制 → 定义访问顺序。

访问顺序里还包含条件的“字段来源”。如果访问顺序的表配错了，比如明明是查“客户/物料”价格，却配成了“客户层次+物料”的组合，条件记录根本找不到。这是定价问题里最常见的隐性错误。

第三个要素是条件记录。条件记录是实际的价格数据，比如客户A采购物料B的价格是每件100元。条件记录不是配置，它是主数据。但条件记录是否能被找到，很大程度上取决于访问顺序和条件类型。业务端在VA01里输入物料和数量后，价格自动带入，靠的正是“定价过程 → 条件类型 → 访问顺序 → 条件记录”这条链路。

5.2 定价过程：把各种条件串起来计算

定价过程是“计算顺序表”，定义了价格计算时各条件类型的排列顺序和计算逻辑。路径 SPRO → 销售和分销 → 基本功能 → 定价 → 定价控制 → 定义并分配定价过程。

标准销售订单使用的定价过程是RVAA01。在定价过程维护界面里，每一行都是一个定价“步骤”，包含：

• 步骤编号：控制计算顺序
• 条件类型
• 正负号：加价还是折扣
• 计算类型：按金额还是按百分比
• 基准公式：基于哪个条件类型的值来计算（例如折扣基于毛价PR00）
• 要求/可选例程：控制该步骤在什么条件下才参与计算

举例：某个销售订单的定价过程是“价格PR00 → 折扣KA00（基于PR00）→ 税MWST（基于税前金额）→ 运费KOFI”。最终净价的计算就是PR00减去KA00的折扣，再加上运费，最后算税。

定价过程为什么这么重要？因为它不仅控制价格计算，还控制“销售/成本科目确定”中收入科目的取值基础、以及“条件排除”等多重逻辑。很多项目因为改了定价过程里的“计算类型”，导致账面收入金额和客户对账单金额对不上，这类问题返工极慢。

5.3 定价过程确定：系统怎么选定价过程

系统判断该用哪个定价过程，依据是销售组织、分销渠道、客户定价过程组、物料定价过程组四个维度。路径 SPRO → 销售和分销 → 基本功能 → 定价 → 定价控制 → 定义并分配定价过程 → 定价过程确定。

客户主数据里有一个“客户定价过程组”字段，物料主数据里也有一个“物料定价过程组”字段。系统在创建销售订单时，取到这些值，在定价过程确定表里找到对应的定价过程。

常见的问题场景：销售订单打完，价格为空。这时候第一反应不应该是去建条件类型，而是应该用系统自带的“定价分析”工具，在VA01菜单里进入定价环境，点“分析”，系统会逐条显示每个定价步骤为什么取值或为什么不取值。定价过程确定没配好、客户定价过程组为空、物料定价过程组与定价过程确定表不匹配，这些问题在定价分析里一目了然。

5.4 定价配置的实操建议

新增条件类型和访问顺序的“增强”是SD顾问进阶的内容，但基础项目里做的最多的其实是以下三件事：

第一，补充条件记录。例如某新客户没有单独维护价格，销售订单里只想用“物料标准价格”，那就要确认标准价格条件PR00在对应访问顺序里能查到普通物料价格记录。

第二，调整条件类型的可见性。标准条件类型在销售订单里是否允许手工修改，这由条件类型里的“人工录入”标识控制。如果销售员需要手工改价，就要允许人工录入；如果财务要求所有价格必须走审批，就禁止手工录入。

第三，维护定价过程的税计算。价外税与价内税的区别，本质在定价过程的“计算类型”选择。像增值税，在定价过程里通常是百分比计算方式，且基准值是所有净价之和。

定价是SD里最需要“理解业务再动手”的领域，因为价格计算规则直接牵扯财务结算。配置前一定要求财务顾问给出完整的价税规则和折扣规则，而不是自己猜。测试的时候多准备几组客户、物料组合，用定价分析工具逐条核对。

6. 配置完之后的验证与常见问题排查

6.1 全流程验证的五个动作

配置完成后，不能只看配置表，要把端到端流程完整走一遍，我建议按下面五个动作来验证：

1. XD01/VD01创建客户，查看销售、配送、开票视图的字段状态是否合理，编号是否正确带出。
2. MM01/MM02维护物料销售视图，重点检查项目类别组、装载组、运输组、定价过程组是否维护完整。
3. VA01创建一张标准销售订单，检查行项目类别是否为TAN、计划行类别是否为CP、价格是否自动带出。
4. VL01N根据销售订单创建交货单，检查装运点是否自动带出、能否过账 VL02N 发货。
5. VF01开票，检查开票类型F2是否自动带出、财务科目是否正确。

如果五个动作都顺了，说明组织架构、主数据、销售凭证、复制控制、定价这条主链路是通的。

6.2 高频报错与排查思路

排查问题有个核心方法论：先看单据流走到哪一步断了，再逆着链路往回查配置。以下是我在项目里遇到过的高频问题：

6.3 两条保命习惯：传输请求与配置文档

最后分享两个我踩过几次坑之后的习惯。

第一，所有配置修改都必须挂在传输请求上。SPRO里的每个配置动作，系统都会提示分配一个请求号。千万不要把所有配置都挂在同一个请求号里，最好按模块拆：组织架构一个请求、主数据一个请求、销售凭证一个请求、定价一个请求。这样后续传输到测试环境或生产环境，即使某个请求冲掉了，也能定位到影响范围。

第二，维护一张“SD配置清单”。每个配置项记录五样东西：路径、表名/视图名、配置了什么内容、属于哪个传输请求、是谁在什么时候改的。这张清单在项目蓝图阶段就要逐步建立，上线后运维排查问题时就是救命稻草。很多项目上线三个月后，新增顾问接手时根本没有配置文档，到处翻SPRO的“更改记录”去追溯来源，效率极低。

在测试环境里多跑几轮端到端单据，记录每张单据的关键字段快照，后续出问题也能快速比对是哪一步的数据变了。SD配置的完整度不在“点多深”，而在能不能支撑业务从下单到开票的整条链路不走样。把链路上的每个交汇点都验证清楚，才算真正把基础功能配置落地。