SAP SD销售链路拆解：文档流、销售区域与定价条件技术

简介：这份SAP SD（销售与分销）中文培训PPT面向刚接触SAP ERP的销售、物流、财务等业务人员与实施顾问，用以系统梳理SD模块从询价报价、订单处理、定价确认到交运发货、开票及财务集成的完整流程，帮助读者建立端到端的业务认知。压缩包共1个文件，为单份ppt演示文稿，约2.09MB，内容以流程图与要点讲义形式组织，覆盖销售组织与分销渠道架构、客户与物料主数据、多种销售文档类型、定价条件、可用性检查、交运拣配包装、退换货与借项贷项凭证，以及与MM、PP、FI/CO模块的协同关系。该资料已有106人学习，适合作为入门培训讲义或日常实施查阅参考。

1. 一张报价单为什么能一路自动变成发票：SD 的价值在"链"而不在"单"

很多人第一次翻这份 SAP SD 中文培训资料，注意力都放在销售订单的录入界面上，觉得 SD 就是把纸质单据搬到屏幕里。真正反直觉的地方在于：订单只是链条上的一环，SD 的设计核心是让前一张单据能自动"生出"后一张单据，并让库存、财务、采购同时被牵动。询价变报价、报价变订单、订单变交货、交货变发票，每一步都靠文档流串起来，靠条件技术算出价格，靠可用性检查决定能不能承诺交货期。这份资料之所以值得逐页拆开看，是因为它把销售背后那条跨越 MM、PP、FI 的链路完整画了出来，而不是只教你怎么按保存键。

2. 组织架构与主数据：销售区域是怎么由四个维度拼出来的

2.1 从公司代码到销售区域：几个层级的挂载关系

SD 里几乎所有配置和主数据，最终都要落在一个坐标上，这个坐标就是销售区域（Sales Area）。它不是一张独立的表，而是三个字段的组合：销售组织（VKORG）+ 分销渠道（VTWEG）+ 产品组（SPART）。理解这一点，后面遇到"为什么客户查不到""为什么定价过程取不到"这类问题就都能立刻定位——因为你的数据建在 01/01/01，而单据跑在 01/02/01，坐标对不上，系统当然找不到。

往上追一层，销售组织要分配给公司代码。这一步的语义是：这个销售组织开的发票，最终记到哪个法人实体的账上。注意这里不是一对一——多个销售组织可以共用一个公司代码，一个销售组织也可能通过跨公司销售（Cross-Company Sales）服务多个公司代码，代价是要额外配置公司间开票（Intercompany Billing），由销售组织所属公司先向客户开票，再由供货工厂所属公司向销售组织所属公司开票，形成两条独立的应收应付。

往下追一层，销售组织还要分配给工厂。工厂才是交货和库存的真实来源，它同时属于 MM 和 PP 的口径。销售组织与工厂的分配关系在配置表里是多对多的，所以一个销售组织下的订单行，可以指定从任意一个已分配的工厂发货。这条分配链被切断时，最常见的报错就是创建订单时提示"未对销售组织 XX 分配工厂"。

分销渠道描述"货怎么出去"：直销、批发、零售、电商，各自是一条渠道，定价、交货类型、开票类型都可以按渠道差异化。产品组描述"卖的是哪条产品线"，财务上常对应事业部。两者都是纯粹的业务口径，不属于任何法人实体。

销售办公室（VKBUR）和销售组（VKGRP）在这一层之外，它们不构成销售区域，只用于把订单归到某个地理区域和某个业务小组，方便做销售统计和权限控制。把它们和销售区域混为一谈，是新人常犯的第一类概念混淆。

2.2 客户主数据的三层切片：通用、公司代码、销售区域

客户主数据是 SD 里被读得最频繁的对象，但它不是一张表，而是三层切片。第一层是通用数据，落在 KNA1，存地址、通讯方式、银行信息，全系统一份；第二层是公司代码数据，落在 KNB1，存对账科目、付款条件、催款程序，一个客户在每个公司代码下各一份；第三层是销售区域数据，落在 KNVV，键就是客户号 + 销售组织 + 分销渠道 + 产品组，存客户组、销售地区、定价过程、交货工厂、装运条件、开票冻结这些纯销售视角的属性。

