简介：SAP SD（销售与分销）模块的中文培训资料，面向刚接触SAP ERP销售业务流程的顾问、关键用户与实施人员，帮助建立从询价、报价、合同、销售订单到交运、开票及财务集成的完整认知。压缩包内共1个PPT文件，大小约2.09MB，以幻灯片形式覆盖销售组织与分销渠道、客户及物料主数据、定价条件、销售文档类型、可用性检查、拣配包装发货、退货与借项/贷项凭证等主题，适合课堂培训与自学查阅。目前已有106人学习。资料结合供应链总览、销售流程总览、组织架构、主数据视图和定价条件组等图示，串起SD与MM、PP、FI/CO的协同关系，便于理解订单确认、需求传递、库存提取、交运处理与发票生成的关键节点。对需要系统掌握SAP SD核心概念和销售全流程的读者，可作为入门梳理与培训讲解的参考材料。

1. 知识地图：SD 在供应链里的位置，先看清再背细节

把 SAP SD 当成一堆事务代码去背，是最费劲也最容易忘的学法。它其实是一条从客户需求走到收款入账的传送带：询价、报价、销售订单、交运、发票，五段首尾咬合，任何一段的主数据没配好，后面整条链都会抖。这份笔记按四个模块铺开——组织与主数据、文档与功能触发、定价与检查、交运开票与财务集成，末尾再补一张易错点清单和一份复习清单。正在系统学销售和分销的人可以拿它当骨架，临考前或上线前可以拿它查漏补缺。先记住地图上的一句话：SD 往下游输出的是需求和收入，需求流向 MM 与 PP，收入流向 FI 与 CO，中间任何一个字段没配，链条就在那里断。

2. 组织与主数据：四层结构、三段客户、两种信息记录

订单建不出来、价格带不出来、交运单找不到发货工厂，这三类问题十有八九不在订单里，而在订单之前的主数据里。SD 的地基由两样东西决定：组织架构定“谁在哪儿卖什么”，主数据定“卖给谁、卖什么、怎么收钱”。这两样配完整了，后面的文档、定价、交运才有意义；配不完整，每个环节都会用报错提醒你一次，只是提醒的方式不一样，有的是硬拦截，有的是悄悄取了个默认值，等到月底对账才发现。

组织架构这一块，教材上画成一张层层嵌套的树，其实真正参与订单的只有三个字段，其余都是给报表和输出用的分类标签。主数据这一块，客户分三段、物料分多视图，看着繁琐，本质是把“一个客户可能跨公司、跨渠道”这件事拆开存，避免改一处影响一片。理解了这个动机，再去看那些灰色不可填的字段，就不会觉得是系统在故意刁难人。

2.1 组织结构：销售区域是三个字段拼出来的

SAP 里没有“销售区域”这个独立的组织单元，它是销售组织、分销渠道、产品组三个字段的组合值。客户主数据里的销售视图就是挂在这个组合上的，订单一建，系统拿售达方加销售区域去捞默认值：付款条件、装运条件、定价过程、交货工厂，全靠这一次匹配。匹配不上，订单就变成一堆要手工填的空格，或者干脆被不完整性日志拦下。

上表里只有前四个字段会真正卡住业务，销售办公室和销售小组属于“配了更好看”的一类。很多人复习时把它们和销售区域混为一谈，记成五层结构，做题时一填就错。梳理下来会发现一个规律：凡是直接影响单据生成的，都是必填且强校验的；凡是只影响统计维度的，系统允许空着，但空着之后报表就是一片空白，这也是上线后最常被业务抱怨的地方。

另外要留意工厂和库存地点在 SD 里的角色。销售订单里的行项目要指定交货工厂，工厂再往下挂库存地点，交运单的拣配就是从这些库存地点里扣。工厂本身属于物流侧的组织单元，但在 SD 的交运环节反复出现，所以复习的时候把它和销售组织放在一起对照着记，比单独背一张组织架构图有效得多。

2.2 客户主数据的三段式与四种业务伙伴

