SAP SD主数据全解析：客户、物料、定价、信用及批导实战

很多刚接触SAP SD模块的朋友，第一个被绕晕的地方往往不是销售订单怎么建，而是“主数据”这三个字。我在做项目时带过不少新顾问和内部关键用户，发现一个普遍规律：凡是销售订单、交货单、开票流程中反复出问题的，追根溯源，十有八九都出在主数据上。物料主数据的销售视图少维护了一个字段，客户主数据里统驭科目配错了，价格主数据没有维护销售范围层级——这些问题在测试环境里改一改就好，一旦上了生产，纠缠起来就是跨部门扯皮、月底对账对不上的大麻烦。

这篇内容我就把SAP SD主数据这件事从头到尾捋一遍。先讲清楚主数据在SD整体业务里到底扮演什么角色，再逐个拆解客户、物料、定价、信用这几大类主数据的核心字段和逻辑，然后结合我做项目时的实操经验，聊聊批次导入、数据迁移和数据治理这些事情。适合正在学SAP的顾问、刚接手SD模块运维的IT人员，以及想搞明白系统逻辑的业务用户，内容偏总览和框架，但每个环节都会给出实际操作层面的心得，不是照本宣科。

1. SD主数据全景：一张销售订单背后调用了什么

先建立整体认识。SAP SD模块本质上管理的是从客户询价、销售订单、发货过账、开票到应收记账这一整条业务链。这条链上每一步操作，都需要主数据作为支撑，系统不会凭空知道价格是多少、客户要求什么交货方式、该从哪个工厂发货。

1.1 一张标准销售订单的创建过程，系统读了多少数据

你在VA01里维护一张标准销售订单，屏幕上需要输入的字段其实不多：售达方、送达方、物料号、数量、工厂。但当你敲回车的那一瞬间，系统内部干了一堆你不知道的事情：

• 根据客户主记录的销售范围数据，确认这个客户能不能从这个销售组织买货；
• 根据物料主数据的销售视图，检查该物料是否允许在此销售组织销售；
• 读取出运点和交货工厂，决定从哪发货；
• 根据定价过程找到对应的价格主数据，计算出净价；
• 检查可用量，决定是否触发可用性检查（ATP）；
• 根据物料主数据的税分类和客户主数据的税分类，确定税码；
• 更新信用主数据的额度占用情况。

任何一个环节的主数据有问题，这张订单要么保存的时候直接报错，要么报错能绕过但后面交货、开票、过账的时候爆雷。很多顾问一上来就研究BAPI_SALESORDER_CREATEFROMDAT2怎么传参（这也是个热词），但传参里的字段其实都是从主数据带出来的，主数据没弄对，BAPI的测试来回跑不通就是常态。

1.2 主数据和SD组织架构的关系：销售范围决定一切

SD主数据有一个区别于MM和FI主数据的显著特点：它是分销售范围（Sales Organization + Distribution Channel + Division）的。同样是客户主数据，在集团层面可能就有三四十个字段的语义完全依赖于销售组织数据；换到成都销售组织去查看同一个客户，看到的销售视图就会不同。

组织架构的优先级很高。在实际项目里，我一般会建议先跑通组织架构，再动主数据，原因是主数据的销售范围信息必须挂在已分配好的组织架构上。比如你要给客户维护销售视图，必须先给该销售组织分配好分销渠道和产品组，否则IMG里根本看不到该层的配置选项。这块不理顺，后面BDC批导或者LSMW导主数据的时候，报错会铺天盖地。

需要注意的一点：SAP的项目实践中，组织架构的调整在项目后期是很痛苦的，因为主数据、单据、科目都挂在架构节点上。所以做蓝图阶段就要跟业务确认清楚：未来会不会增加新的分销渠道、新公司是不是要复用同一个销售组织。这一点是SD主数据管理的顶层约束，也是我带的项目里最常出的隐性风险。

