SAP SD：它管什么，实施又在哪里出问题

SAP SD（销售与分销）在SAP中运行订单到收款：报价、销售订单、交货、开票，以及向财务的交接。在S/4HANA上，它的变化会影响项目范围。客户变成业务伙伴，信用管理转到SAP Credit Management，返利转到条件合同，开票直接过账到通用日记账（Universal Journal）。这篇指南写给销售运营负责人、财务主管和项目经理，帮助他们了解SD做什么、在哪里出问题。第二个问题的简短答案是：客户主数据、定价条件、可用性检查和科目确定。上线前，用真实数据把这四项都测一遍。

在一次完整的SAP实施之后的推广中，订单到收款的各个步骤都完全按设计搭建。在流程图上看起来没有问题。没有人核实过生产环节的库存更新是怎么传过来的。

销售告诉客户5天。制造部门清楚，实际更接近10天。

这个落差带来的损失不止是交货延迟。它损害了信任，而信任比一项配置设置更难重建。

SD处在物流链的最前端。它通过一串凭证，把客户的兴趣变成发票：

1. 询价：客户询问价格或可供货情况
2. 报价单：带有效期的正式价格和交货报价
3. 销售订单：客户确认下单，运行可用性检查并确认交货日期
4. 交货：仓库拣货、打包；发货过账减少库存
5. 开票：创建发票及其会计凭证
6. 收款：财务把收到的付款与未清项清账

每张凭证都引用前一张。正是这条凭证流让订单到收款可追溯。链条干净，您就能把每张发票追溯到最初的请求。如果凭证乱序创建或被绕过，报表就会出错，随之而来的是争议。

1. 01询价询问价格或可供货情况
2. 02报价单带有效日期的正式报价
3. 03销售订单可用性检查确认日期
4. 04交货拣货、打包、发货过账
5. 05开票发票和会计凭证
6. 06收款财务对未清项清账

每张发票都能追溯到最初的请求

做得好，这条链就能消除手工交接。一家制造业客户在SD上线后，把订单到收款周期缩短了40%，主要是消除了销售、仓库和财务之间的交接。

销售订单与可用性检查

销售订单处理是SD配置工作量最集中的地方：订单类型、项目类别、计划行和可用性检查。

可承诺量（ATP）是对业务最关键的部分。它根据库存、计划收货和已有承诺，检查所要求的日期能否满足。配置得当，销售告诉客户的就是系统真正能承诺的。配置不当，销售告诉客户的只是自己希望能交付的。

在开头提到的那次推广中，没有人核实过生产环节的库存更新是怎么传过来的。销售报出的日期，工厂做不到。

定价与条件

定价是SD中最容易被低估的设置。在第一次发票争议之前，它看起来很简单。

SD的条件技术处理基础价格、客户折扣、数量阶梯、附加费、运费和税。每个要素是一个带访问顺序的条件类型，条件记录存放具体数值。

我见得最多的定价问题：上线时设定的旧定价条件从没更新过。业务重新谈了折扣，没人更新SD里的条件记录，发票就错了，争议落到应收账款头上。

定价治理是流程决策，不是配置决策。必须有人负责条件记录的维护。

装运

交货处理涵盖拣货、打包和发货过账。发货过账是关键事件：它过账库存减少，把交货放入开票到期清单，并记录实际交货日期。装运点和路线确定控制交货如何创建。分销网络复杂的公司，会用SAP Transportation Management（TM）来扩展这一块。

开票、科目确定与税

开票把交货变成发票，并创建会计凭证。科目确定依据销售组织、客户和物料的科目分配组以及条件类型，把每个开票项目映射到收入、税和其他总账科目。一旦出错，发票就会过账到错误的科目，财务到月结时才会发现。

税务确定同样脆弱。它取决于客户的税务分类、物料的税务分类，以及发货国家或辖区。不匹配，可能让应税销售开出零税发票，也可能给免税销售加了税。

信用管理

信用检查会拦截或标记那些会让客户超出信用额度的订单。它只有在额度得到维护时才有用。上线时设定的静态额度，会随着付款行为和业务量的变化而失去意义。

当额度低于客户的正常订单规模时，每一笔订单都会被自动冻结。销售团队于是学会了释放冻结，而不是申请复核额度。

那不是信用管理。那是变通做法。

以下是SD的结构要素，以及各自关联的对象。

