企业官网建设流程全解析

简介：SAP SD定价配置步骤PDF文档，是一份面向SAP顾问、实施人员及认证考试备考学员的实用技术笔记。文档以直观的步骤拆解，完整覆盖定价配置的八个关键环节：从字段目录、条件表（V/03、V/05）、条件类型（VK13）、存取顺序到确定过程的创建与分配、条件记录（VK11）生成，每一步都说明了配置目的和操作入口，并串联后台与前台逻辑，帮助读者建立起定价配置的整体框架。除了标准流程，文档还补充了价格主数据优先级、计算顺序、手动更改、统计信息、打印小计、中间表需求、计算类型等配置要点，并针对复杂实施场景，给出了新增字段、依赖条件、公式例程等扩展思路，避免在实际项目中“照本宣科”。资源为单个PDF文件，体积约867KB，适合随时查阅。目前已有717人学习浏览，是快速掌握SAP SD定价配置细节的一手参考。

1. SAP SD定价配置到底卡在哪：从一张订单的价格不对说起

做SAP SD实施或做企业内部IT支持的人，迟早会被同一个场景卡住：销售同事在VA01里建了一张销售订单，保存前看到价格不符合预期——该给的客户折扣没进去，或者条件记录明明维护了，订单价格却是0。这时候翻出办公桌上那份「SAP_SD定价配置步骤.pdf」，对着里面的截图和路径走，结果发现不是这一步名字对不上，就是配置完看不到任何效果。这不是你笨，而是SAP的定价从来不是「在订单行项目里手动填个价」那么简单，它是一套由条件类型、存取顺序、条件记录、定价过程共同组成的计算链。这篇内容就是一条把这条链讲透、跑通、能排查的实战路径，适合正在做SD顾问、企业内部支持岗、以及刚接手定价配置却不知道从哪里下手的初级从业者。

2. 定价的骨架：条件类型、存取顺序、条件表三者怎么串成一条链

2.1 为什么SAP SD定价不是「填个价」，而是「按条件找价」

SD模块里的单据串联关系是「销售订单 → 交货单 → 开票凭证」，价格这个字段最特殊，它不是在每一层都重新手填的，而是在销售订单创建时由系统通过一个「查字典」逻辑算出来的，交货单和后续开票都承接这份计算结果。这个「查字典」逻辑就是定价。你把客户代码、物料代码、订单数量、订单日期这些要素丢进去，系统按预先配置好的规则去找对应的价格或折扣记录，找到就带出来参与计算，找不到就忽略或报错。

这带来一个反直觉的结论：你在VK11里维护的那条「价格」，本质上不是订单上的字段值，而是一条「条件记录」。条件记录存放在条件表里，表决定了「在什么字段组合下能命中这条记录」。比如你维护了一条物料A的价格，条件是物料；再维护一条客户C加物料A的价格，条件是客户+物料。那么订单里同时带客户C和物料A时，系统优先命中更精确的客户+物料那条，而不是物料那条。这种「更精确优先」的规则不是你定的，是你在存取顺序里定义出来的。

很多新人一上来就急着去复制一个标准定价过程，却不理解这条链是怎么运转的。结果就是改了一堆值，订单还是一动不动。我一般会先让人做一件事：打开VA03，进入一张价格正确的旧订单，菜单路径「环境 → 分析 → 定价」，你会看到系统实际计算的每一步：哪一步用了哪个条件类型、取了哪条条件记录、基数是多少、金额怎么算出来。看懂这个画面，比看十遍配置文档都有用。

这套设计的真正价值在后续单据流里才体现出来。订单价格一旦确定，交货单过账不会重新算价，开票也是按交货单复制。如果中途有人改了条件记录，已保存的订单价格不会被冲掉，这保证了单据的历史一致性。代价就是，查价格是否正确，必须回订单的定价分析里看，而不是只看条件记录本身——后面会重点讲这个排查思路。

2.2 条件类型与条件表：VK11那一笔到底存到哪里去了

先理清三个最容易混淆的概念。条件类型是「价格或折扣的业务含义」，比如PR00表示普通价格，K004表示客户折扣，K007表示物料折扣。条件表是「命中的字段组合结构」，比如表001是按物料查价，表003是客户加物料，编号不必硬记，你打开配置时能看到每张表的字段清单。条件记录则是你通过VK11实际录入的数据，比如「客户C在物料A上的价格是100元」，数据分别存在条件抬头表KONH和条件项目表KONP里。