1.3 主数据质量差，业务链上哪里最痛

光说“主数据很重要”没什么感觉，直接列一下数据错误在不同环节的典型表现：

• 销售订单环节：系统提示“客户账户组不存在”或“物料未定义在销售组织”，订单建不出来，销售员只能反复电话问IT。
• 库存和可用量环节：物料主数据的可用性检查字段没设好，后台ATP结果不准，客户订单交期承诺失真，承诺了交不了货。
• 交货环节：出运点没维护，交货单创建卡住；装载组、运输组缺失，装运计划算不出来。
• 开票环节：计税收款范围、价目表、定价过程是空的，开票时价格提取不到，财务临时用手工价格。
• 对账环节：客户主数据里统驭科目配错，应收账款记到错误的科目上，月末对账根本对不平。

这些症状有经验的顾问一看到就能反推主数据哪里有问题。但这属于事后救火。好的做法是从总览层面建立主数据质量清单，哪个字段由谁负责、在什么节点的维护标准是什么，先定清楚再动手补数。

2. 核心主数据逐一拆解：客户、物料、定价、信用、条件记录

总览的核心价值在于给主数据分门别类。SD模块里真正天天要打交道的核心主数据，我按业务影响程度排序来讲。

2.1 客户主数据：不要只盯着基本视图，销售视图才是SD的主战场

客户主数据在SAP里用XD01、XD02、XD03维护（部分项目用FD01维护财务视图），由三个层次的视图构成：

• 基本数据层：客户编码、名称、地址、电话、银行账户、统一社会信用代码等。
• 公司代码层：统驭科目、催款程序、容差组、付款条件、对账单等，这是FI和SD衔接的关键。
• 销售范围层：销售组织、分销渠道、产品组、订单原因、售达方/送达方回填逻辑、交货工厂、装运条件、价格组、客户统计组、税分类等。

实际项目里，新手最容易混淆的是“售达方（Sold-to）”和“送达方（Ship-to）”。卖方的合同和订单都挂在售达方上，但货物必须送到指定地点，送达方承担的是收货方的角色。一个售达方通常允许挂多个送达方，这在SAP中是通过客户主数据的“客户科目组”功能实现的。很多企业在主数据梳理阶段就把售达方和送达方搞混，导致物流发货单上地址全是总公司，分仓没有录入。

从SD视角看，客户主数据里最值得关注的字段包括：

• 销售范围层：销售组织/分销渠道/产品组，决定了这个客户在哪些范围内有效。
• 交货相关：交货工厂、装载组、运输组，影响交货单的创建和路径计算。
• 定价相关：价格组、客户定价过程、价格列表类型。价格组不同的客户可以有不同的定价逻辑，这是SD定价里很常用的区分维度。
• 基础相关：客户统计组、客户分类，用于出具销售分析报表和信用评估。
• 税相关：税分类，通常1表示征税、0表示免税。税分类配错，发票金额直接算错。

从实操经验来看，客户主数据上了几百家以后，最怕的是重复。同一家公司，一个叫阿里巴巴（中国）网络技术有限公司，一个叫阿里巴巴（中国）网络技术有限公司杭州分公司，在SAP里可能建了两条。这种脏数据后期清洗非常痛苦。所以主数据项目一定要在初始导入阶段就建立客户编码唯一性校验规则，不能完全依赖业务员的“我认为”。

2.2 物料主数据：SD销售视图的字段清单，少一个都让你哭

物料主数据由MM模块集中维护，但SD模块大量使用物料主数据的销售（Sales）视图和工厂（Plant）视图。SD顾问不能因为物料主数据是MM的“地盘”就不管，恰恰相反，销售订单、交货单、开票中很多报错都源于物料主数据的SD字段。

销售视图（Sales: Sales Org. Data 1和Data 2）中的关键字段包括：