客户主数据按三个层次存：通用数据、公司级数据、销售区域数据。这个设计是为了解决一个很现实的问题——同一个客户可能在多个公司代码下交易，付款条件各不相同，但地址只有一个。如果全塞在一张表里，改地址就得改好几条记录，早晚改漏。

三段里最容易漏的是第三段。很多人在一个销售组织下建完客户，以为大功告成，换到另一个销售组织建订单时发现价格没了、交运条件空了，原因就是销售区域数据没扩。补的办法不复杂，按目标销售区域再维护一次即可，关键是养成习惯：新建客户后先看一眼不完整性日志，缺哪段一目了然。

合作伙伴功能是客户主数据里最像“隐藏关卡”的部分。同一笔业务里，下单的人、收货的人、付钱的人、收发票的人可能完全是四个主体，系统用四种功能把它们拆开。

四个强制项少填一个，订单保存时就会被拦住。实际业务里最常见的情况是集团客户：总部下单、分公司收货、财务中心付款、另一个主体收票。这四种主体在系统里是四条独立记录，通过伙伴功能串起来。如果只填售达方，后面的交运和开票环节会分别报错一次，排查起来要跑两趟。

2.3 物料主数据与客户-物料信息记录

物料主数据是按视图组织的，SD 关心的是销售组织数据和工厂数据这两块。基本数据里放计量单位，销售组织数据里放销售单位、最小订单数量、最小交货数量，工厂数据里放 MRP 视图和可用性检查相关的参数。这几块拼起来，才决定了“客户下 60 件”在系统里到底意味着什么。

单位处理是最容易想当然的地方。举例来说，某个物料的基本计量单位是件，销售单位是箱（Carton），仓储和运输还用到托盘（Pallet），同时主数据里写了最小订单数量 60 件、最小交货数量 60 件、发货单位 4 件。这意味着：客户下单时按销售单位取整到 60，系统按发货单位的 4 的倍数去拆分交运数量。两个取整规则不一致的时候，订单 60 件、交运也能拆成 60 件，但拣配和包装环节按 4 件一箱打，最后一箱装不满，仓库就会来问为什么会有半箱。这类差异不会在订单保存时报错，只会在拣配/包装环节冒出来，属于典型的“配置时看不见、执行时才疼”。

客户-物料信息记录是另一件常被忽略的东西。客户下单时用的是他们自己的物料编码和描述，我们要翻译成自己的物料号。这张信息记录里存的正是客户物料编码、客户描述、额外的交运数据以及部分交货标记。维护好之后，录单时输入客户料号就能自动带出我方物料，既快又不出错；没维护，业务员就只能靠记忆或者翻 Excel，错一单的成本远超维护这张表的时间。

这两类主数据加上前面的组织架构，构成了 SD 的第一层地图。复习的时候可以按“组织 → 客户 → 物料”的顺序走一遍，每一层问自己三个问题：这个字段影响哪张单据、缺了会报什么错、谁负责维护。三问答得出来，这一层就算过了。

3. 销售文档：文档类型决定整条流程的行为

销售文档这一块，背字段是下策，背文档类型的含义是中策，理解“文档类型是一个开关组”才是上策。同一张订单界面，换个文档类型，字段变成必填、变成隐藏、变成只读，交运和开票的触发逻辑也跟着变。很多人复习到这里喜欢列一张长长的类型清单就收工，真正到用的时候还是分不清标准订单和交货协议的区别，问题就出在只记了名字，没记它打开了哪些开关。

这一章按三层推：先看文档类型怎么按业务阶段分组，再看一个文档类型背后挂了哪些功能，最后看文档流怎么把订单、交运、发票串成一条可追溯的链。三层走完，遇到一张陌生单据，至少能判断出它处在流程的哪一段、下一步该谁接手。

3.1 文档类型谱系：三个阶段十来种类型

按业务阶段分，销售文档类型可以归成三组。售前阶段负责把需求说清楚，销售阶段负责把承诺落下来，售后与调整阶段负责把偏差补回去。三组之间的转换关系比单个类型本身更重要。