维护条件记录时，VK11界面会先让你选择「条件类型」，然后让你输入这个条件类型对应的「键值组合」。键值组合由什么字段构成，正是你在后台配置里给这个条件类型指定的存取顺序决定的。所以同样是在VK11里录PR00，有些系统让你只输物料，有些系统让你输客户加物料加地区，有些还要输数量段。

我经常遇到用户抱怨「VK11里找不到那个字段」，其实不是找不到，是这个条件类型分配的存取顺序里根本没有包含那张条件表。标准的做法是：在后台定义条件类型时，给它分配一个存取顺序；在存取顺序里，按精确度从高到低排列几个条件表。例如给PR00配一个ZS01的存取顺序，包含「客户+物料」表和「物料」表，那么VK11维护PR00时，系统会根据这个存取顺序，让你能分别维护两种粒度的价格。

这里有个容易懵的点：条件类型、存取顺序、条件表是一对一还是一对多？常见的做法是，一个条件类型对应一个存取顺序，一个存取顺序里包含多个条件表，系统按顺序逐个查找，先命中哪张表就用哪条记录。这个「先命中」逻辑是定价能否出正确价格的分水岭，下一节专门讲它。

2.3 存取顺序：为什么物料有价，加上客户维度后反而查不到

存取顺序是SAP定价里最容易被忽略、也最容易翻车的地方。它做的事很简单：给当前条件类型把条件表按优先级排个队，系统在订单定价时，从上往下逐表查找，一旦在某张表里找到记录就停下来，不再往下查。

问题就出在「找到记录就停」这个逻辑上。假设备了一个PR00的存取顺序，先查「客户+物料」表，再查「物料」表。现在客户C加物料A维护了100元，物料A单独维护了120元。系统查找时第一张表命中，价格取100元，这没问题。但如果客户C加物料A的记录维护了，但有效期截止到上个月，系统查第一张表时发现记录已过期，会把它当成「未命中」，继续往下找，最后取到物料A的120元。于是你看到的订单价格不是100元而是120元，而你还以为系统抽风了。

更隐蔽的一个问题是「空白命中」。如果存取顺序里有一张表是「客户」加「物料」加「生效日期」，你维护记录时把生效日期留空了，某些系统版本会把这条记录视为永远生效，这张表在查找时永远排在前面命中，后面更精确的表根本没机会执行。我的建议是，给条件类型设置的存取顺序里的条件表，字段组合千万别层层冗余。表与表之间要有清晰的粒度差异：第一张表字段最多、最精确，后续每张表逐步去掉字段、放宽范围，而不是把相同的字段换个顺序再做一张表。

我见过一个企业内部的定价配置，PR00的存取顺序里放了五张表，其中三张表的前四个字段完全一样，只是表的编号不同。结果每次维护价格，用户都要在VK11里逐一检查五张表有没有重复录入，出错率极高。后来我把存取顺序收敛成两张表：一张客户+物料，一张物料，一个月后才消停。存取顺序不是越复杂越好，它是「系统查价的路径」，路径越短，越容易预判结果。

3. 从空白系统跑通一次定价配置：路径、字段与最小验证

3.1 最小配置路径：五步走，从条件类型到定价过程分配

把定价配置从零跑通，我建议不要直接去复制标准定价过程RVAA01，而是按下面这个顺序一步步建，每一步都能验证，最后合起来才不至于出错。这套顺序也是很多实施项目里实际采用的落地路径。

第一步，定义条件类型。进入SPRO → 销售和分销 → 基本功能 → 定价 → 定价控制 → 定义条件类型，事务码是V/08。新建一个条件类型，比如ZPR0，复制标准PR00或者直接创建，关键字段在后面几步里维护，这里只要建出这个壳。字段「存取顺序」暂时留空，后面配好再填。

第二步，定义存取顺序。路径同上，进入「定义存取顺序」，事务码V/06。创建一个如ZS01的顺序，在「表」标签页里添加条件表。如果标准表里没有你要的字段组合，需要先在「定义条件表」里用事务码V/04创建一张自定义条件表。