• 销售单位（Sales unit）和基本单位（Base unit）的换算关系。比如产品按箱卖，基本单位是EA，销售单位是CT，两者的换算比例没配好会导致数量错误。
• 物料组（Material Group），用来做销售分析报表的统计维度。
• 税分类（Tax Classification），与客户税分类共同决定销项税计算。
• 项目类别组（Item Category Group），决定了销售订单行项目里能选择的项目类别（标准、免费、样品等）。项目类别组配成“NORM”是一般物料，配成“TANN”通常是免费物料逻辑。
• 可用性检查（Availability Check）字段，控制ATP检查规则。
• 运输组（Transportation Group）和装载组（Loading Group），用于运输计划。

工厂视图里也有一个关键字段：利润中心。如果SD订单行过账时没有正确带到利润中心，CO模块的获利能力分析报表就会失真——这也是热搜词里“工单结算与获利能力段”的问题经常出现的根因。

物料主数据还有一个特别容易被忽略的点：批次管理。如果物料启用了批次（Batch Management），销售订单创建时可能需要指定批次，或者通过批次确定策略自动带出。热搜词里“物料主数据批量大小”问的人多，其实就是批量大小字段在MRP视图里的作用，它影响采购建议的拆分逻辑，SD这侧不用管，但如果SD订单要跑可用性检查，和MRP信息交互时这个字段可能间接产生影响。

2.3 定价主数据：SD的“价格”不是手工敲的

很多业务用户问：价格不是我填进去的吗？在SAP里，销售订单上的价格可以由系统自动带出，也可以手工覆盖，但正规做法的核心是条件主数据（Condition Records），它本质上就是一套定价主数据。

定价主数据的三要素：条件类型、条件记录、定价过程。

• 条件类型：价格、折扣、附加费、税收这些分别对应不同的条件类型，如PR00是价格，K004是物料折扣，KA00是客户折扣，等等。
• 条件记录：在某条件类型上维护的具体价格和有效期。比如“物料A在2024年1月到12月对客户组01卖100元”，这就是一条条件记录。通过VK11创建，通过VK13查看。
• 定价过程：定义了系统在计算价格时，以什么顺序去取条件类型。定价过程在后台通过“定义定价过程”维护，从销售范围的销售组织/分销渠道/产品组里分配。客户主数据里的“客户定价过程”字段与销售凭证定价过程联动。

定价主数据的经验就一条：不要同时维护多套重复条件记录。实战中常遇到的情况是，VK11建了新价格但没有在日期上做覆盖，造成旧记录一直生效，系统取价时按优先级和有效期选了个“旧的”，于是业务看到“为什么价格不对”。排查方法就是三个事务代码：VK13查看条件记录、VA03查看订单定价分析（定价分析按钮，或者事务代码VA03的菜单栏里找到“分析”）、SE38跑定价报表。

有一个我遇到的印象很深的问题：某项目里业务反馈特定客户的订单价格比合同价高10%，排查了一圈发现是客户主数据里“客户定价过程”维护错了，导致系统取了另一个定价过程，步骤顺序里没有匹配到特定折扣条件，价格直接以基本价格输出。这种问题不会报错，但系统逻辑上确实按配置走了，不追根就永远找不到原因。这就是主数据在定价环节的隐蔽性。

2.4 信用主数据：信用额度，不只是财务一个部门的事

热搜词里“SAP SD 记录的信用决策”就是指信用管理。在SAP中，信用管理（Credit Management）属于SD与FSCM（财务供应链管理）之间的桥梁。信用主数据的主要载体是信用段（Credit Segment），它在主数据中的位置是通过客户主数据的信用视图来维护的。

信用主数据的关键项：

• 信用额度：给客户设定的风险敞口上限。
• 信用控制范围：决定信用检查的范围。一个信用控制范围可以包含一个或多个公司代码。
• 风险类别：一般按客户评级划分，影响信用检查的严格程度。
• 信用代表组：负责审批的信用团队。