上表里最容易被低估的是合同和交货协议。它们的行项目和标准订单长得几乎一样，但多了一层计划行，订单要靠计划行按日期释放，不是建完就完。如果按标准订单的思路去理解，就会觉得“为什么建了合同却没有交运需求”，然后开始怀疑配置。退货、贷项、借项三类则是另一个易混点：退货是货往回走，贷项是钱往回走，借项是钱往前补，三者可以组合使用，但各自的后续单据完全不同。

还有一类是发票侧的类型，包括发票、发票取消、公司间发票、现金销售、形式发票等，它们属于开票环节，放到第 4 章展开。这里先建立印象：文档类型是一套按业务阶段分布的家族，不是一张平铺的清单。

3.2 一个文档类型背后挂着的七项功能

文档类型的价值不在标签，而在于它决定了保存那一刻系统要跑哪些功能。归纳下来常被考、也常被踩的是七项。

这七项里，定价和可用性检查最容易出“静默错误”——系统不报错，只是给了一个你不想要的结果。比如可用性检查的范围设得太松，订单照常保存，等到交运那天才发现库存被别的订单占完了。传递需求和交货计划则是联动项：订单没写交期，到期交运清单里就什么都没有，仓库不背这个锅。

信用检查的触发点值得单独记一笔：它既可能在订单保存时触发，也可能在交运发货过账前触发，取决于配置的是哪个检查时点。很多项目上线后出现“订单被卡住但没人知道原因”，十有八九是信用额度或风险类别配得不对，而不是流程有问题。

3.3 文档流、状态与不完整性日志

文档流是 SD 里最值得掌握的一项基本功。订单生成交运，交运生成发票，每一步都记录在关系表里，形成一条前驱后继的链。有了这条链，客户问“我那批货到底走到哪一步了”，你能在三十秒内答出来；没有这条链，就只能一张单据一张单据地翻，翻到最后还得靠猜。

" 读取一张销售订单的单据流：订单 -> 交运 -> 发票 " VBFA：销售单据流表，记录前驱/后继关系 SELECT vbelv, " 前驱单据号，这里是销售订单号 posnv, " 前驱行项目号 vbeln, " 后继单据号，如交运单、发票号 posnn, " 后继行项目号 vbtyp_n " 后继单据类别代码，具体取值以系统配置为准 FROM vbfa INTO TABLE @DATA(lt_flow) WHERE vbelv = @lv_order AND vbtyp_n IN ( 'J', 'M' ). " 常见的 J 为交货、M 为发票

这段查询的逻辑很直白：以订单号为前驱键，把后继单据全部拉出来，再按单据类别过滤出交货和发票。扣住三个参数就够了——前驱单据号用来定位起点，后继单据类别用来筛环节，行项目号用来看是哪一行货物走到了哪一步。如果查出来只有订单没有交运，说明交货计划没生成；如果有交运没有发票，说明开票还没执行或者被开票到期清单挡住了。这条排查路径比逐个事务代码去点要快得多。

状态管理是文档流的分支。抬头状态和行项目状态各自独立，整体处理状态通常分未处理、处理中、已完成几档。状态不看界面也能改，很多后台作业会把状态批量推进，所以复习时不要死记某一档的名字，记住“状态是谁在什么动作之后推进的”更有用。不完整性日志则是另一件救命工具：字段没填全时，系统不会直接拒绝保存，而是先弹出一个列表，告诉你缺哪些字段、在哪个视图。上线初期业务员最常问的“为什么保存不了”，答案基本都在这个日志里。养成保存前扫一眼日志的习惯，能省掉大量来回沟通。

4. 定价、可用性与交运开票：从条件记录到发票入账

定价是 SD 里公认最像玄学的一块。价格没带出来，老手的第一反应不是改配置，而是按“存取顺序 → 条件表 → 条件记录”三层往下倒查，因为八成的原因在最底层的条件记录没维护，跟配置一点关系都没有。把这条链摸清楚，定价就从玄学变成了流程题。

这一章把后半段流程一次走完：条件技术怎么组织价格，可用性检查和信用检查什么时候介入，交运怎么从到期清单走到发货过账，发票怎么回写财务。这四件事的共同点是都跨模块，出错时现象往往出现在别的模块里，所以复习时要顺着单据走，而不是按模块背。