第三步，定义定价过程。路径「定义并分配定价过程」下的「维护定价过程」，事务码V/04。新建一个过程，比如ZPRIC01，在里面按行添加步骤。定价过程是整个配置的核心，它的每一行代表一个计算步骤，具体字段含义在3.2里讲。

第四步，分配定价过程。还是在「定义并分配定价过程」路径下，进入「定义定价过程确定」。这里做的不是把过程分配给订单类型，而是设置一个查找规则：当销售订单类型、客户定价过程、物料定价过程组合成什么值时，系统就用什么定价过程。标准系统默认是按销售单据类型分配定价过程，常见做法是把这个分配关系配置在「销售单据类型」层级，再把客户定价过程配置在客户主数据里。

第五步，维护条件记录，用VK11录入一条测试价格。这一步必须在定价过程分配完成后做，否则你录入时系统虽然能存，但订单读不到。

五步走完，用VA01创建一张测试订单，输入客户和物料，回车后看行项目价格。我一般会在这一步一次性验证三件事：价格是否带出、折扣是否带出、最终净价是否等于手算结果。三步都对，说明整条链通了。

3.2 定价过程里每行字段的意思：步骤号、计数器、必需、正负、小计

定价过程打开后是张表格，每一行是一个步骤，每个步骤可以是一个条件类型、一个小计、或者一个合计。新手最常犯的错误是把所有条件类型都堆在一起，不看顺序和基准，结果系统算出来的净价和业务预期差一大截。

定价过程里的关键字段就那几个。步骤号决定了计算顺序，系统从上往下逐行算；计数器是同一行里多个条件类型的编号，很少用到；条件类型列填PR00或K004这类，如果是小计行，这里填的是「小计1」「小计2」或「总计」这种特殊行。必需列如果勾选，表示本步骤必须找到条件记录，否则保存凭证时系统会报错；正负列里的负数表示折扣方向，正数表示加价方向。统计列勾上后，该步骤只显示金额但不参与净价计算。

我一般会给新人看下面这个最小可用的定价过程结构：

注意第20行的客户折扣，它的基准是什么？系统默认取「直到前一步为止的累计值」。所以折扣步骤必须放在价格步骤之后，否则系统拿0做基数，折扣算出来是0。如果你希望折扣按「价格加运费」来算，那就要把第40行的运费挪到折扣之前，或者通过基准步骤字段指定从某个小计步骤取值。定价过程里的每一行本质上是一条小计算器指令：取什么值、做什么运算、结果显示在哪。

还有一点，保存定价过程后要记得「激活」或「释放」，有些系统版本里这个过程还有一个状态字段，未释放的过程在订单里不会被调用。我踩过这个坑，配置流程看起来全对，但VA01里价格就是出不来，最后发现是过程没释放。遇到类似情况，先回V/04里检查状态，别急着改条件记录。

3.3 在客户主数据和订单类型上把定价挂上去

定价过程配置好，不等于所有客户都在用。系统实际调用哪个定价过程，是由订单类型的定价过程确定规则，和客户主数据里的「定价过程」字段共同决定的。这一步经常被漏掉，导致同样的物料，换个客户价格逻辑就变了。

以S/4HANA里的业务伙伴（BP）主数据为例，进入客户主数据维护事务码BP，切到销售视图，找到「销售」标签页里的「定价」子视图，那里有个「定价过程」字段。如果这个字段为空，系统会用默认的定价过程；如果你希望这个客户走特殊折扣逻辑，就得在这里填一个不同的客户定价过程。注意，「客户定价过程」和「定价过程」是两个东西，前者是一个编码，被系统用来在定价过程确定规则里查最终使用的定价过程。

订单类型这边，事务码OVB2或者SPRO里的「定义销售单据类型」下，能找到「定价过程确定」相关的字段或规则。系统先拿订单类型去确定一个范围，再结合客户定价过程、物料定价过程，最终匹配出完整的定价过程。这部分配置是嵌套的，排查时别只盯一个地方，我通常按「订单类型 → 客户定价过程 → 物料定价过程」的顺序一层层点下去，很快就能定位问题在哪层。

4. 定价过程确定与计价分析：价格不对时往哪条路查

4.1 定价过程确定链：订单类型、客户、物料三层匹配

价格不对，第一步不是去改条件记录，而是先确认系统现在用的到底是哪个定价过程。怎么查？打开VA03进入订单，菜单「环境 → 分析 → 定价」里会显示本次定价用的过程名称，对照一下是不是你配置的那个。如果不是，说明定价过程确定规则里出了问题，你条件记录维护得再对也没用。