SD订单在保存时，系统会根据信用检查规则计算“信用敞口=未清订单金额+未清交货金额+未清应收款”，超过额度时会触发警告或错误。这里最容易出问题的是：信用额度维护了，但信用控制范围没有分配给销售范围，导致信用检查根本没生效。还有的企业上线后业务反馈“信用查得太死了”，实际是风险类别配得太高，所有客户都按最严格级别来查。

我在做信用相关项目时的一条建议是：上线之初不要把信用检查设为错误级别，先设警告级别，跑一两个月看数据，再逐步收紧。这个策略可以避免一开始就卡死销售业务。信用主数据的清理比客户主数据更敏感，因为它直接关系到集团的风险敞口，每一次手工调额度都应该有审批流程，信息通过信用主数据变更记录可以追溯。

2.5 条件记录之外的辅助主数据：客户物料信息、输出条件、产品层次

SD主数据还有几张常用但容易被忽略的表：

• 客户物料信息（Customer-Material Info，事务代码VD51创建）。当某个客户有自己的物料编码时，需要在系统里建立客户物料信息表，把客户的物料编号和SAP内部的物料号对应起来。这个功能在汽车零部件、电子制造行业中非常常见，客户发订单时用的是他们的物料编码，业务员录单时直接输客户编码，系统自动带出内部料号。
• 输出条件（Output Determination）。SD很多环节都需要输出单据，比如订单确认、交货通知、发票。输出条件主数据规定了在什么条件下用什么传真/邮件/EDI发送。最常见的问题是订单确认没有自动发给客户，排查时通常要检查输出条件记录有没有维护销售范围层的“输出类型”。这个也算主数据的范畴，虽然严格上属于条件技术。
• 产品层次（Product Hierarchy）。一台设备通常有多层产品结构，用于销售分析报表的汇总统计。产品层次需要事务代码VK11/VK12来维护条件，或从物料主数据里分配层级号。热搜词还提到“SAP CVBOM和产品层次如何配合使用”，这涉及到变动BOM（Variant Configuration）与产品层次的关系。简单说，CVBOM是用来配置可配置物料（KMAT）的结构选配，产品层次则偏向于销售分析和统计；两者在可配置物料场景下会同时存在，但逻辑上是独立的两套机制，不要混在一起理解。

辅助主数据不用每天维护，但它们往往决定了自动化程度。项目上线前一定要检查输出条件记录有没有批量生成，否则上线后每一个单据都要手工点发送，那真是灾难。

3. 主数据维护实操：手工、批导、接口，怎么选更靠谱

主数据维护在项目里有三种路径：前台手工维护、批导工具（LSMW/BDC）、接口同步（从MDM/PLM/其他系统下发）。看起来只是操作方式不同，但选错了路径，后期运维成本差很多。

3.1 什么时候用前台，什么时候用批导，什么时候接接口

我的经验判断：

• 零星单据级维护，比如新增单一客户，直接前台XD01搞，速度快，还能顺便人工复核字段。
• 项目上线或主数据梳理阶段，一次性需要导几千个客户、几万条物料主数据，务必批导。LSMW是ECC时代最通用、最灵活的工具；S/4HANA环境下也可以用LTMC，但LSMW仍然能跑，很多老顾问继续用。
• 企业大了以后，主数据源头是PLM/MDM，SAP只是下游消费方，这时候不能靠手工了，必须走接口。接口同步的重点是幂等：同一主数据重复下发两次，系统不能产生重复记录；失败要有重试机制。

热搜词中还有“SAP LSMW”、“SAP ABAP维护视图”这类，说明很多人还在学习这些工具。LSMW批导的核心思路是：录制操作流程（或者用BAPI），然后做字段映射，再把源数据导入。这里有一个需要注意的点：客户主数据批导时，BS段、KNB1、KNVV这三块要分步处理。BS是基本视图，KNB1是公司代码视图，KNVV是销售范围视图。LSMW里如果一次性维护三层，字段多且容易出错，我不建议新手一次到位，建议分步导。