4.1 条件技术的四层结构与定价过程

条件技术分四层，从下往上依次是条件记录、条件表、存取顺序、定价过程。条件记录是实际维护的价格数据；条件表规定了用哪些字段的组合去定位一条记录；存取顺序决定多张条件表按什么优先级找；定价过程则把一堆条件类型按步骤排好，规定谁先算、谁基于谁算、哪些进小计。

条件表里那些控制字段，翻译成人话就是“价格按什么维度区分”。按客户、按物料是最常见的两种，价格组和物料定价组是把一批客户或一批物料归堆，避免逐条维护；离港国和目的国用于出口场景；数量字段用于阶梯价；日期用于季节性价格。字段越多，匹配越精确，维护量也越大，所以实际项目里往往是分层的：常用维度用粗粒度条件表，个别客户用细粒度条件表兜底。

定价过程是这套结构里唯一需要“读顺序”的部分。每一步有从第几步到第几步的范围、计算类型、是否参与小计、以及一个需求例程。读的时候不要横着读，要竖着看小计，弄清楚哪几步累加成基价、哪几步在基价上打折、哪几步在折后加税。小计搞明白了，定价过程就通了。

4.2 定价过程怎么读，以及三种常见错配

一个典型的定价过程大致长这样：先取物料价格作为基价，再用客户折扣或数量折扣往下减，中间穿插运费和附加费，最后算税。每一步的计算类型决定了它是覆盖、是加、是减、还是按百分比算。复习时把步骤表默写一遍，比背十个条件类型名字有用。

三种最常见的错配，第一种是定价过程没分配给客户或订单类型，结果是价格整片空白，这时去查条件记录纯属浪费时间，先看定价过程的分配表。第二种是存取顺序里多张条件表优先级颠倒，导致专用价格被通用价格覆盖，现象是“明明给这个大客户维护了专属价，订单里却是标准价”。第三种是小计设置错误，折扣算在了税后面，或者运费进了折扣基数，金额差得不多所以很难被发现，只能靠对账时逐单核对。

排查顺序建议固定成三步：先看定价过程有没有带上，再看存取顺序找到的是哪张条件表，最后看那条条件记录本身的有效期和状态。三步走完还查不出来，再回头看需求例程，这一步的概率很低，但一旦命中就是黑匣子级别的难查，值得留个印象。

4.3 可用性检查与信用检查

可用性检查回答的是“这批货现在能不能承诺给客户”。它看的不只是当前库存，还把已分配的需求、计划入库、在途数量一起算进去。检查分时点：订单保存时做一次静态检查，交运创建时再做一次，两次结果可能不一样，因为中间可能被别的订单占用了库存。

" 查询指定物料在指定工厂、指定日期的可用数量 CALL FUNCTION 'BAPI_MATERIAL_AVAILABILITY' EXPORTING plant = '1010' " 工厂，必须与物料主数据中的工厂一致 material = 'M1' " 物料号 unit = 'PC' " 计量单位，需与物料基本计量单位可换算 check_date = sy-datum " 检查日期，决定取哪一天的计划库存 IMPORTING av_qty_plt = lv_avail " 返回的可用数量（工厂层级） TABLES wmdvsx = lt_requirements " 输入需求行，为空则只按现有库存与计划评估 wmdvex = lt_availability. " 输出可用性明细

调用时的关键参数是工厂、物料、单位和检查日期四个。单位必须能跟基本计量单位换算，否则返回的数量没有意义；检查日期决定系统取哪一天的库存和计划入库，做远期承诺时要按交期传，不能图省事传当天。返回的可用数量是工厂层级的汇总值，如果要看批次或库存地点级别的明细，得读第二张输出表。业务上最常见的误用是拿这个结果直接当承诺量，忽略了安全库存和已确认的需求，最后交不出来货。