定价过程确定链的完整顺序大致是这样：系统先根据销售单据类型找到可用的「销售单据定价过程」范围，再根据客户主数据里的「客户定价过程」缩小范围，最后结合「物料定价过程」确定最终过程。每一层都有各自的配置入口，常见的做法是大部分客户共用默认过程，少数特殊客户单独指定。

排查技巧是倒着查：先在VA03的定价分析里看到当前用的过程名，再回到后台看这个过程的分配规则，然后往回核对客户主数据里的定价过程字段是否按预期维护。我见过一个案例，价格时对时错，排查到最后发现两个销售区域共用了同一个客户主数据，而客户定价过程是按销售区域维护的，订单一跨销售区域就跳到另一个过程，业务端完全不知道。

4.2 用VA03的凭证分析追踪每一步计价

定价分析窗口是这个模块里最值得花时间看的数据，没有之一。它把定价过程从头到尾的每一步都展开：步骤号、条件类型、条件记录号、存取顺序、基数、单位金额、总额、是否统计、是否入账。你在配置里配了什么、条件记录里录了什么，最终都落到这张表上。

看这张表有个固定的套路。第一步，定位基准价格步骤，看它的金额和你VK11维护的记录是否一致，不一致就是条件记录或存取顺序问题，一致就往下看。第二步，核对所有折扣步骤的基线，折扣步骤的「计价基础」列显示的金额是不是你业务上预期的基数，不是的话，问题多半是步骤顺序。第三步，看每一行有没有被统计标记，统计行的金额会单独显示，但不会累加到净价里，如果你发现折扣在分析里出现了却等于没出现，大概率是统计列被勾上了。

这是典型的「黑匣子」解法。配置上的感觉都是玄学，但定价分析窗口里的每一列都是确定的。我每次改完定价配置，都会强迫自己在这张表里从头到尾过一遍，确认每个步骤的金额和手算结果一致，再关掉事务码。

4.3 订单、交货、开票三段的价格一致性

很多SD从业者容易在开票阶段才发现问题：销售订单价格对，交货单过账后也对，但开票时金额变了。这在大部分情况下不是定价配置的问题，而是订单价格到交货单、交货单到开票的复制和调整逻辑导致的。

价格在销售订单里通过定价过程计算并保存在条件记录里，交货单创建时按「复制控制」把这部分条件数据带过去。如果交货单里重新打开了定价（比如对交货单做了价格修改），或者开票时采用了「部分开票」折行，金额就可能出现尾差。还有一类常见情况是，订单被参照复制（如VA01按已有订单创建新订单）时，系统会重新读取定价条件，此时条件记录的有效期如果已过，就会取新值，导致「别的都没变，价格变了」。

我的处理习惯是：任何价格相关的配置或数据变动，先在三张单据上各看一眼价格再下结论。SD模块相关单据之间的价格一致性，很少是「一个开关」能解决的，更多时候是复制控制、定价类型、事务流共同作用的结果。你在订单层把定价看透，交货和开票层只需要确认复制逻辑没有额外干扰。

5. 避坑清单：定价配置最常见的5个翻车现场

5.1 条件记录建了，订单价格还是0

现象：VK11里PR00维护了物料价格，VA01创建订单，行项目价格显示0。

原因有两个高频可能。第一个是定价过程里PR00那一行勾了「统计」，或者根本没放进当前定价过程；第二个是存取顺序里的条件表没有命中，比如条件记录维护在「客户+物料」表里，但当前订单的客户编号与记录不一致。

解决：先打开VA03的定价分析，看PR00步骤是否存在、基数是什么。如果PR00行都不在，去检查定价过程；如果行在但金额为0，把VK13打开，输入同款条件类型和键值，看这条记录在系统里能不能查到。能查到但订单不取用，再看存取顺序。

5.2 折扣在分析里有，订单算出来却高于预期

现象：K004客户折扣录了10%，定价分析里也能看到这行，但最终净价等于原价，折扣完全没减。

原因：折扣步骤被勾了「统计」，或者条件类型把计算类型设成了「数量」而不是「百分比」，也可能折扣的「基准步骤」没有指向价格小计。

