很多新手第一次接触 SAP 销售和分销(SD)模块的配置,面对 SPRO 里一长串的 IMG 节点,往往不知道从哪儿下手。有人一上来就去配销售凭证类型,结果主数据和组织架构还没搭好,后面全部返工;有人照着网上教程把销售组织、分销渠道都定义了,却不清楚这些配置之间到底是什么关系,业务跑起来才发现单据流断在半路。这篇文章就把 SD 模块基础配置拆成组织架构、主数据、销售凭证与流程控制三大核心板块,按实际项目的配置顺序逐步走一遍,每条路径都是基于 SPRO 事务码的标准配置路径。目标是让刚入行的 SD 顾问、内部关键用户,以及独立负责小项目实施的顾问,看完之后能照着在自己的系统里把地基打牢。
SD 模块本质上管的是从客户询价、报价、销售订单,到发货、开票、收款跟踪这一整条订单到现金的链路。配置是这一切业务操作的前提,配置错了,后续所有单据都跟着错;配置全了,业务流转才会顺畅。下面这些内容,都是我在实际项目里一步步踩过、调过、验证过的经验,不是那种只能在 PPT 里看的漂亮话。
1. 配置思路拆解:为什么一定是这个顺序
1.1 三大板块的依赖关系
先讲清楚一个底层逻辑:SD 的配置不是零散的开关设置,而是一张互相咬合的网。组织架构决定了“谁在做生意”,也就是公司内部哪个销售组织、走哪个渠道、卖哪个产品线;主数据解决了“跟谁做生意、卖什么东西”,也就是客户是谁、卖什么物料、什么价格和条件;销售凭证与流程控制则管的是“生意怎么做”,从订单类型到项目类别,再到交货、开票整套单据流的串联规则。
这三者有严格的先后依赖。没有组织架构,主数据无处挂靠——客户主数据要维护在销售范围(销售组织+分销渠道+产品组)下,物料主数据也需要指定销售组织、分销渠道和产品组才能维护销售视图。没有主数据,销售凭证就是空壳——销售订单至少要输入客户和物料,而客户和物料的基础信息、定价条件、可用量检查都依赖主数据配置。没有销售凭证类型和流程控制,即使有了客户和物料,也无法生成订单,订单之后也不能生成交货单、开票凭证。
所以正确顺序必须是:先完成企业结构和基础数据的全局配置,再配置客户和物料主数据的前置参数,最后才去定义销售凭证、项目类别、计划行、交货和开票的相关控制。我自己在项目中见过一个反面案例:某项目组为了赶演示进度,先改了销售凭证类型并扩展复制控制,结果第二天测试订单时发现客户主数据的销售范围层没有维护销售范围,订单还是创建不了。回头补主数据配置,反而拖慢了整体节奏。
1.2 配置前的准备和前置条件
在动手打开 SPRO 之前,有几件事必须先定下来,否则配置过程会反复返工。
首先是业务蓝图。你要从业务部门拿到一堆关键信息:有多少个销售组织?是按区域分还是按产品线分?每个销售组织对应哪些工厂和装运点?分销渠道怎么定,是直销、批发还是线上?产品组是按产品大类还是按品牌划分?这些答案直接决定了组织架构的数量和层级,也决定了后续主数据维护时销售范围的数量。
其次是编码规范。销售组织、分销渠道、产品组、客户账户组、凭证类型、工厂、库位这些对象都要有清晰的编码规则。比如销售组织用 1000、2000 区分不同事业部,分销渠道用 10 直销、20 分销、30 线上,产品组用 01 成品、02 备件、03 服务。如果编码随意,后面查询报表和分析数据时一眼看去全是数字,毫无可读性。
再次是全局设置。比如定义国家、货币、汇率、计量单位等基础数据。这些通常在 Enterprise Structure 和 Global Settings 里完成,看似和 SD 不直接相关,但 SD 单据里到处都要用到。比如装运地址、开票币种、重量单位、体积单位,如果这些基础单位没配好,交货单的拣配和装运过程会乱套。
还有一个项目层面的准备:确认传输请求。SD 配置都是要传的,每个配置项完成后会挂到某个传输请求上。建议在项目开始时把配置任务分拆到不同的传输请求里,比如组织架构相关放在一个请求里,主数据相关放在另一个请求里,凭证流程控制放在独立请求里。这样后期传输到测试机或生产机时,可以按模块分别验证,出问题也好回溯。
2. 组织架构配置:先搭骨架
2.1 定义销售组织、分销渠道与产品组
SD 的组织架构核心就是销售组织、分销渠道和产品组这三个维度。
销售组织是承担销售责任的业务单元,通常对应一个销售大区或一个事业部门,是销售报表和定价控制的最上层维度。定义路径:
企业结构 → 定义 → 销售和分销 → 定义、复制、删除、检查销售组织
进入后选择“定义销售组织”或“复制现有销售组织”。新建时输入销售组织代码(比如 1000)和名称,这个代码会贯穿后续所有单据和主数据,不能随便改。如果集团内已有类似销售组织,也可以用复制功能,复制时可以选择是否复制组织架构相关的分配关系,能省不少事。
分销渠道表示产品到达客户的方式,比如直销、批发、零售、电商。路径:
企业结构 → 定义 → 销售和分销 → 定义、复制、删除、检查分销渠道
产品组用来细分产品线,比如成品、备件、服务或者按品牌划分。路径:
企业结构 → 定义 → 销售和分销 → 定义、复制、删除、检查产品组
这三个对象定义完成后,你会得到一个销售组织的“维度组合”,也就是后面天天挂在嘴边的“销售范围”。简单理解:销售范围 = 销售组织 + 分销渠道 + 产品组。比如某公司销售组织 1000、分销渠道 10、产品组 01,那么 1000/10/01 就是一套销售范围。客户主数据的销售视图、物料主数据的销售视图、定价条件记录,全部是挂在销售范围下的。
2.2 分配关系与销售范围
定义完销售组织、分销渠道、产品组后,必须做分配。不分配,这些对象就是孤岛。
分配路径主要在企业结构 → 分配 → 销售和分销下:
- 给公司代码分配销售组织:这个动作把销售组织和财务上的公司代码绑定,开票时产生的会计凭证才能正确进入对应公司代码的账套。
- 给销售组织分配分销渠道:决定这家销售组织支持哪些分销渠道。
- 给销售组织分配产品组:决定这家销售组织卖哪些产品线。
- 设置销售范围:系统通过维护销售范围这个动作,正式生成可供主数据和单据引用的销售范围记录。
这里面最容易漏的是“设置销售范围”这一步。有些顾问只做了前三个分配,以为销售范围自然就存在了,结果创建客户主数据时,销售范围字段怎么也选不进去,报“没有定义销售范围”。
还要设置销售组织与工厂的分配。SD 的销售订单最终要从某个工厂交货,所以要把工厂和销售组织关联起来。路径:
企业结构 → 分配 → 销售和分销 → 给销售组织分配工厂
注意,一个销售组织可以分配多个工厂,一个工厂也可以分配给多个销售组织。但具体某个物料在某销售范围下可不可以卖,还要看物料主数据里有没有维护相应销售范围的视图。
装运点的定义也不能忽略。装运点是实际进行发货作业的物理地点,比如工厂的成品仓库、码头、配送中心。路径:
企业结构 → 定义 → 后勤 → 装运点 → 定义装运点
定义装运点后,还要建立装运点与工厂/库位的对应关系:
企业结构 → 分配 → 后勤 → 给工厂分配装运点
这样销售订单交货时,系统才能根据工厂和装运点确定规则找到在哪发货。实际项目中见过比较多的坑:销售组织、工厂都配好了,就是忘了给工厂分配装运点,结果创建交货单时报“没有为工厂定义装运点”。这个错不难排查,但对你熟悉常用报错信息的敏感度有要求。
还有一个容易忽略的组织要素是销售办公室、销售组和销售人员。它们挂在销售组织/分销渠道下,主要用于销售报表的统计和团队的业绩归属。路径:
企业结构 → 定义 → 销售和分销 → 维护销售办公室、销售组、销售人员
如果你业务上不需要按销售员分析业绩,这三项可以先不配。但只要后续有人提需求要“按销售员看订单汇总”,你就得回来补上,而且历史数据也只能按当时的组织属性追溯到单笔订单。
组织结构配置完成后,强烈建议做一下“检查”功能。在 SPRO 的每个定义节点里都有“检查”按钮,比如“检查销售组织的完整性”,系统会告诉你哪些分配还没做、哪些销售范围没有定义。我习惯在全部组织架构配完后跑一遍检查,把所有报红的都清掉再往下走。
3. 主数据配置:客户、物料与条件
3.1 客户主数据配置:先定账户组
客户是 SD 业务运转的起点,一切销售行为都需要客户来承接。在 SAP 里创建客户(事务码 XD01),第一步不是直接填客户名称,而是选账户组。账户组本质上决定了这个客户是什么类型——普通客户、一次性客户、员工、关联公司——也决定了客户主数据的编号范围和维护屏幕。
账户组定义路径:
销售和分销 → 主数据 → 业务合作伙伴 → 客户 → 客户主数据 → 准备客户主数据创建 → 定义账户组
创建账户组时,要指定客户编号范围。客户编号范围的定义路径:
销售和分销 → 主数据 → 业务合作伙伴 → 客户 → 客户主数据 → 准备客户主数据创建 → 定义客户账户组的编号范围
这里有个选择:外部编号和内部编号。外部编号是业务上先有编码规则,手工输进去;内部编号则让系统按号码段自动递增。大部分制造企业喜欢外部编号,因为客户编码往往跟 CRM 或其他系统的客户号统一;也有的企业不在乎编码规则,直接用内部编号更省事。无论选哪种,编号范围必须和账户组关联起来,否则创建客户时会报“没有为客户账户组定义编号范围”。
另一个关键配置是屏幕格式。同样是客户主数据,不同类型的客户在屏幕上显示的字段应该不同。比如关联公司客户可能需要维护“统驭科目”和“付款条件”,而普通散户客户不需要;海外客户需要维护“国际贸易条款”和“运输条件”,国内客户则未必。路径:
销售和分销 → 主数据 → 业务合作伙伴 → 客户 → 客户主数据 → 准备客户主数据创建 → 定义客户主数据的屏幕格式
这里要给每个账户组分配字段状态组,把需要隐藏、必输、可选或显示的字段控制好。实际项目中,这一步经常被人忽略,等客户数据录入时才发现屏幕上字段又多又乱,录入效率极低,还得回头调屏幕格式再重新传输。
客户主数据分三个层级:一般数据层、公司代码层、销售范围层。一般数据层存放客户的名称、地址、电话、税号等基础信息;公司代码层存放统驭科目、付款条件、催款程序等财务相关数据;销售范围层存放销售组织相关的数据,比如销售范围、销售办公室、销售组、定价过程、客户定价过程、交货工厂、装运条件等。在配置客户主数据时,还要注意合作伙伴功能的定义,也就是客户里那套“售达方、送达方、收票方、付款方”。售达方是下订单的客户,送达方是收货地点,收票方是收发票的主体,付款方是实际付钱的主体。这四者可以相同,也可以不同,完全由业务决定。路径:
销售和分销 → 主数据 → 业务合作伙伴 → 客户 → 客户主数据 → 销售范围数据 → 定义合作伙伴功能
如果客户存在大量多角贸易或集团内部往来,这个合作伙伴功能配置尤其重要,配不好,开票时发票抬头和收货地址就是错的。
3.2 物料主数据销售视图与客户-物料信息记录
物料主数据里的销售数据,决定了某个物料在某个销售范围内能不能卖、怎么卖。维护路径是事务码 MM01,通过选择“销售视图”并指定销售组织、分销渠道、产品组,进入物料销售数据维护界面。
但物料主数据销售视图能否顺利维护,前提是后台配置了物料类型和行业领域,并定义了物料编号范围。物料类型里有一个重要概念叫“项目类别组”(Item Category Group),这个字段直接决定了销售订单中该项目默认的项目类别。比如成品(FERT)默认项目类别组是 NORM,对应标准项目 TAN;贸易商品(HAWA)可能对应不同项目类别组;服务物料则可能是 TEXT 文本项目。路径:
后勤-常规 → 物料主数据 → 设置关键字段 → 定义物料类型的项目类别组
这个配置看着不起眼,实际影响巨大。我遇到过某项目把所有物料都设成 NORM 项目类别组,结果销售订单里要做免费样品时,项目类别怎么都变不过去,定不了价,交不了货。最后查出来就是项目类别组的配置没细化。
客户-物料信息记录是客户和物料交叉维度的主数据,用于维护特定客户对特定物料的特殊条件,比如最小订购量、特定的交货偏好、客户自己的物料编码。事务码是 VD51。这个信息记录在订单中可以覆盖物料主数据中的默认值,在客户管理比较精细的企业里非常实用。后台没有太多需要配置的,但要在客户主数据里把“客户-物料信息记录”的权限和字段状态开放。
3.3 定价相关主数据配置
定价是主数据板块的重头戏,也是 SD 模块里最容易让人头大的一块。先澄清一点:定价条件记录本身是主数据,比如事物码 VK11 创建价格、折扣、附加费;但让这些条件记录能生效,必须先在后台配置定价过程(Condition Procedure)、定价过程确定,以及条件类型相关的控制。
路径:
销售和分销 → 基本功能 → 定价 → 定价控制 → 定义定价过程
销售和分销 → 基本功能 → 定价 → 定价控制 → 定义定价过程确定
定价过程可以理解成一个计算价格的行项目序列,比如:基础价格 → 客户折扣 → 物料折扣 → 附加费 → 税 → 最终净价。每一行对应一个条件类型(比如 PR00 基础价格、K004 物料折扣、K007 客户折扣、MWST 销项税)。定价过程确定则是把定价过程分配给“销售范围 + 客户定价过程 + 单据定价过程”的组合。
这里有个新手必踩的坑:只做了定价过程,忘了做定价过程确定。结果在销售订单里,价格根本带不出来,或者只能手工改价。排查思路是:用事务码 OVKK 查看定价过程确定上,看看该销售范围+客户定价过程+单据定价过程组合是否匹配,并检查条件记录是否存在。
配置定价过程的几个建议:不要把条件类型一股脑全塞进去,每行要指定访问顺序(Access Sequence),访问顺序决定了系统按什么优先级去查条件记录。比如 PR00 基础价格,通常访问顺序是 01,先查客户/物料特定价格,再查物料组价格,再查通用价格。条件记录建错层级,价格就会按错误顺序被覆盖。这个逻辑多琢磨几次,定价配置就通了一半。
4. 销售凭证与流程控制:单据流转的核心
4.1 销售凭证类型配置:从订单类型开始
销售凭证类型就是你在订单里看到的订单类型,比如 OR 标准订单、TA 现金销售、RE 退货单、FD 框架协议等。这个类型的定义决定了订单头的控制参数:编号范围、合作伙伴确定、定价、交货、开票、文本、项目类别等默认值。
定义路径:
销售和分销 → 销售 → 销售凭证 → 销售凭证头 → 定义销售凭证类型
创建销售凭证类型时要注意几个关键字段:
- 编号范围:每个凭证类型要分配一个编号范围。比如标准订单 OR 用 100000-199999,退货单 RE 用 200000-299999,现金销售 TA 用 500000-599999。路径:
销售和分销 → 销售 → 销售凭证 → 销售凭证头 → 定义销售凭证类型的编号范围
- 合作伙伴确定过程:决定这个订单类型里售达方、送达方、收票方、付款方等合作伙伴的维护方式。标准订单一般要用标准的合作伙伴确定过程,现金销售可能只需要售达方和送达方。
- 定价过程:决定订单采用哪套定价逻辑。不同凭证类型可以用不同定价过程,比如标准订单走完整价格协议,退货单可能不需要价格计算。
- 项目类别:销售凭证类型会影响订单行项目的默认项目类别,但最终项目类别的确定还取决于“项目类别确定”规则。
- 交货和开票:控制该订单类型是否影响交货需求、是否允许开票。比如退货单要考虑是否立即冲销库存、是否需要后续免费补发。
大多数企业会复制标准凭证类型再调整,而不是从零新建。复制时可以带上“复制控制”相关设置,再修改名称和部分参数。直接新建容易漏掉大量默认值,后期莫名其妙出问题。
4.2 项目类别、计划行类别与可用性检查
项目类别(Item Category)是 SD 配置里最需要理清逻辑的一层。它决定了销售订单行项目的行为:是否计库存、是否定价、是否交货、是否开票、是否触发可用性检查。
定义路径:
销售和分销 → 销售 → 销售凭证 → 销售凭证项目 → 定义项目类别
这里要重点理解“项目类别确定”。当你在订单里输入物料和数量后,系统按什么逻辑决定用哪个项目类别?答案是:根据销售凭证类型 + 物料主数据里的项目类别组 + 使用场景(标准业务、返工、免费样品等)来查“项目类别确定表”。
路径:
销售和分销 → 销售 → 销售凭证 → 销售凭证项目 → 项目类别确定 → 定义项目类别确定
举例说明:物料主数据中 A 物料项目类别组是 NORM,销售凭证类型是 OR(标准订单),那么系统默认该项目类别可能是 TAN(标准项目)。如果该物料是免费样品场景,可能系统会选择 TANN(免费项目)或者需要在订单中手工改成 TANN。免费项目在定价过程中不计价,这一点对业务尤其重要——很多企业发样品不计价,但没有正确项目类别,价格带不出来或后续开票时多开了金额。
计划行类别(Schedule Line Category)控制的是物料的交付时间和库存安排。每个项目类别可以对应多个计划行类别,比如“可以按单生产”“从库存发货”“按计划日期分批交付”。路径:
销售和分销 → 销售 → 销售凭证 → 计划行 → 定义计划行类别
计划行类别里有一个关键动作:移动类型。移动类型决定了交货过账时的货物移动,比如标准交货过账用的是 601(销售出库)。如果你配置了错误的移动类型,交货过账时会影响库存账和财务账的准确性。
可用性检查(ATP)则是计划行里很重要的一项控制。它决定系统在检查物料可用量时,是否纳入销售订单需求、计划独立需求、采购订单等。路径:
销售和分销 → 销售 → 销售凭证 → 计划行 → 定义计划行类别 → 配置可用性检查
实际项目里,总会有个别物料明明库存有货,却不满足订单需求日期。多数原因是可用性检查规则设定的检查范围太窄,例如只检查“工厂库存 + 在途采购”,忽略“计划订单备妥数量”,或者可用性检查组在物料主数据里设置错误。
4.3 复制控制:把订单、交货、开票串起来
复制控制(Copy Control)是流程控制里最关键的一环,也是我最想重点讲的一块。SD 的业务流转不是凭空发生的:销售订单要转成交货单,交货单过账后要转成开票凭证,开票凭证要转成会计凭证,这些转换全部由复制控制规则驱动。
复制控制路径主要有三处:
销售和分销 → 销售 → 销售凭证 → 复制销售凭证数据 → 定义复制控制
销售和分销 → 装运 → 交货 → 定义交货类型及复制规则(交货单复制控制)
销售和分销 → 开票 → 开票凭证 → 复制控制 → 定义开票凭证的复制控制
每一处复制控制都是一张二维矩阵表:行是源凭证类型,列是目标凭证类型。比如订单到交货,行是 OR,列是 LF;订单到开票,行是 OR,列是 F2。矩阵里的每一格还有“复制控制级别”定义——只复制表头数据,还是表头和行项目都复制,还是连计划行一起复制。
常见的坑是复制控制漏配。比如你定义了新的销售凭证类型 ZOR,却忘了给它和交货类型 LF 配置复制控制,那么从 ZOR 创建交货单时,系统直接报错“没有找到 ZOR 到 LF 的复制规则”。这种错非常典型,排查起来也不难,但新手容易慌,在交货单配置界面找半天。
复制控制里还有一个细节:复制条件。比如订单类型 ZOR 只在“已批准”的状态下才能转成交货单。这些条件也要在复制控制条目里维护,否则业务人员可以绕过审批流程直接发货。
4.4 交货、装运与开票相关配置
交货类型定义了交货单的行为。路径:
销售和分销 → 装运 → 交货 → 定义交货类型
标准交货类型是 LF(外向交货)。交货类型里要指定交货项目类别(Deliver Item Category),比如标准项目类别是 DLN,文本项目是 DLN 或者 DAN。交货类型还涉及拣配、包装、装卸、装运点确定等流程。
装运点确定(Shipping Point Determination)在交货流程中扮演“自动选发运点”的角色。路径:
销售和分销 → 装运 → 装运点 → 装运点确定
系统会结合销售凭证里的装运条件、工厂、装载组、国家地区、运输组等条件,自动匹配一个装运点。这个配置如果做得粗糙,可能会出现有库存却不自动推荐装运点的情况,或者推荐到错误的仓库。配置时要检查“规则”里的条件顺序,确保优先命中你期望的那个装运点。
开票相关配置里,最核心的是开票凭证类型。标准发票类型是 F2(销售发票),贷项凭证是 F8,借记凭证是 F5 等。路径:
销售和分销 → 开票 → 开票凭证 → 定义开票凭证类型
开票类型会影响编号范围、会计过账、发票拆分合并逻辑。复制控制要把订单到开票的类型规则配全,否则订单无法出票。收入科目的确定也非常关键,路径:
销售和分销 → 基本功能 → 科目分配 → 收入科目确定 → 定义科目确定规则与科目确定程序
收入科目确定是通过定价过程中的条件类型(比如 KOFI)把销售金额过账到财务科目的。如果科目确定规则配错,发票过账后会生成错误的收入科目。实际项目里最常见的是:不同产品组对应不同收入科目,但科目确定规则只建了一个条件记录,结果所有产品线的收入都汇到一个科目上,财务报表直接失真。这个问题在测试期非常隐蔽,等财务月结发现收入科目对不上,再去翻配置,成本就高了。
5. 常见问题与排查技巧实录
配置做完不是终点,能调试通才算真正掌握。下面这些问题是 SD 基础配置里出镜率最高的,我在不同项目中反复见过,整理成速查表供你直接参考。
| 症状 | 可能原因 | 排查思路与路径 | 常见修复办法 |
|---|---|---|---|
| 创建客户时销售范围选不了 | 销售范围未定义或未分配完整 | 检查 SPRO → 企业结构 → 分配 → 销售和分销 → 设置销售范围 | 重新执行分配后生成销售范围 |
| 创建客户时报账户组无编号范围 | 账户组未分配编号范围 | 检查 SPRO → 销售和分销 → 主数据 → 客户 → 准备客户主数据创建 → 定义客户账户组的编号范围 | 给对应账户组分配内部或外部编号范围 |
| 销售订单价格带不出来 | 定价过程未分配或条件记录缺失 | 事务码 VA03 查看定价分析,事务码 OVKK 检查定价过程确定 | 分配定价过程到销售范围;维护相应条件记录 |
| 订单不能转交货单 | 复制控制缺失 | 检查 SPRO → 销售和分销 → 销售 → 销售凭证 → 复制销售凭证数据 → 定义复制控制 | 新增源凭证类型到目标交货类型的复制规则 |
| 创建交货单时报无装运点 | 工厂未分配装运点或装运点规则不匹配 | 检查 SPRO → 企业结构 → 分配 → 后勤 → 给工厂分配装运点;检查装运点确定规则 | 给工厂补分配装运点;调整规则条件 |
| 交货过账库存不足 | 可用性检查或库存状态问题 | 查看物料主数据可用性检查组,查看库存状态 | 调整 ATP 规则;释放库存或补货 |
| 发票过账科目错误 | 收入科目确定条件记录缺失或匹配错 | 检查 SPRO → 销售和分销 → 基本功能 → 科目分配 → 收入科目确定 | 新增正确的科目确定条件记录 |
5.1 报表驱动的配置检查习惯
配置完成后,不要只靠模拟单据去碰运气。SAP 提供了一些检查报表和日志,最实用的几个建议熟记:事务码 V.03 是销售订单报表,VA03 查看销售订单,VL03N 查看交货单,VF03 查看开票凭证;事务码 OVA6 可以快速查看销售凭证复制控制矩阵,事务码 OVKK 看定价过程确定。
我个人的习惯是:每个配置节点做完后,马上模拟一个完整业务场景,从报价、订单、交货、开票一路走到底,看中间是否有报错。如果中途报错,优先看报错信息里提到的对象——是组织架构、主数据还是复制控制问题。SAP 的报错信息一般都很直白,比如“没有为工厂 X 定义装运点”“客户 Y 在销售范围 Z 中不存在”,顺着信息拆解,比自己盲目翻配置要高效得多。
5.2 传输管理和配置一致性
还有一个项目阶段容易出问题的点:传输。配置在开发机完成并测试通过后,要释放传输请求,按顺序传到测试机、生产机。每次传输前,建议用“比较配置”功能检查开发机和目标系统之间的配置差异,避免覆盖掉目标系统里已有的热修复。
传输后要做业务流程回归测试。因为组织架构、主数据、凭证类型之间有引用关系,漏传某个分配关系或复制控制规则,会导致生产机出现“开发机正常,生产机报错”的诡异现象。我在项目里吃过这个亏:销售凭证类型 ZOR 传到生产机了,但对应的编号范围定制没传,结果创建订单时一直报编号范围错误。那段时间一度以为代码有问题,后来一查传输请求,发现少传了一条配置记录。
5.3 从基础配置到业务扩展
SD 模块的基础配置虽然庞杂,但越往后越会发现,核心其实是稳定的:组织架构定框架,主数据定要素,凭证流程定路径。这三件事做好,SD 的地基就稳了。
之后再往上扩展的功能——比如信用管理、输出确定、定价增强、可用性检查增强——都是在这套地基上做文章。很多顾问一上来就研究客户增强和 BAdI,反而忽略了最基础的复制控制和定价过程理解,后面做增强时连断点触发在哪一层都找不到。先花足够时间把标准配置吃透,做增强时才能游刃有余。
我个人在实际项目里最大的体会是,SD 配置不要追求一步到位,而要追求“每配置一项就知道它管什么”。比如你改了一个项目类别的字段,要想清楚这个改动会影响哪些订单类型、哪些物料类型、哪些流程节点;你加了一条复制控制规则,要明白它会让哪条业务流跑通,又会放开哪些操作限制。带着这种“知道为什么”的心态去配,哪怕遇到没见过的报错,也大概率能通过逻辑推演找到答案。
最后再分享一个小技巧:在 SPRO 里做完任何配置后,按一下“检查”按钮,很多时候会直接告诉你缺少哪些关联配置。养成这个习惯,可以在沙盘里省掉无数来回试错的功夫。