结构要素	在SAP SD中的用途	关键关联
销售组织	最高层的销售单元，负责销售条款和责任	分配给FI中的公司代码
分销渠道	产品触达客户的方式（批发、零售、直销）	控制定价、主数据和合作伙伴确定
产品组	销售组织内的产品分组	用于报表和输出的物料分组
销售范围	销售组织、分销渠道和产品组的组合	每张销售凭证和每条客户记录都需要
销售办事处	按地理划分的销售单元	区域报表和合作伙伴确定
销售组	销售办事处内的团队	订单上的负责人
装运点	货物发出的地点	把SD与仓库管理和运输联系起来
工厂	生产或供应单元	库存来源，与装运点关联

销售范围是实际运作的单元。客户销售数据按销售范围维护，每张销售凭证也都在某个销售范围内创建。许多迁移在这里栽跟头：无法清晰映射到销售范围的遗留客户记录，在加载之前需要认真准备。

如果您正从ECC迁移，以下是需要纳入范围的SD变化。SAP在其S/4HANA文档中把这一领域归在“Sales”之下，不过大多数团队仍然称它为SD。

ECCS/4HANA

客户ECC客户主记录S/4HANA带客户角色的业务伙伴

信用管理ECCFI-AR-CRS/4HANASAP Credit Management (FIN-FSCM-CR)，必须采用

返利ECCSD返利处理，依据索引重建S/4HANASettlement Management中的条件合同

可用性检查ECC基本产品可用性检查S/4HANA高级ATP：分配、缺货订单、替代工厂

开票ECCFI和CO分别对账S/4HANA通用日记账（ACDOCA）中的一个行项目

收入确认ECC许多项目采用自定义递延逻辑S/4HANASAP Revenue Accounting and Reporting，单独授权

1. 客户成为业务伙伴。 客户主数据通过带客户角色的业务伙伴来维护。在转换中，必须在转换运行之前设置好客户-供应商集成。
2. 信用管理转到SAP Credit Management。 ECC的信用管理（FI-AR-CR）在S/4HANA中不再提供。SAP Credit Management（FIN-FSCM-CR）是它的替代，因此转换必须迁移信用数据和设置。这不是可选项。
3. 返利转到条件合同。 传统的SD返利处理被Settlement Management（条件合同管理）取代。返利条件即时生效，而不必依据索引重建。
4. 高级ATP。 S/4HANA的高级ATP增加了产品分配、缺货订单处理、跨工厂的基于替代方案的确认、释放交货和供应分配。在S/4HANA Cloud中，这些功能属于标准许可。本地部署一旦启用，则需要单独的许可。
5. 开票过账到通用日记账。 FI、CO和盈利分析共用ACDOCA中的同一个行项目，省去了ECC中FI与CO的对账工作。代价是：科目确定出错，会立刻过账到错误的科目，在行项目层面一目了然。
6. 收入确认。 对于IFRS 15下的多要素合同、订阅或长期服务，SAP Revenue Accounting and Reporting取代了许多ECC项目自建的递延逻辑。它需要单独授权，并且要在上线前设计好，而不是等到年底才发现。

Clean Core改变了SD定制的处理方式。在公有云上，不可能在核心中写自定义代码。在私有云和本地部署上可以，但会让每一次升级都更困难。大多数旧的定价Z例程，都可以用标准条件类型、公式和BAdI取代。真正剩下的部分，应放在SAP BTP上的并行扩展中。我的Clean Core指南谈到了这个决策。

SD与MM

可用性检查从MM读取库存，发货过账则过账库存移动。如果库存数据有误，ATP的结果就不可靠。如果因为库存实际并不在装运点而导致发货过账失败，交货就无法完成，开票也会停滞。通过主数据和纪律让两边保持一致：不要绕过标准过账去手工调整库存。

SD与PP

在按订单生产的场景中，销售订单可以直接驱动生产，因此确认的日期是有生产订单支撑的承诺。物料主数据中的策略组控制销售订单和预测如何相互作用。设错了，它们会叠加而不是相互冲抵，计划运行就会高估需求，随之而来的是生产过剩。我的SAP PP指南谈了计划这一侧。

SD与FI

开票凭证就是接口。每张发票都会创建一张会计凭证，把收入、税和客户未清项过账到通用日记账。客户主数据中的付款条件决定到期日。销售谈了条款却没告诉财务，系统执行的就是财务从未同意的条款。

如果SD设计把所有收入都视为在开票时确认，而合同另有约定，事后改造的代价很高。在设计签字确认之前，先和财务就收入确认达成一致。关于集成中财务这一侧，请看我的SAP FICO指南。

四个故障点造成了上线后大部分的麻烦。