为什么非要切成三层？因为同一个法人在不同渠道下的商业条款本来就不一样。某制造商既做直销又走经销商，同一个客户号在直销渠道下可能享受特殊折扣，在批发渠道下按标准价走，如果只留一份数据，就没法表达这种差异。三层结构把"法律实体""财务关系""商业关系"三种语义拆开，避免了一张巨表里大量字段被重复填充或者互相冲突。

界定字段状态的开关是账户组（Account Group），它在客户主数据里决定三件事：字段是必输、可选还是隐藏；号码是内部给号还是外部给号；默认挂哪个合作伙伴确定过程。所以你会看到一个客户创建界面里字段很少，换个账户组字段就多出一片——那不是界面问题，是账户组在控制字段状态。

合作伙伴是客户主数据的另一个维度，也是 SD 里最容易被忽略的设计。一张订单上可以同时存在售达方、送达方、付款方、开票方，它们可以指向不同的客户号。这套设计的动机是把一笔交易里的四种角色解耦：谁买、货送哪、谁付钱、发票开给谁。集团采购、集中付款、异地收货这些现实场景，靠的就是这四个角色可以分离。

-- 查客户在哪些销售区域下存在销售视图数据 -- KNVV 的主键就是 客户+销售组织+分销渠道+产品组，这四列缺一不可 SELECT kunnr, -- 客户号 vkorg, -- 销售组织 vtweg, -- 分销渠道 spart, -- 产品组 ktgrd, -- 客户科目分配组，影响开票时的收入科目确定 kalks, -- 客户定价过程，参与定价过程确定 bzirk, -- 销售地区，用于销售分析与权限 vwerk -- 交货工厂，订单行未指定工厂时的兜底来源 FROM knvv WHERE kunnr = '0000100000' AND loevm = ' '; -- 删除标记为空的才是有效记录

这段查询在排查"客户明明建过却下不了单"时几乎是第一步。如果返回结果里找不到订单正在使用的那个销售区域组合，问题就已经定位了，不用再去翻定价或者单据类型。注意loevm这个删除标记，很多客户被"删除"其实是打了标记，数据仍在表里，用不带条件的查询会看到一堆看似存在实则失效的行，白折腾半天。

2.3 物料主数据与客户-物料信息记录：谁的优先级更高

物料主数据在 SD 侧的关键视图是 MVKE，键是物料 + 销售组织 + 分销渠道，和 KNVV 的粒度几乎对称。这个视图里藏着几个决定后续行为的字段：科目分配组（KTGRM）参与收入科目确定，物料定价组（KONDM）参与定价条件表存取，项目类别组（MTPOS）参与项目类别确定，税分类参与税务条件计算。换句话说，订单行最终用什么项目类别、算什么税、记哪个收入科目，源头都在 MVKE 这四个字段上。

物料主数据的其他视图分工也很清楚：MARA 存基本计量单位、物料组这类全局属性；MARC 存工厂级的 MRP 类型、采购类型、生产周期；MARD 存库存地点级库存。SD 在订单里指定工厂后，实际读的是 MARC，交货时读的是 MARD 里的非限制库存。所以一个物料"销售视图建好了但下不了单"，很可能是工厂视图没维护，订单行一填工厂就报错。

再往上一层是客户-物料信息记录，落在 KNMT，键是客户 + 物料 + 销售组织 + 分销渠道。它的存在意义是覆盖物料主数据的通用值：某个客户对某个物料有自己的物料号、自己的最小订货量、指定的交货工厂、甚至自己的价格。信息记录的优先级高于物料主数据，低于单据上的手工输入。

把这条优先级链记住，能省掉大量调试时间。很多字段的取值顺序是一致的：单据手工输入 > 客户-物料信息记录 > 客户主数据 > 物料主数据。交货工厂就是典型例子，订单行指定了就用手工值，没指定就看信息记录，再没有就看客户销售视图里的默认工厂，最后才回到物料工厂视图。理解这条链的设计动机并不复杂——越靠近具体交易的数据越应该优先，因为它是针对这一笔业务专门设定的，通用配置只是兜底。

3. 文档类型与文档流：订单不是一张表，而是一条带状态的链

3.1 文档类型背后绑定了哪些"行为"