解决：回到V/04定价过程里检查该条件类型所在行的统计勾选，去掉勾选；再看计算类型，标准折扣条件类型一般是「百分比」，如果被改成固定金额或数量，金额自然不按10%扣。最后检查基准步骤字段，确保它取的是价格行的小计。

5.3 给了VK11权限，用户还是不能维护条件记录

现象：用PFCG给业务用户添加了VK11事务码，用户打开后能看到价格清单，但点新建或保存时提示「没有权限」或按保存无反应。

原因：VK11涉及条件记录的写操作，光给事务码不够。系统还会检查条件类型的授权组，以及底层数据库表的更新权限。SAP ECC/PFCG角色里如果只挂了事务码，没有挂对应的授权对象，写操作会被拦下。

解决：在PFCG角色里给用户挂上必要的授权对象，核心是S_TCODE（事务码）以及跟条件维护相关的权限对象。另一个常见坑是用户主数据里「用户组」为空，导致某些参数文件不生效。配完角色后让用户重新登录，别用同一个会话测，SAP的权限缓存常常会让人误判。

5.4 复制订单时价格被「新值」悄悄替换

现象：用户参照旧订单创建新订单，只有客户和日期变了，订单价格和旧订单不一样。

原因：参照复制会重新读取条件记录。旧订单当时生效的价格记录可能已经到期，新订单按当前日期取到新价格；或者新订单的客户定价过程与旧订单不同，系统走了不同的定价过程。

解决：这种属于「数据层面正确、业务预期不一致」。常见做法是先在定价过程中确认是否需要锁定复制来源的价格，而不是重新读取。对不需要随日期变化的特殊价格，可在条件记录里把有效截止日期设成9999年，或者用单独的定价过程，把复制控制调整为「复制订单条件」而不是「重新确定」。

5.5 批量导入价格后，部分客户的价格显示翻倍

现象：用批量工具或者直接通过表维护更新了价格后，部分客户订单里的价格变成了原本的两倍，甚至叠加了好几层折扣。

原因：最常见的原因是同一条件类型在多个条件表里各存在一条有效记录，比如「客户+物料」里有一条100元，「物料」里也有一条100元，存取顺序里两张表都能命中，系统逐层累加或覆盖混乱。另一个原因是批量导入时没有清理旧记录，导致同一张条件表里同一键值出现了多条有效期重叠的记录。

解决：用VK13按物料和客户查一遍现有记录，把所有重叠有效期的记录都显示出来，删掉或缩短旧记录。批量导入前务必先做一次「按条件类型+键值去重」的检查。我一般会导出KONP表数据核对一遍再导入，宁可慢一点，也别让价格在数据层面叠罗汉。

6. 进阶：用条件记录核对与凭证分析固化价格成果

定价配置跑通只是起点，真正体现水平的地方在于：怎么让配置结果在一段时间后仍然可信。我的做法很简单，定期把条件记录和订单定价分析对照起来看，形成一套可重复的验证习惯。

条件记录核对，我一般用SE16N直接查KONH和KONP两张表。KONH里看条件抬头：条件类型、客户、物料、有效期起止；KONP里看条件项目：金额、计量单位、计算类型。注意这个操作只建议查看，不建议直接改表，改表绕过VK11的校验，容易把条件记录改出逻辑错误。要导出全量清单，优先用VK13按条件类型和数据范围导出，这个版本更安全。

数据核对完，还要做一次「凭证级回归」。我用的办法是维护一张特定的定价验证订单模板，物料固定、客户固定，里面必须包含三个要素：一个基准价格PR00、一个百分比折扣、一个固定金额的附加费。每次改完定价配置，就用这个模板重新跑一遍VA01，打开定价分析核对净价。这张订单就是定价配置的回归用例，比任何口头约定都可靠。跑过几次后你会发现，配置变更最危险的地方往往不在配置本身，而在配置之外的客户主数据、条件记录有效期这些不起眼的位置。

最后分享一个经验习惯：每次改完配置，我都会用一个不熟悉这个系统的同事账号去开一张测试订单，不看过程、只看结果。如果他不靠任何提示能在订单里看到正确的价格，这个配置才算真的收工。配置好不好，不取决于你写了多少行，而取决于下一个接手的人能不能一眼看懂。这套方法在类似ERP系统里通用，希望帮到你。

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