客户主数据没准备好。 每个字段在下游都有影响。缺少税务分类，意味着税算错。缺少付款条件，意味着FI无法计算到期日。缺少装运条件，会让交货排程出错。数据量比计划假设的更大，源数据比假设的更差，而且清理需要业务来做决定。要早开始，把它当作业务工作流，而不是技术加载。我那篇SAP数据迁移为何失败谈了方法。

定价条件没人维护。 上线时的条件如果没人复核，一年之内就会变成发票争议。

可用性检查与现实脱节。 ATP读取的数据过时，就会做出业务无法兑现的承诺。要用真实的生产和库存场景去验证，而不是单元测试中用的那种干净的测试数据。

科目确定的缺口在上线后才被发现。 要用实际的会计科目表、税码和物料组来测试。税码不匹配，可能会拦住订单，或者在有人弄清问题之前就引发发票争议。

下表是我会在UAT签字确认之前逐项过一遍的清单。

风险	影响	缓解措施
客户主数据不完整	发票错误、交货失败、FI过账缺口	尽早启动数据工作流；迁移前按销售范围定义必填字段
定价条件过时	发票争议、收入不正确	在上线时指定条件记录负责人和复核周期
ATP与PP或MM脱节	交货承诺不可靠	UAT签字确认前，用真实的计划场景测试ATP
科目确定存在缺口	收入过账到错误的科目	用真实的会计科目表和完整的税码集来测试
把释放信用冻结当作例行操作	敞口失控、应收账款争议	强制执行额度复核；在头90天跟踪手工释放
输出未经测试	发票和交货单不能自动发出	上线前用真实的打印和邮件路由测试每一种输出类型
付款条件不一致	到期日错误、现金预测出错	加载客户数据前，先在销售和财务之间约定条款

如果销售团队习惯性地释放信用冻结，而不是申请复核，就在头90天内解决，趁习惯还没养成。

什么是SAP SD，它做什么？

SAP SD（销售与分销）管理订单到收款：询价、报价、销售订单、交货、开票，以及向财务会计的交接。它的凭证流把每一步与前一步关联起来，因此每张发票都能追溯到最初的订单。它与MM集成，处理库存和发货过账；与PP集成，处理按订单生产和可用性；与FI集成，处理收入、税和应收账款。

SAP SD的组织结构是怎样的？

实际运作的单元是销售范围：销售组织、分销渠道和产品组的组合。每张销售凭证都在某个销售范围内创建，客户销售数据也按销售范围维护。销售办事处和销售组位于其下，用于报表和责任划分。在物流一侧，装运点和工厂决定货物从哪里发出。在加载客户数据之前，要把结构定对，因为之后再改就意味着重新加载数据。

SAP SD中的定价是如何运作的？

定价采用条件技术。每个价格要素是一个条件类型，由访问顺序决定适用哪条条件记录，再由定价过程按顺序组合各个条件类型。大多数定价争议，追根溯源是商务条款变更时条件记录没有更新，而不是配置错误。

SAP S/4HANA中的高级ATP是什么？

高级可承诺量（aATP）是S/4HANA的可用性检查。在基本产品可用性检查之外，它增加了产品分配、缺货订单处理、跨工厂的基于替代方案的确认、释放交货和供应分配。这些功能包含在S/4HANA Cloud中，在本地部署上一旦启用，需要单独的许可。供应受限或分配规则重要的地方，适合使用。对于供应稳定的供应链，配置得当的基本检查往往就够了。

SAP SD如何与财务会计集成？

通过开票凭证。把开票凭证释放到会计，会生成一张记录收入、税和客户未清项的日记账分录。科目确定依据销售组织、科目分配组和条件类型来决定总账科目。税取决于客户和物料的税务分类。客户主数据中的付款条件设定到期日。对于IFRS 15的情形，SAP Revenue Accounting and Reporting会在一段时间内递延并确认收入。

从ECC迁移到S/4HANA时，SAP SD有哪些变化？

客户成为业务伙伴。信用管理从FI-AR-CR转到SAP Credit Management，这是强制性的。返利处理被Settlement Management中的条件合同取代。高级ATP可用，开票过账到通用日记账。要尽早把这些全部纳入范围，因为每一项都需要配置、数据迁移和测试。

SAP SD实施中最常见的错误有哪些？

有五个反复出现。低估客户主数据。上线后让定价条件无人负责。只用干净的数据测试ATP。用简化的数据测试科目确定。没有端到端测试输出。最后一个很容易被忽略。发票不能自动发出时，就有人开始手工打印，这种变通做法就会变成常态。