在 SD 里按下保存，写入的不只是 VBAK 一行抬头和 VBAP 若干行项目，而是同时被文档类型触发的一整套行为。文档类型（Sales Document Type，表 TVAK）是一个配置对象，它把十几个过程绑定在一起：号码范围决定单号从哪来；字段状态决定哪些字段必输、哪些只读；项目类别确定过程决定行项目用什么项目类别；计划行类别决定这一行要不要传递需求、要不要做可用性检查；交货类型和开票类型决定后续单据长什么样；合作伙伴确定过程、文本确定过程、输出确定过程各自挂一套规则。

这种"单据类型即策略容器"的设计，目的是让同一套代码支撑完全不同的业务。标准订单、退货、贷项凭证请求、借项凭证请求、合同、计划协议、免费订单，业务语义千差万别，但底层表结构完全一致，差异全部收敛在文档类型这一层配置里。代价是排错时你必须知道去查哪一层——单据行为不对，先看文档类型绑了什么，而不是直接怀疑代码。

项目类别是下一层。TAN 是标准项目，TANN 是免费项目，TAB 是单独采购，TAX 是第三方交易，REN 是退货项目。项目类别决定这一行是否参与定价、是否参与交货、是否参与开票、是否传递需求。第三方交易就是典型例子：货由供应商直发客户，企业自己不碰库存，所以项目类别要标记为不交货，交货由单独的采购流程完成。这些差异如果写成代码分支，系统早就没法维护了。

计划行类别再往下一层，管的是"什么时候、交多少"。它决定这一行的需求是否传递给 MRP、是否做可用性检查、是否触发采购申请。一张订单可以有多个计划行，每个计划行对应一个交货日期和一个数量，这就是分期交货的实现方式。

3.2 VBFA：前后序关系怎么被记录下来

文档流表 VBFA 是整个链条的骨架。它的每一行记录一对前后序关系：前置单号、前置行号、前置单据类别、后续单号、后续行号、后续单据类别、参考数量、计量单位，以及一个正负号字段。单据类别用单字符表示，订单是 C，交货是 J，发票是 M，物料凭证是 R，报价是 B，询价是 A。后续单据被创建时，系统把这一行写进去，之后所有追溯——从发票倒查交货、从交货倒查订单——都是在这张表上做连接。

为什么不用外键直接在单据表里指向前置单？因为一张单据可能引用多个前置单据，也可能被多个后续单据引用，是典型的多对多。一张交货单可以合并十张订单的发货，一张发票可以合并多张交货单开票，退货和贷项凭证还会产生反向关系。用独立的关联表记录，才能同时支撑拆分、合并、冲销这些操作。

正负号字段是这套设计里最精妙的一处。正常销售是正向流转，退货则是一条反向边，数量以负数记入。这样在统计"某张订单实际发出去多少"时，只要把文档流里所有后续单据的参考数量带符号累加，就能自动扣掉退货，不需要为退货单独写一套统计逻辑。这也解释了为什么做报表时直接读单据表的数量字段经常对不上，必须走文档流汇总。

单据状态是另一条线索。订单抬头和行项目上有一组状态字段：总体处理状态、交货状态、开票状态、拒绝状态。交货状态在交货单创建后变化，开票状态在发票生成后变化，但真正决定"能不能继续往下走"的往往是明细状态，比如拣配状态、发货状态。排查"为什么这张订单开不了票"，实际是沿着状态字段一条条往回找哪一步没完成。

提示：核对文档流断裂时，先看 VBFA 里有没有对应边，再看前置单据的状态字段是否允许后续动作。两处都对，才轮到怀疑配置。

3.3 从订单到交运、发货过账、开票：一条时序与它的账务后果

把这几个动作按时间排开，才能看清每一步改了什么数据、留了什么后果。

第一步，订单保存。需求按计划行类别传递到 MRP，物料需求计划据此生成采购申请或生产订单；同时可用性检查在计划行上算出确认数量，写回确认表和计划行。此时库存没动，账也没动，只是产生了一条承诺。

第二步，创建交货单。参照到期交货清单批量生成，系统从订单复制客户、物料、数量、批次信息，同时执行一次可用性检查和信用检查。交货单本身也是两层的：抬头 LIKP 存送达方、装运条件、交货日期，行项目 LIPS 存物料、数量、工厂、库存地点、批次。