信用检查是另一道闸门。它按信用额度、信用组、风险类别几个维度判断，触发点可以在订单，也可以在交运发货前。放在订单端，优点是早拦截，缺点是订单多的时候容易误伤；放在交运端，优点是不影响下单体验，缺点是货已经拣出来了才被拦，仓库白干一趟。这个取舍没有标准答案，取决于行业和客户结构，复习时记住“两个时点都可以配”就够了。

4.4 交运：从到期清单到发货过账

交运这一段的标准动作是：到期交运清单 → 生成交货单 → 提货 → 拣配 → 包装 → 运输 → 发货过账。到期交运清单按交期把该发的订单行捞出来，是仓库每天上班第一件事要看的东西；交货单生成后，提货单告诉仓库去哪些库位拿多少货；拣配确认实际拣出的数量；包装决定装箱和托盘；运输环节安排承运方；最后发货过账，库存才真正减少。

发货过账这一步的影响面比想象中大，一次过账会同时改动五处：减少仓库库存、按金额更新库存科目、减少交运需求、更新销售与交运的文档流、为后续开票创建工作清单。这五件事里任何一件没发生，后面都会出问题——库存没减，盘点对不上；科目没更新，财务成本算错；需求没减，MRP 还在重复采购；文档流没更新，客户问进度答不出来；开票清单没生成，发票漏开。所以复习时不要把发货过账当成一个按钮，它是一次跨模块的写操作。

特殊场景也要顺带记一下。第三方供应商直发时，货不从自己仓库走，交运单依然要建，但拣配环节被跳过；寄存和临时存放处理则涉及库存所有权的差异，单据流和普通销售不一样。这些场景在考试里出现频率不高，在实际项目里却经常是“为什么这张交运单拣不了配”的答案。

4.5 发票类型与 FI/CO 落点

开票是 SD 的收尾动作，也是 SD 与财务的接口。发票通常参考交运单生成，数量以实际发货为准，金额由定价结果决定。开票完成后，数据同时落到应收和成本两侧：应收侧生成应收账款和销售收入，成本侧结转销售成本并减少存货。

这张表里最常被混淆的是发票取消和贷项凭证。发票取消针对的是“这张票开错了”，处理方式是冲销原票再重开；贷项凭证针对的是“这笔钱确实不该收那么多”，属于业务上的减免。两者在财务上的痕迹完全不同，混用会导致应收账龄分析失真。形式发票则是另一个坑，它不产生应收，只作为单据使用，误把它当正式发票入账，月底对账必然出问题。

5. 易错点：主数据、文档与集成三处最容易翻车

前面四章是按模块顺着讲的，这一章换个角度，按“错在哪”倒着讲。梳理下来会发现，SD 的错很少是单点错，基本都是“某处没配 → 系统给了个默认值 → 现象出现在另一个模块”。这类错最麻烦的地方在于，报错信息和真实原因隔了好几层，不看单据流根本找不到源头。

下面按三个方向列出五个最容易漏、也最容易在复习和实操里翻车的点，每条都按“易漏点 → 为什么漏 → 怎么补”走一遍。这五条覆盖了从建单到入账的主干，考前过一遍，比再刷十道选择题有用。

5.1 主数据与组织类

易漏点一：客户主数据只建了通用数据，销售区域数据没扩。

为什么漏：新建客户时系统允许只填通用数据和公司级数据就保存，界面不报错，看起来一切正常。等到另一个销售组织的人建订单，才发现价格、交运条件、伙伴功能全是空的。很多人第一反应是“定价配错了”，实际是客户数据没扩到那个销售区域。

怎么补：建完客户立刻查一次不完整性日志，按目标销售区域补全销售视图、交运视图、开票视图和伙伴功能。日常排查时养成习惯，先看客户主数据在目标销售区域有没有记录，再看配置。这个顺序调过来，能省掉一大半无效排查。

易漏点二：四个强制伙伴功能只填了售达方。

为什么漏：售达方是下单主体，最直观，填完就能继续往下走，系统在录入阶段不会立刻拦住。等到交运环节要取收货地址、开票环节要取付款方，才逐个报错，而且每次只报一个，补完一个又冒一个。

