简介这份PPT面向SAP初学者、SD模块顾问及企业销售与分销业务人员系统梳理销售和分销模块的核心流程与组织架构帮助读者建立从询价报价、订单处理到交运开票的完整认知框架。内容涵盖销售文档类型与功能、定价与可用性检查、客户与物料主数据、业务伙伴角色、销售组织与分销渠道等组织元素并延伸至与MM、PP、FI、CO模块的集成关系及报表控制视图适合作为入门培训或日常业务查阅的参考材料。资源包共1个文件为PPT演示文稿整体约2.09MB以图文页面的形式呈现供应链总览、销售流程总览与组织架构等模块化知识。目前已有106人学习篇幅精炼、结构清晰便于按主题快速定位所需章节适合需要系统了解SAP SD业务逻辑与模块协同关系的读者参考使用。1. 销售和分销到底管什么从一张“跑单”说起你有没有见过这样的场景客户在网上下了一单销售在表格里记一笔仓库在另一个系统里查库存财务月底再对着发票一笔笔对账。单子一多谁都说自己没错可货发错了、价算错了、账对不上最后只能靠人肉翻聊天记录找“后悔药”。SAP SDSales and Distribution销售和分销要解决的就是把这根从客户询价到收款入账的链条收进同一套系统里跑。通俗地说SD 是 ERP 里专门管“卖东西”的那一段询价、报价、销售订单、交运、发货、开票一路到财务记账。它不只是一个开单工具而是把销售组织、分销渠道、客户主数据、物料主数据、定价条件、库存与生产需求串成一条有文档流可追溯的线。搞懂它你就明白企业里“一张订单背后到底经过了多少道手”也更容易看懂那些销售、仓库、财务之间反复扯皮的根源。2. 为什么销售流程需要一套系统从报价到收款的链条逻辑2.1 一张订单不是孤立动作而是一串前后咬合的文档很多初学者以为销售就是“填一张订单”但在 SD 的视角里订单只是链条中间的一环。前面有询价Inquiry和报价Quotation后面有交运Delivery、发货过账Goods Issue、开票Billing再往后是应收账款。每一环都生成自己的文档并且和前后文档建立链接这就是常说的“文档流”。打个比方这就像寄快递你先问能不能寄、多少钱询价/报价然后下单销售订单快递员上门取件交运包裹出仓发货最后给你一张运单和发票开票。如果每一步都记在不同本子上丢件了根本查不清而 SD 把这些步骤串成一条链点开任意一张单据都能往前追到订单、往后看到发票。这种链接带来的直接好处是可追溯。客户说“我订的是蓝色那款”你可以从发票倒查到交运、订单、报价确认当初谈的是什么。系统里文档类型也对应不同交易标准订单、退货、借项/贷项凭证请求、合同、交货协议、询价、报价各有各的编号和流程。文档类型不是随便选的它决定了这张单会触发哪些功能、走哪条处理路径。2.2 定价不是手填数字而是条件技术的组合结果销售里最容易翻车的地方之一就是价格。SD 的定价不是让销售在订单里敲一个数而是由“条件技术”算出来的。系统里维护各种条件记录客户、物料、价格组、物料定价组、客户/物料定价组、价格清单、运费、税、付款条件等订单创建时按优先级逐层去找找到就套用。可以把它想成叠优惠券先看有没有客户专属价再看物料基础价再看数量折扣、附加费最后加税和运费。哪一层生效、哪一层被覆盖取决于条件表的顺序和存取顺序。原文里列出的价格条件组、折扣/附加费、国际付款条件、离港国/目的国等都是这套组合的输入项。提示定价出问题先别急着改订单金额去查条件记录有没有维护、有效期对不对、存取顺序有没有被别的条件抢先命中。手改价格只是把错误藏起来下次还会犯。2.3 交运和开票库存、信用与财务在这里交汇订单确认之后SD 要把需求传下去。如果货在仓库就走交运到期交运清单、拣配、包装、发货过账。发货过账这一步影响很大——减少仓库库存、按金额更新库存科目、减少交运需求、更新文档流、为发票创建工作清单。也就是说仓库动一下财务账上跟着动。如果货不在手边SD 会把需求传给生产或采购MRP 跑出采购申请、生产订单供应商自动产生车间控制接上。这就是原文里供应链总览那条线销售订单 → 需求传递 → 采购/生产 → 收货 → 交运 → 开票。开票也不是随便开一张纸。发票类型分标准发票、取消发票、公司间发票、退货、贷项/借项凭证、现金销售、形式发票等不同发票类型对应不同的会计过账。SD 与 FI财务会计、CO成本控制集成销售收入、销售成本、应收款都在这里落账。信用检查、可用性检查也在订单和交运环节卡口避免货发了钱收不回来。3. 组织架构和主数据SD 为什么先要“搭架子”3.1 销售组织、分销渠道、部门三个维度切出一笔业务SD 的组织架构不是摆设它决定了“这笔生意归谁管、走哪条路、算哪个部门的业绩”。核心三件套是销售组织、分销渠道、产品组部门。销售组织代表负责某个市场或产品线的销售单位分销渠道代表货怎么卖出去比如直销、经销、线上部门则按产品线或业务类型再切一刀。原文里还提到销售办公室、销售小组、工厂、库位、公司代码、业务范围。可以这样理解销售组织是“谁在卖”分销渠道是“通过什么方式卖”部门是“卖的是哪一类”。三者组合成销售区域订单挂在这个区域下后续的交运工厂、开票公司代码才有依据。架子搭错了后面定价、交运、开票都会跟着错位。3.2 客户主数据和物料主数据一张单背后的两本“档案”客户主数据分通用数据、公司级数据、销售区域数据几层地址、联系方式、银行信息是通用的付款条件、科目管理是公司级的销售区域里则放销售员工、转运代理、联系人以及售达方、交运方、付款方、开票方这些业务伙伴角色。同一个客户在不同角色下可以是不同主体比如下单的是总部收货的是分厂付款的是财务公司。物料主数据同样分视图基本计量单位、销售单位、包装单位最小订单量、最小交货量、交货单位。原文举例里基本单位是件销售单位可能是箱托盘又是另一层最小订单 60 件、最小交货 60 件、交货单位 4 件——这些数字直接决定订单能不能下、交运怎么拆。客户-物料信息记录则把“这个客户买这个物料”的额外信息单独存一份比如客户物料编码、部分交货设置。注意很多“订单下不了”“交运数量不对”的问题根子不在订单本身而在主数据的单位换算和最小量设置。先查档案再查单据。3.3 业务伙伴角色一笔交易里可能站着四个“客户”SD 里最容易让人懵的概念之一是一笔交易里客户可以扮演多个角色售达方谁买的、交运方货发给谁、付款方谁付钱、开票方发票开给谁。这四个角色可以是同一个客户也可以是不同主体。系统通过业务伙伴功能把这些角色挂到单据上强制要求的角色没维护单据就卡住。这种设计不是为了复杂而复杂而是贴合真实业务集团采购、分散收货、集中付款很常见。理解这一点再看客户主数据里的“合作伙伴”页签就不会觉得那是一堆重复字段而是同一笔生意的不同责任方。4. 常见误区与易混概念别把 SD 当成“开票软件”4.1 误区一SD 就是销售开单和库存、生产没关系易混点很多人以为 SD 只负责录订单库存是仓库的事生产是车间的事。为什么混因为日常接触到的只是销售界面看不到背后的需求传递。怎么区分SD 的订单确认后会触发可用性检查需求传给 MRP 和 PP缺货时自动产生采购申请或生产订单交运发货又直接减少库存、更新财务科目。它是一条链的起点不是孤立的开单窗口。4.2 误区二报价单和销售订单是一回事易混点询价、报价、销售订单看起来都是“记一笔客户要买什么”。为什么混文档长得像字段也相似。怎么区分询价和报价是售前文档通常不触发交运和开票销售订单才是真正推动后续流程的关键文档会触发定价、可用性检查、需求传递、交运。文档类型不同系统触发的功能也不同不能拿报价单当订单用。4.3 误区三发票金额可以随手改反正财务能调易混点订单价格不对直接在开票时改个数字。为什么混开票界面确实能改。怎么区分SD 的发票基于订单和交运生成价格来自条件技术手改会切断文档流和定价依据导致收入、成本、应收对不上。正确做法是回头查条件记录、订单定价而不是在发票上打补丁。4.4 误区四发货过账只是“货出去了”跟账无关易混点仓库觉得发货就是扫个码、出个门。为什么混动作发生在仓库感觉和财务很远。怎么区分发货过账会减少库存、按金额更新库存科目、减少交运需求、更新文档流、为发票创建工作清单。它是销售和财务之间的关键过账点发错时间、发错数量账上立刻有反应。4.5 误区五客户主数据填一次就永远不用管易混点客户档案建完就放着。为什么混地址、联系人看起来不常变。怎么区分付款条件、信用限额、销售区域数据、业务伙伴角色都会影响订单能不能下、能不能发货、发票开给谁。主数据是活的销售组织调整、客户主体变更都要回头维护否则单据会在意想不到的地方卡住。5. 什么时候用、什么时候别用把 SD 放回它该在的位置5.1 适合用的场景交易频繁、角色多、要追溯SD 真正发挥价值是在销售链条长、参与方多、需要前后追溯的场景里。比如一家公司有多个销售组织、多条分销渠道客户分售达方、交运方、付款方、开票方订单要触发库存检查、信用检查、生产或采购需求发货后还要和财务对账。这种时候文档流和集成就是刚需手工表格根本兜不住。再比如退货、借项/贷项凭证、公司间发票、现金销售这些非标准交易SD 用不同文档类型和发票类型来区分处理比在表格里加备注靠谱得多。定价条件技术也能把客户价、物料价、折扣、附加费、税、运费分层管理减少“拍脑袋报价”。5.2 不适合硬上的场景业务极简、链条很短反过来如果业务就是一个小团队卖少数几种货客户和价格都很稳定没有复杂的组织架构和角色分工硬上一套完整 SD 反而增加负担。主数据要维护、组织架构要搭、条件记录要配这些前期成本需要交易量来摊薄。业务极简时轻量工具加清晰的对账习惯可能比大系统更顺手。还有一种情况要谨慎流程还没想清楚就急着上系统。SD 的文档类型、定价顺序、交运路径都依赖业务规则规则本身模糊系统只会把模糊放大。先把“谁卖、卖给谁、怎么定价、货怎么走、票怎么开”这几件事定下来再谈配置。判断维度适合用 SD不建议硬上交易频率高频、多角色低频、单人可处理组织复杂度多销售组织/渠道单一主体追溯要求需要文档流审计口头对账即可集成需求与库存、生产、财务联动链条很短5.3 一个具体例子退货单为什么不能当新订单处理假设客户退了一批货。新手容易直接开一张新销售订单数量填负数觉得“负负得正”。但在 SD 里退货有专门的文档类型和后续流程退货单触发收货、贷项凭证库存回补和财务冲销走各自的过账逻辑。拿标准订单硬套文档流断了库存和应收都对不上月底对账就是一场血泪经验。正确路径是选退货文档类型关联原订单或发票让系统按退货流程走收货和贷项。这样发票、交运、订单之间的链接还在查起来有据可依。类似地借项/贷项凭证请求、公司间发票、形式发票也各有各的用途不能混用。提示遇到“这笔业务该用哪种文档类型”拿不准时先问一句“它要不要触发交运、要不要触发开票、要不要冲原单”答案基本就出来了。我自己的习惯是每次碰到销售单据对不上先不急着改数而是把文档流从头到尾走一遍订单挂的销售区域对不对、客户角色全不全、条件记录命中了哪一层、交运和发货过账时间是否匹配。这套动作走顺了很多所谓的玄学问题其实都是某一环的主数据或文档类型选错了。希望这份整理能帮到你遇到 SD 里的名词不再发懵。本文还有配套的精品资源点击获取 
长河君 · 2026/11/3 12:55:57 · 阅读 1.2k SAP SD销售与分销模块详解：从订单到收款的完整流程与核心概念
简介这份PPT面向SAP初学者、SD模块顾问及企业销售与分销业务人员系统梳理销售和分销模块的核心流程与组织架构帮助读者建立从询价报价、订单处理到交运开票的完整认知框架。内容涵盖销售文档类型与功能、定价与可用性检查、客户与物料主数据、业务伙伴角色、销售组织与分销渠道等组织元素并延伸至与MM、PP、FI、CO模块的集成关系及报表控制视图适合作为入门培训或日常业务查阅的参考材料。资源包共1个文件为PPT演示文稿整体约2.09MB以图文页面的形式呈现供应链总览、销售流程总览与组织架构等模块化知识。目前已有106人学习篇幅精炼、结构清晰便于按主题快速定位所需章节适合需要系统了解SAP SD业务逻辑与模块协同关系的读者参考使用。1. 销售和分销到底管什么从一张“跑单”说起你有没有见过这样的场景客户在网上下了一单销售在表格里记一笔仓库在另一个系统里查库存财务月底再对着发票一笔笔对账。单子一多谁都说自己没错可货发错了、价算错了、账对不上最后只能靠人肉翻聊天记录找“后悔药”。SAP SDSales and Distribution销售和分销要解决的就是把这根从客户询价到收款入账的链条收进同一套系统里跑。通俗地说SD 是 ERP 里专门管“卖东西”的那一段询价、报价、销售订单、交运、发货、开票一路到财务记账。它不只是一个开单工具而是把销售组织、分销渠道、客户主数据、物料主数据、定价条件、库存与生产需求串成一条有文档流可追溯的线。搞懂它你就明白企业里“一张订单背后到底经过了多少道手”也更容易看懂那些销售、仓库、财务之间反复扯皮的根源。2. 为什么销售流程需要一套系统从报价到收款的链条逻辑2.1 一张订单不是孤立动作而是一串前后咬合的文档很多初学者以为销售就是“填一张订单”但在 SD 的视角里订单只是链条中间的一环。前面有询价Inquiry和报价Quotation后面有交运Delivery、发货过账Goods Issue、开票Billing再往后是应收账款。每一环都生成自己的文档并且和前后文档建立链接这就是常说的“文档流”。打个比方这就像寄快递你先问能不能寄、多少钱询价/报价然后下单销售订单快递员上门取件交运包裹出仓发货最后给你一张运单和发票开票。如果每一步都记在不同本子上丢件了根本查不清而 SD 把这些步骤串成一条链点开任意一张单据都能往前追到订单、往后看到发票。这种链接带来的直接好处是可追溯。客户说“我订的是蓝色那款”你可以从发票倒查到交运、订单、报价确认当初谈的是什么。系统里文档类型也对应不同交易标准订单、退货、借项/贷项凭证请求、合同、交货协议、询价、报价各有各的编号和流程。文档类型不是随便选的它决定了这张单会触发哪些功能、走哪条处理路径。2.2 定价不是手填数字而是条件技术的组合结果销售里最容易翻车的地方之一就是价格。SD 的定价不是让销售在订单里敲一个数而是由“条件技术”算出来的。系统里维护各种条件记录客户、物料、价格组、物料定价组、客户/物料定价组、价格清单、运费、税、付款条件等订单创建时按优先级逐层去找找到就套用。可以把它想成叠优惠券先看有没有客户专属价再看物料基础价再看数量折扣、附加费最后加税和运费。哪一层生效、哪一层被覆盖取决于条件表的顺序和存取顺序。原文里列出的价格条件组、折扣/附加费、国际付款条件、离港国/目的国等都是这套组合的输入项。提示定价出问题先别急着改订单金额去查条件记录有没有维护、有效期对不对、存取顺序有没有被别的条件抢先命中。手改价格只是把错误藏起来下次还会犯。2.3 交运和开票库存、信用与财务在这里交汇订单确认之后SD 要把需求传下去。如果货在仓库就走交运到期交运清单、拣配、包装、发货过账。发货过账这一步影响很大——减少仓库库存、按金额更新库存科目、减少交运需求、更新文档流、为发票创建工作清单。也就是说仓库动一下财务账上跟着动。如果货不在手边SD 会把需求传给生产或采购MRP 跑出采购申请、生产订单供应商自动产生车间控制接上。这就是原文里供应链总览那条线销售订单 → 需求传递 → 采购/生产 → 收货 → 交运 → 开票。开票也不是随便开一张纸。发票类型分标准发票、取消发票、公司间发票、退货、贷项/借项凭证、现金销售、形式发票等不同发票类型对应不同的会计过账。SD 与 FI财务会计、CO成本控制集成销售收入、销售成本、应收款都在这里落账。信用检查、可用性检查也在订单和交运环节卡口避免货发了钱收不回来。3. 组织架构和主数据SD 为什么先要“搭架子”3.1 销售组织、分销渠道、部门三个维度切出一笔业务SD 的组织架构不是摆设它决定了“这笔生意归谁管、走哪条路、算哪个部门的业绩”。核心三件套是销售组织、分销渠道、产品组部门。销售组织代表负责某个市场或产品线的销售单位分销渠道代表货怎么卖出去比如直销、经销、线上部门则按产品线或业务类型再切一刀。原文里还提到销售办公室、销售小组、工厂、库位、公司代码、业务范围。可以这样理解销售组织是“谁在卖”分销渠道是“通过什么方式卖”部门是“卖的是哪一类”。三者组合成销售区域订单挂在这个区域下后续的交运工厂、开票公司代码才有依据。架子搭错了后面定价、交运、开票都会跟着错位。3.2 客户主数据和物料主数据一张单背后的两本“档案”客户主数据分通用数据、公司级数据、销售区域数据几层地址、联系方式、银行信息是通用的付款条件、科目管理是公司级的销售区域里则放销售员工、转运代理、联系人以及售达方、交运方、付款方、开票方这些业务伙伴角色。同一个客户在不同角色下可以是不同主体比如下单的是总部收货的是分厂付款的是财务公司。物料主数据同样分视图基本计量单位、销售单位、包装单位最小订单量、最小交货量、交货单位。原文举例里基本单位是件销售单位可能是箱托盘又是另一层最小订单 60 件、最小交货 60 件、交货单位 4 件——这些数字直接决定订单能不能下、交运怎么拆。客户-物料信息记录则把“这个客户买这个物料”的额外信息单独存一份比如客户物料编码、部分交货设置。注意很多“订单下不了”“交运数量不对”的问题根子不在订单本身而在主数据的单位换算和最小量设置。先查档案再查单据。3.3 业务伙伴角色一笔交易里可能站着四个“客户”SD 里最容易让人懵的概念之一是一笔交易里客户可以扮演多个角色售达方谁买的、交运方货发给谁、付款方谁付钱、开票方发票开给谁。这四个角色可以是同一个客户也可以是不同主体。系统通过业务伙伴功能把这些角色挂到单据上强制要求的角色没维护单据就卡住。这种设计不是为了复杂而复杂而是贴合真实业务集团采购、分散收货、集中付款很常见。理解这一点再看客户主数据里的“合作伙伴”页签就不会觉得那是一堆重复字段而是同一笔生意的不同责任方。4. 常见误区与易混概念别把 SD 当成“开票软件”4.1 误区一SD 就是销售开单和库存、生产没关系易混点很多人以为 SD 只负责录订单库存是仓库的事生产是车间的事。为什么混因为日常接触到的只是销售界面看不到背后的需求传递。怎么区分SD 的订单确认后会触发可用性检查需求传给 MRP 和 PP缺货时自动产生采购申请或生产订单交运发货又直接减少库存、更新财务科目。它是一条链的起点不是孤立的开单窗口。4.2 误区二报价单和销售订单是一回事易混点询价、报价、销售订单看起来都是“记一笔客户要买什么”。为什么混文档长得像字段也相似。怎么区分询价和报价是售前文档通常不触发交运和开票销售订单才是真正推动后续流程的关键文档会触发定价、可用性检查、需求传递、交运。文档类型不同系统触发的功能也不同不能拿报价单当订单用。4.3 误区三发票金额可以随手改反正财务能调易混点订单价格不对直接在开票时改个数字。为什么混开票界面确实能改。怎么区分SD 的发票基于订单和交运生成价格来自条件技术手改会切断文档流和定价依据导致收入、成本、应收对不上。正确做法是回头查条件记录、订单定价而不是在发票上打补丁。4.4 误区四发货过账只是“货出去了”跟账无关易混点仓库觉得发货就是扫个码、出个门。为什么混动作发生在仓库感觉和财务很远。怎么区分发货过账会减少库存、按金额更新库存科目、减少交运需求、更新文档流、为发票创建工作清单。它是销售和财务之间的关键过账点发错时间、发错数量账上立刻有反应。4.5 误区五客户主数据填一次就永远不用管易混点客户档案建完就放着。为什么混地址、联系人看起来不常变。怎么区分付款条件、信用限额、销售区域数据、业务伙伴角色都会影响订单能不能下、能不能发货、发票开给谁。主数据是活的销售组织调整、客户主体变更都要回头维护否则单据会在意想不到的地方卡住。5. 什么时候用、什么时候别用把 SD 放回它该在的位置5.1 适合用的场景交易频繁、角色多、要追溯SD 真正发挥价值是在销售链条长、参与方多、需要前后追溯的场景里。比如一家公司有多个销售组织、多条分销渠道客户分售达方、交运方、付款方、开票方订单要触发库存检查、信用检查、生产或采购需求发货后还要和财务对账。这种时候文档流和集成就是刚需手工表格根本兜不住。再比如退货、借项/贷项凭证、公司间发票、现金销售这些非标准交易SD 用不同文档类型和发票类型来区分处理比在表格里加备注靠谱得多。定价条件技术也能把客户价、物料价、折扣、附加费、税、运费分层管理减少“拍脑袋报价”。5.2 不适合硬上的场景业务极简、链条很短反过来如果业务就是一个小团队卖少数几种货客户和价格都很稳定没有复杂的组织架构和角色分工硬上一套完整 SD 反而增加负担。主数据要维护、组织架构要搭、条件记录要配这些前期成本需要交易量来摊薄。业务极简时轻量工具加清晰的对账习惯可能比大系统更顺手。还有一种情况要谨慎流程还没想清楚就急着上系统。SD 的文档类型、定价顺序、交运路径都依赖业务规则规则本身模糊系统只会把模糊放大。先把“谁卖、卖给谁、怎么定价、货怎么走、票怎么开”这几件事定下来再谈配置。判断维度适合用 SD不建议硬上交易频率高频、多角色低频、单人可处理组织复杂度多销售组织/渠道单一主体追溯要求需要文档流审计口头对账即可集成需求与库存、生产、财务联动链条很短5.3 一个具体例子退货单为什么不能当新订单处理假设客户退了一批货。新手容易直接开一张新销售订单数量填负数觉得“负负得正”。但在 SD 里退货有专门的文档类型和后续流程退货单触发收货、贷项凭证库存回补和财务冲销走各自的过账逻辑。拿标准订单硬套文档流断了库存和应收都对不上月底对账就是一场血泪经验。正确路径是选退货文档类型关联原订单或发票让系统按退货流程走收货和贷项。这样发票、交运、订单之间的链接还在查起来有据可依。类似地借项/贷项凭证请求、公司间发票、形式发票也各有各的用途不能混用。提示遇到“这笔业务该用哪种文档类型”拿不准时先问一句“它要不要触发交运、要不要触发开票、要不要冲原单”答案基本就出来了。我自己的习惯是每次碰到销售单据对不上先不急着改数而是把文档流从头到尾走一遍订单挂的销售区域对不对、客户角色全不全、条件记录命中了哪一层、交运和发货过账时间是否匹配。这套动作走顺了很多所谓的玄学问题其实都是某一环的主数据或文档类型选错了。希望这份整理能帮到你遇到 SD 里的名词不再发懵。本文还有配套的精品资源点击获取