第三步，拣配与包装。拣配确认实际从货架拿了多少，写回拣配数量；包装把若干件装进一个处理单元，生成包装单据。这两步只影响仓库作业数据，不影响账面库存。

第四步，发货过账。这是链条上第一个真正改账的动作。移动类型 601 把库存从非限制使用状态扣掉，生成物料凭证，同时把成本从存货科目转入销售成本科目，形成第一张会计凭证。交货单的发货状态随之更新，文档流里补上一条从交货到物料凭证的边。

第五步，开票。参照交货单创建发票，开票类型决定这是标准发票、贷项凭证还是借项凭证。开票时重新执行定价，把收入、税额、成本条件一并算出，过账后生成第二张会计凭证：借方客户应收，贷方收入和应交税费，同时用成本条件冲销前面结转的销售成本。至此文档流闭合，订单的开票状态更新为完成。

看清楚这个顺序，就能理解一个常见现象：为什么发票金额和订单金额有时对不上。发票的定价基准可能不是订单日期而是交货日期，价格条件在两次定价之间如果有效期、税率、折扣发生了变化，结果自然不同。这不是 bug，是设计上把定价当作"在开票时点重新计算"的动作，而不是把订单价格原样搬过去。

4. 定价的条件技术：一张订单的价格是怎么被"算"出来的

4.1 条件表、存取顺序、条件类型的三层解耦

价格算得准不准，取决于条件技术这套表驱动机制。它把"价格从哪来"拆成三层：条件类型定义价格的性质，条件表定义查找的维度，存取顺序定义多个条件表之间的优先级。

条件类型是业务语义的最小单位。基本价格、客户折扣、物料折扣、数量返利、运费、附加费、税额、成本，各是一个条件类型，各自有一套计算规则：是固定金额、百分比，还是按重量计价。条件类型还决定这个条件是否可以被手工覆盖、是否参与小计累计、是否打印在单据上。

条件表定义"按什么找"。客户+物料是一张表，客户+物料组是另一张，物料+工厂又是一张。每张表就是一组键字段的组合，系统按这组键去条件记录表里查匹配的行。

存取顺序把若干条件表排成一条查找序列。以基本价格为例，序列可能是：先找客户+物料的专用价，找不到再找客户+物料组的价，再找不到找物料+工厂的价，最后回到物料的标准价。这个"逐级回退"的设计是条件技术真正的价值所在——你不需要为每个客户都建一条价格记录，只需要在差异发生的那一层建即可，上层自动覆盖下层。

条件排斥组是配套的开关。两个条件类型如果被分到同一个排斥组，系统只会激活其中一个，避免重复计算。常见于"促销折扣"和"合同折扣"只能二选一这类业务规则。

注意：条件记录有有效期。价格对不上时，先确认条件记录的生效区间覆盖了定价日期，而定价日期来自文档类型配置，不一定等于订单创建日期。

4.2 定价过程：步骤、从/到、需求与统计

定价过程（Pricing Procedure）把所有条件类型按顺序编排成一个计算方案。每一行有步骤号、计数器、条件类型、从和到、需求、统计标记、打印标记。

从和到这两个字段专门服务于小计。假设步骤 100 到 200 是基础价格和各项折扣，步骤 300 是一个小计条件类型，那么小计行会声明"从 100 到 200"，把这段区间的金额累加起来，存进定价记录的一个小计字段里。后续如果有一个按净价百分比计算的折扣，直接引用这个小计字段作为基数即可。这套机制让"先减折扣再算税"和"先算税再减折扣"这类顺序差异，可以通过步骤编排精确表达，而不需要写代码。

需求字段挂的是一个例程号，用来在运行时判断这一行是否参与计算。有些折扣只对大客户生效，有些附加费只在出口业务里加，这些判断都以例程的形式挂在定价过程行上。

统计标记是另一个容易忽略的开关。标记为统计的条件类型只参与计算和显示，不进净价，典型例子是成本条件——它必须被算出来，因为要结转销售成本，但不能影响对客户的报价。

定价过程本身也需要被确定出来。系统按销售文档类型对应的单据定价过程，加上客户主数据里的客户定价过程，两者组合查出最终使用的定价过程。所以同一个物料卖给两个客户，价格计算方案可以完全不同，这就是为什么"客户定价过程"这个字段在客户销售视图里那么关键——它一旦为空，整条定价链路就断了。