怎么补：把四个强制项当成一组来填，售达方、交运方、付款方、开票方，同一主体时直接复制，不同主体时分别建客户记录再挂上去。集团客户场景尤其要确认付款方和开票方是不是同一主体，这两个搞混，发票寄错地方是小事，应收挂错客户是大事。

5.2 文档与流程类

易漏点三：文档类型选错，用标准订单去承接退货或补收。

为什么漏：标准订单是最熟的类型，建单时手一快就选了它，界面上字段都能填，看起来没毛病。问题在后面：标准订单触发的是正向交运和正向发票，退货该走的反向流程完全没启动，等到要开贷项凭证时发现参考不到对应单据。

怎么补：建单前先确认业务性质——货往前、钱往前、货往回、钱往回，四种组合对应四类文档。退货用退货类型，退款用贷项凭证请求，补收用借项凭证请求。已经建错的，不要硬改，走冲销重建，成本比后面手工调账低得多。

易漏点四：可用性检查范围设得过松，订单照常保存但承诺了不存在的货。

为什么漏：可用性检查不通过时，系统默认是给警告而不是报错，业务员点了回车就过去了。配置层面，检查范围如果没把相关需求类型纳入，系统算出来的可用量会偏乐观，看起来“库存充足”。

怎么补：先确认检查范围覆盖了哪些需求类型，再看超量时的处理方式是警告还是错误。对交期敏感的物料，把关键需求类型都纳入检查，并对超量设成硬拦截。日常用可用性查询核对订单承诺量，别等交运时才发现缺口。

5.3 集成与账务类

易漏点五：发货过账后才发现科目或库存有问题，只能靠冲销回滚。

为什么漏：发货过账在 SD 侧只是一个动作，但它在 MM 侧减库存、在 FI 侧记成本，任何一侧的配置缺失都会在过账瞬间爆发。很多人在测试环境只测了单据能不能建，没测过账，上了生产第一批货就卡住。

怎么补：上线前把“建单 → 交运 → 拣配 → 发货过账 → 开票 → 财务凭证”这条链完整跑通一遍，重点看过账后库存科目、成本科目、应收科目是否都落了数。出问题时先看物料主数据的会计视图和工厂视图，再看自动记账的科目确定配置，最后才怀疑单据本身。这条链跑通一次，后面九成的问题都能定位。

这五条的共同点是：错误现象和真实原因不在同一个模块。复习时把它们当成五个排查入口记住，遇到报错先想“这个现象最可能从哪来”，比从报错信息逐字读起要快得多。

6. 复习清单：用一张自检表把 SD 从头到尾走一遍

复习 SD 最忌讳按事务代码顺序从头点到尾，点完一遍什么都没记住。更有效的做法是按单据流走：从客户主数据出发，经过订单、交运、发票，最后落到财务凭证，每一步问自己“这一步的输入从哪来、输出到哪去、缺了会怎样”。走完一遍，知识就从散点连成了线。

下面这张自检表可以当成复习的索引，每一行对应一个必须能答上来的问题。答不上来的，回到对应章节补，不要跳。

表格之外，还有三个动作值得在复习时固定下来。第一个是画图：拿一张白纸，从客户主数据画到财务凭证，把每一环的单据名和关键字段标上，画不出来就说明那一环还没通。第二个是倒查：随便挑一个报错现象，比如“价格为空”，自己走一遍排查顺序，看能不能在三步内定位。第三个是对照：把易错点那五条当成检查项，每复习完一个模块就过一遍，看有没有中招。

我自己的血泪经验是，最容易被跳过的是主数据那一段。因为它不像定价和交运那样有明确的“流程感”，看起来只是一堆字段，复习时总想快点翻过去。结果每次出问题，绕一圈还是回到这里——客户销售区域没扩、伙伴功能少填、发货单位对不上，全是主数据的事。从那以后我每次碰 SD，都强制自己先把客户主数据的三个段、物料主数据的几个单位、文档类型的几个开关过一遍，再去看流程，速度快很多，也不会在同一个坑里反复翻车。

希望这份清单帮到你，复习的时候少走一点弯路。

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