3.2 LSMW批导客户主数据：手把手过一遍关键步骤

以客户主数据批导为例子：

1. 首先明确源数据格式。Excel里至少包含：客户编码、名称、搜索项、街道、城市、邮政编码、国家、语言、统驭科目、付款条件、销售组织、分销渠道、产品组、交货工厂、装运条件、价格组等。
2. 事务代码LSMW进入，新建一个Project和Sub-Object，例如Project=SD_MASTER，Sub-Object=CUST_IMPORT，对象类型选“0040(客户主数据)”或直接用BDC录制。
3. 如果选择录制，在“记录”步骤里用XD01走一遍完整创建流程，录下所有屏幕的字段顺序。但录制出来的程序有个毛病：它录的是固定字段，如果源数据有的客户没有录某个字段，BDC里传入空值可能导致报错。所以更稳妥的做法是用BAPI方式。SD客户主数据批导最常用的BAPI是BAPI_CUSTOMER_CREATE、BAPI_CUSTOMER_CREATE_FROM_DATA1、以及BAPI_CUSTOMER_SAVEREPUTATION（这是后来版本里更推荐的）。BAPI_CUSTOMER_CREATE_FROM_DATA1能同时处理基本数据、公司代码数据和销售范围数据，入参结构比较清晰。
4. 字段映射阶段，把Excel列名映射到BAPI的结构字段，记得必填字段要勾选“必填项”，防止源数据缺字段时静默填空。
5. 执行导入。先跑前几条做测试，盯住看是否生成了正确的客户编码。注意客户主数据创建时，如果指定了外部编码，需要先在后台把客户编码范围设为外部编号，否则系统强制内部分号，你Excel里带进来的编码无效。

3.3 BAPI传销售订单时的主数据校验逻辑，为什么它总报错

热搜词里有“SAP BAPI_SALESORDER_CREATEFROMDAT2”，这个BAPI是SD顾问最常用的开发接口之一。但几乎每个人第一次跑都遇到过报错“Customer number has no sales area data”或者“Material is not defined for sales org”。这些报错就是主数据校验的结果。

BAPI创建销售订单时的校验链路：

• 函数ALE_SD_GET_BASIC_MASTER_DATA先从底层检查客户主数据和物料主数据是否存在于对应销售范围。
• 如果客户主数据在销售范围层没有扩展，系统会报错CUSTOMER_NOT_DEFINED。
• 如果物料主数据没有销售视图，系统报MATERIAL_NOT_FOUND或MESSAGE NO. MV 020。
• 检查定价条件记录是否存在，如果定价过程里需要PR00且没维护，会报“Pricing”相关错误，或者订单价格是空的。
• 检查ATP、信用检查也是各自独立的主数据调用。

如果这些报错频繁出现，不要一个个在代码层面处理，先回主数据层面把基础数据补全。我见过有开发同事写了一大段增强代码去屏蔽物料主数据销售视图校验，导致订单能建但后续交货全乱——典型的本末倒置。

4. 主数据治理：从上线到运维，一套能落地的机制

主数据不是维护一次就高枕无忧，尤其是集团型企业，客户和物料都是动态变化的。所以总览类的文章最后一定要讲治理机制，不然你的主数据状态只会越来越乱。

4.1 主数据字段责任矩阵：一个字段必须有唯一负责人

我推荐每个项目组做一张“主数据字段责任矩阵表”。拿客户主数据举例：

没有责任矩阵的结果就是：客户地址变了没人改，发货单一直寄错地址；客户付款条件改了，财务不知道，月底欠款逾期率上升。这些锅最后都甩给IT，但IT其实只能帮忙配置工具，业务规则还靠业务部门自己去维护。

4.2 上线切换阶段的主数据迁移：先清洗，后导入，再核对