4.3 定价例程与 KONV：算完的价格落在哪

条件记录表存的是"规则"，定价结果落在 KONV 里。KONV 的键是定价条件号加行号加步骤号加计数器，字段包括条件类型、金额、币种、定价单位、条件值、激活状态、条件控制。每一张单据在保存时都会把自己的定价结果写进这张表，所以你可以从订单倒查每一步用了哪条条件记录、金额是多少、哪一步被跳过了。

激活状态字段是排查定价问题的关键。它有几种取值：激活、被替代、不适用、被删除。价格"被划掉"通常意味着这一行的激活状态不是激活，可能是条件排斥、可能需求不满足、也可能被后续同类型条件覆盖。

下面这段 ABAP 是定价需求例程的典型骨架，用来控制某个折扣条件类型是否参与本次计算。这类例程在系统里按编号挂到定价过程行的需求字段上，运行时由定价引擎回调。

FORM frm_kond_bedingung_901 USING komk STRUCTURE komk komp STRUCTURE komp. DATA: ls_pr00 TYPE komv, lv_qty TYPE komp-mgval. " KOMP 是当前行项目的通讯结构，MGVAL 为订单数量 lv_qty = komp-mgval. " 从当前定价过程已算出的条件里，回查基本价格是否已成功取到 READ TABLE xkomv WITH KEY kschl = 'PR00' INTO ls_pr00. IF sy-subrc <> 0 OR ls_pr00-kbetr IS INITIAL. " 基本价格都没有，后面基于价格的折扣没有意义，直接判定不成立 sy-subrc = 4. EXIT. ENDIF. " 业务规则：数量达到 100 且客户组为 Z1 时才允许该折扣生效 IF lv_qty >= 100 AND komk-kdgrp = 'Z1'. sy-subrc = 0. " 0 表示条件成立，本行参与计算 ELSE. sy-subrc = 4. " 4 表示条件不成立，本行被跳过 ENDIF. ENDFORM.

KOMK是抬头通讯结构，携带客户号、客户组、销售组织、币种这类抬头级信息；KOMP是行项目通讯结构，携带物料、数量、工厂这类行级信息；XKOMV是当前正在计算中的定价行内表，可以在例程里回查前面步骤已经算出的结果。返回值的约定很关键：SY-SUBRC = 0表示条件成立，本行参与计算；返回 4 表示不成立，本行跳过。写成其他值会导致行为不可预期，这是血泪经验——例程里任何分支都必须显式设置返回值，不能依赖初始值。

例程里读XKOMV而不是去读数据库，是出于一致性考虑：定价是一个按步骤顺序推进的过程，后面的步骤必须看到前面步骤的中间结果，直接查表会读到旧数据。理解这一点，就能解释为什么有些需求例程在单独测试时正常、放进定价过程就失效——它读的是运行时结构，不是持久化数据。

5. 常见问题排查：那些"配置没错但结果不对"的坑

5.1 客户建过了，订单却说未在销售区域定义

现象：客户主数据里明明能查到，创建订单时依然报"客户未对销售区域 XX/XX/XX 定义"。

原因：客户销售视图是按销售组织、分销渠道、产品组三个维度分别存储的，账户组不同还可能影响这几个维度是否必输。主数据建在直销渠道，订单却跑在批发渠道，两个坐标下的 KNVV 记录互不相干，系统当然找不到。

解决：先用 2.2 节那条 SQL 查出客户实际存在的销售区域组合，与订单抬头上的三个字段逐一比对；缺哪个就用客户主数据的事务码把销售视图扩展到目标组合。批量场景下用批量维护工具一次性铺开，不要一条条手工建，否则渠道一多必然漏。

5.2 定价分析显示某一步"没找到"

现象：订单净价和预期差一截，展开定价分析发现某个折扣条件类型的行显示未激活。

原因：四类可能——条件记录的有效期没覆盖定价日期；存取顺序里靠前的条件表已经命中，后面的被短路；该条件类型与另一条件类型处在同一排斥组，被排斥掉了；定价过程行上挂的需求例程返回了不成立。

解决：逐层排除。先看条件记录的有效期和定价日期；再看定价分析里每一步的存取结果，确认是哪张条件表命中、哪些表被跳过；然后核对排斥组配置；最后才怀疑需求例程。顺序反过来做会浪费大量时间，因为前三种情况占绝大多数。

5.3 库存明明有，交货单却过不了账

现象：库存总览显示非限制库存充足，发货过账仍提示库存不足。

原因：可用性检查承诺给其他订单的数量已经把库存占满了，账面库存和可用库存是两回事；或者交货单行指定的库存地点、批次与有库存的位置不一致；也可能库存处在质检或冻结状态，不参与非限制使用。

解决：用可用性总览按物料和工厂查看当前确认需求和可用数量，确认占用来源；再核对交货单行上的工厂、库存地点、批次三个字段是否与实际库存位置一致。这类问题在批次管理的物料上尤其多，因为多了一个维度，坐标对不上的概率成倍上升。

5.4 发票金额和交货单金额对不上

现象：交货单上的金额和最终发票的净价差异明显，或者税额算出来不对。

原因：发票不是简单复制交货单金额，它在开票时点重新执行定价。如果开票的定价日期取的是交货日期而非订单日期，期间发生税率调整、条件记录过期、折扣失效，结果就会变。另一类原因是开票的复制控制配置决定了哪些字段从交货单带过来、哪些重新确定，配置不同行为就不同。

解决：在发票上打开定价分析，逐行比对两次定价的差异来源，重点看定价日期和条件记录有效期。确认是业务预期如此，还是复制控制配错了。分辨方法很直接：如果差异只出现在跨月的单据上，基本可以判定是日期驱动的定价差异。

5.5 发票过账报错，提示科目确定失败

现象：发票保存时提示无法确定收入科目，或者过账后收入记到了错误的科目上。

原因：收入科目确定依赖一组维度的组合——客户科目分配组、物料科目分配组、工厂、税分类等。任意一个维度在主数据里没维护，或者维护的值在科目确定配置表里没有对应行，就找不到科目。税分类缺失还会连带导致税务条件取不到，税额算成零。

解决：先把客户销售视图里的科目分配组、物料销售视图里的科目分配组、物料的税分类这三个字段逐个核对，再拿这组值去科目确定配置里比对是否配有对应行。这一步的关键是"组合"思维——单独看每个字段都没问题，组合起来没有配置行，一样报错。

6. 配置与代码的边界：SD 为什么把灵活性放在主数据和条件表里

回头看这套设计，取舍其实非常清晰：它把业务的差异性下沉到配置和主数据，让同一套程序支撑完全不同的销售模式，代价是链路变长、定位变难。

第一个取舍是"文档类型即策略容器"。订单、退货、贷项凭证在表结构上完全一致，差异收敛在文档类型绑定的十几个过程上。好处是新增一种业务形态只需要配置，不用改代码；代价是任何一个行为异常，你都得先搞清楚是哪一层配置在起作用。这也解释了为什么熟手排查问题的第一反应是看配置绑定关系，而不是看程序。

第二个取舍是"条件技术用表驱动替代硬编码"。三层解耦让价格策略可以逐级回退、按维度覆盖，业务方改价格不需要开发介入。代价是每次定价都要遍历存取序列，性能开销和可解释性都需要额外机制来兜底——定价分析那个工具本质上就是为这套机制配的"黑匣子记录仪"，没有它，条件技术几乎无法调试。

第三个取舍是"文档流用关联表而非外键"。多对多的关联表支撑了拆分、合并、冲销、退货这些操作，让一条链路可以被完整追溯。代价是所有统计都必须走汇总，不能直接读单据表的数量字段。

验证这些取舍是否被正确使用，我的习惯是画一张"影响面清单"：改任何一个配置之前，先问它挂在哪个坐标上——是销售区域维度的，还是文档类型维度的，还是条件表维度的。挂在销售区域的，就要检查所有相关组合是否都覆盖；挂在文档类型的，就要检查所有引用它的单据；挂在条件表的，就要检查存取顺序里的前后顺序。这张清单画出来，八成的"配置没错但结果不对"在动手之前就能被排除掉。

从那以后，我每接手一套新的销售配置，都会先把销售区域组合、文档类型绑定、条件存取顺序这三张表拉出来对一遍，再动任何一个字段。这份培训资料的价值也在这里——它没有停在界面操作上，而是把这条链上的每一环都摆出来，让你能看到环与环之间是怎么咬合的。希望帮到你。

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