项目上线前的数据迁移是所有主数据工作的重头戏。热搜词里“旧资产迁移到新系统”反映的也是这个痛点。

主数据迁移我总结的口诀：清洗、映射、导入、核对，四步缺一不可。

• 清洗：去重、统一编码规则、删除历史废弃客户。这个阶段一定让业务参与，IT不能替业务做决定。
• 映射：老系统编码对应新系统编码，需要做一张映射表。如果老系统用的就是客户名称做编码，新系统建议改成系统流水号，更可控。
• 导入：用LSMW、LTMC或者接口方式导入。上线前至少做三遍，不是一遍就完事。每一遍都要导出导入后的数据清单和源数据对比。
• 核对：以财务的客户余额、销售部门的客户交易记录为基准，验证客户主数据在FI、SD各层视图的完整性。

走完这四步，主数据上线成功率会高很多。凡是跳过了清洗直接导数的，后期基本都要花双倍精力去擦屁股。

4.3 常见问题速查表：主数据总览类场景下的排查思路

最后附一个速查表，覆盖SD主数据总览类文章里最常提到的几类报错和排查路径：

这个表格可以直接贴到项目知识库里，一线人员排查主数据问题时能省很多时间。

5. 两类特殊场景提醒：物料主数据批量大小与SD协议栈

这个章节专门针对热搜词里出现频率较高的两个话题做个提醒，因为它们在主数据总览里容易被人忽略，但实际项目中遇到的概率很大。

5.1 物料主数据中的批量大小，别让它坑了销售订单

物料主数据的MRP视图里有一个“批量大小”字段（Lot Size），比如批量大小键值：EX表示批量对批量，PK表示固定批量，等等。虽然这主要是MRP运行的参数，但当SD订单触发需求传递时（有计划行），MRP运算的采购建议会受批量大小影响。简而言之，如果批量大小设成固定订货批量10，但客户单次订单需求是12，MRP运算后可能建议采购20而不是12，仓库会觉得系统“算错了”。解决方案不是改批量大小，而是理解这个字段的业务含义：当库存策略允许超量采购时，这个设置是合理的；当订单对应的是项目型销售，最好用EX（按需求订）避免多余库存。

5.2 SD协议栈：云化、集成与主数据的同步关系

搜索词里“SD协议栈”可能被误解为技术底层协议，但在SAP语境下，更多人讨论的是SD模块在S/4HANA、BTP、API集成中的“技术栈”。这个点概括起来就是：主数据不再只存在于SAP内部，它可能需要与CRM、电商平台、数据中台协同。云环境下，客户主数据、定价主数据很可能由外部系统维护，SAP通过API实时同步。

在这个背景下，主数据管理的复杂度上升了不止一个层级：你不仅要管理SAP内部的主数据质量，还要关注外部系统的数据是否能通过同步任务正确落地。做这类项目时，我强烈建议设计“主数据同步监控报表”，每天检查同步失败的任务和异常字段，不要等问题被业务发现后再救火。

个人实操体会：一套适合长期运转的主数据总览落地方式

在多个项目里踩过坑之后，我越来越觉得主数据这件事的成败不看技术工具，而看有没有一套长期运转的机制。最开始我也痴迷于研究LSMW的进阶技巧、BAPI的报错处理，但后来发现，真正让项目稳稳运行的，是那几个最朴素的动作：字段责任到人、上线前反复清洗、上线后做同步监控、每次变更留痕。工具再强，也只是把这套机制固化的载体而已。

最后再分享一个小技巧：每次上线前，让IT团队打印一份“主数据关键字段检查清单”——每个主数据类别一张A4纸，上面列好关键字段、数值范围、责任人。业务用户拿去照着核对，比自己闷头在系统里翻效率高得多。做总览类文档的意义也正在于此：先跑通整体框架，再深入细节，最后把框架固化成日常操作可用的工具，主数据这件事就算真正落地了。