简介这是一份深入讲解SAP SD模块定价逻辑的Word文档适合SAP SD顾问、实施人员及需要理解销售订单价格计算原理的ERP从业者。文档从R/3系统如何根据物料金额计算净价值与总金额切入完整梳理了定价过程的确定框架、客户定价过程与单据定价过程的配置路径并逐项解释了后台配置界面中步骤、计数、条件类型、从/到、人工、必需、小计、计算类、条件基、帐码等字段的用途让读者能够真正看懂ZVAB02等常见定价过程。资源为单个doc文件压缩包大小2.87MB内容配有大量后台配置截图与顺序讲解适合按图索骥、循序渐进学习。目前已有650人学习下载是SAP SD定价后台配置领域一份简洁而完整的参考资料。1. 净价 85.47 与总价 100.00SAP SD 定价逻辑先看后台怎么“算”出来一张销售订单里物料金额维护 100.00 CNY系统展示净价值 85.47 CNY、总金额 100.00 CNY中间差额来自折扣、税、返利等条件的叠加。这个结果不是前端手工算出来的而是由 SAP SD 后台一套定价逻辑完整驱动先从销售区域、单据定价过程、客户定价过程等维度匹配出定价过程再按定价过程内部步骤依次取条件类型、执行小计和总计。对实施顾问和开发人员来说定价异常的排查路径也应该按这个顺序走而不是一上来就改 VK11 价格主数据。2. 定价过程确定销售区域、单据定价过程与客户定价过程的组合匹配2.1 决定因素是灰字段确定结果是白字段进入“定义定价过程确定”配置界面第一屏呈现的并不是计算算法而是一张决定因素与确定结果的对照表。灰色字段包括销售组织、分销渠道、生产线、单据定价过程、客户定价过程、定价过程、条件类型白色字段是系统最终确定的结果。以配置第一行为例销售区域 1000—11—11、单据定价过程 A、客户定价过程 1 共同决定了 ZVAB02 定价过程和 PR01 条件类型。这段配置的精髓在于“匹配”而不是“计算”。系统不会在每次创建订单时重新判断业务规则它只是把订单抬头和主数据里的字段值取出来与这张配置表逐行比对全部一致才命中。日常项目里最常出问题的两个点一是新增分销渠道后忘了补这一行配置二是客户主数据里的客户定价过程没维护结果订单定价过程走错折扣和税的计算全部异常。2.2 单据定价过程挂在订单类型上的标识单据定价过程在后台配置里只是一串短标识通常用 A、B、C 这类代码表示。它本身不参与计算真正的关联在“为订单类型指定单据定价过程”这个配置里。比如 ZOR标准订单分配到单据定价过程 A那么创建 ZOR 类型订单时系统从订单类型出发找到 A这个 A 再参与定价过程确定的匹配。项目里新增自定义订单类型后如果忘了维护这层映射最常见的现象是订单创建后找不到定价过程价格行直接为空或者退回去用了一个完全不对的默认过程。这里的判断方法很直接在 VA01 新建一张该订单类型的测试单查看定价过程能否被系统识别识别不出来时优先回去检查订单类型与单据定价过程的分配配置而不是去动定价过程内部。2.3 客户定价过程存在客户主数据里的匹配键客户定价过程和单据定价过程一样是短标识但它的存放位置变了它保存在客户主数据的销售数据视图里。系统匹配定价过程时要同时取出这个字段所以客户主数据维护不完整或者批量导入时漏了这个字段都会导致定价过程匹配失败。项目上处理内销、外销、关联方这类多业务并存的情况时通常会给客户分类维护不同的客户定价过程让不同客户群落到不同定价过程上。我这里有一条实用经验批量创建客户时把客户定价过程设成必填校验项。等订单价格出问题再去补这个字段往往要牵连到排错、返工和重复测试成本比提前校验高得多。2.4 三层匹配失效时的排查信号价格异常时要先区分问题位置客户定价过程错误通常表现为一批客户的折扣表现都不对单据定价过程错误表现为某一类订单类型的价格整体不对销售区域配置缺失则是同区域下所有订单都受影响。把三个维度拆开排查比直接去改定价过程内部步骤快得多。下表汇总了这几项配置的用途和异常特征配置位置配置内容定价确定中的作用异常典型现象定义定价过程确定多字段匹配行输出定价过程和条件类型订单取不到定价过程定义客户定价过程标识代码参与定价过程匹配同客户价格与预期不一致定义单据定价过程标识代码参与定价过程匹配同订单类型价格不一致为订单类型指定单据定价过程订单类型到标识映射为订单类型找到匹配键新增订单类型无价格3. 定价过程内部步骤、计数、条件类型与小计字段如何编排计算3.1 步骤与计数控制计算顺序的最小单位进入 ZVAB02 定价过程后每一行就是一个定价步骤步骤数值从小到大排列系统按这个顺序执行计算。计数的作用容易被忽略它解决的是同一个步骤内多个条件类型的次序问题。比如运输附加费全部放在步骤 100但实际存在三个运输条件类型分别代表不同承运商这时就在步骤 100 下分配计数 1、2、3让三个条件类型依次执行。这里要强调一个观念步骤编号不决定条件类型的业务优先级它只决定计算先后。如果折扣依赖基础价格折扣所在步骤必须放在基础价格步骤之后如果毛利计算依赖成本和售价两个来源对应步骤就要排在两者都被取到以后。配置定价过程时先画一张计算流程图再按流程图排步骤比对着配置界面一条条加要可靠得多。3.2 从、到与小计把局部计算累加成整体“从”和“到”在定价过程配置里有两种完全不同的含义这点非常容易混淆。第一种是定义小计的累计范围比如想累计步骤 10 到 50 之间的所有条件金额就在描述为“小计”的那一行里分别填写 10 和 50。第二种是定义计算的基础比如某个折扣按百分比计算就需要指定以哪一步的金额为基数通常把基数步骤号填在“从”字段。小计关键字负责把同一阶段的金额汇入公共字段。例如运费、附加费、包装费三个条件类型全部标记小计 A后续步骤只要引用小计 A就能拿到这三类金额的合计。系统里没有专门表示“小计”和“总计”的条件类型所以定价过程中经常能看到一些没有条件类型的描述行它们不负责取数只负责汇总前面的计算结果。下面给出一段演示用配置步骤 Ctyp 描述 从 到 小计 人工 必需 010 PR01 含税价格 010 020 A 020 K004 订单折扣 010 010 A √ 030 小计 010 020 A 040 MWST 销项税 030 030 B 050 总计 010 040这段配置演示的是先按 PR01 取含税价格再针对步骤 010 的金额应用手工折扣 K004步骤 030 汇总 010 到 020 的小计步骤 040 以步骤 030 为基数计算销项税最后步骤 050 计算总金额。注意这只是用于说明字段联动关系的演示结构不是 ZVAB02 的真实内容实际项目中的定价过程会比这复杂得多。从这个例子能清楚看到“从”字段的两种角色在折扣行里指的是计算基准步骤在小计行里指的是累计起点步骤。如果折扣行没有正确指定基准步骤百分比金额可能以整张订单的累计金额为基数算出来的结果会偏差很大。3.3 人工、必需、计算类、条件基与账码这五个字段分别影响条件类型在取数和过账时的行为逐一拆开看。“人工”勾选后条件类型只能手工在订单中维护即使 VK11 里维护了条件记录系统也不会自动带出。这是销售订单“价格没带出来”最常见的原因之一。判断方法很直接在定价分析里看该条件行是不是处于手工输入状态如果是并且你已经维护了条件记录回后台看条件类型上的人工标识。“必需”勾选后定价过程执行到这一步必须拿到值拿不到时订单会拒绝保存或给出错误提示具体表现取决于提示级别配置。“计算类”用于在标准条件技术不满足需求时用固定公式替代它复杂税率计算经常用到。“条件基”则给条件类型指定一个计算基础金额的公式后续百分比计算会以这个公式得出金额为基准。账码是条件类型和总账科目之间的桥梁系统根据账码决定条件金额计入哪个科目、记借方还是贷方。价格、折扣、运费、税每一种条件类型都要有对应的账码。项目顾问做定价配置时很容易只关注金额计算而忽略账码结果价格算得对财务过账科目却错了这种问题在订单界面上看不出来必须通过会计凭证反查才能发现。4. 条件类型与存取顺序PR01 的价格主数据是怎么被找到的4.1 条件类型既是计算元素也是主数据入口条件类型 PR01 在定价过程中是计算元素但它自己还挂着一组属性其中最重要的是分配的存取顺序。在“维护条件类型”配置里双击 PR01可以看到它挂上了存取顺序 PR02。这个挂接关系的意思是系统计算 PR01 时会按照 PR02 定义的取数路径去条件表里找价格。条件类型还决定了条件记录的可维护性。在 VK11 里创建价格主数据时弹出的那些“关键字组合”其实就是存取顺序里的条件表。也就是说价格主数据维护在哪些表里、能按哪些维度维护并不是 VK11 界面决定的而是条件类型背后的存取顺序决定的。想调整价格主数据的查找维度要去配存取顺序而不是改价格主数据本身。4.2 存取顺序几张条件表按优先级排队在“维护调取顺序”配置中进入 PR02可以看到它包含四张条件表存取编号分别是 10、20、30、40编号越小优先级越高。系统查找价格时先按第一张表的键值组合取数取不到再进第二张依次向下。下面是演示四层结构的例子具体表名和键值组合依据项目实际配置而定存取顺序 PR02 的假想结构 优先级 条件表 键值组合 10 条件表1 销售组织 分销渠道 物料 20 条件表2 销售组织 物料 30 条件表3 物料 40 条件表4 空白统一价如果物料在四张表里都维护了价格系统按优先级取第一层的“销售组织分销渠道物料”第一层没有记录才下探到“销售组织物料”以此类推。实际项目里的定价配置常见做法是搭出“客户物料”“物料”“物料组”这样的层级让特殊价格覆盖通用价格。要注意的是优先搜索不等于只用第一张表它只决定命中顺序哪张表没有记录系统就会继续往下找。这里还有一点容易被忽略创建价格主数据时弹出的关键字组合列表顺序与存取顺序里的条件表顺序一致。维护人员如果对存取顺序不熟悉可能把专享价维护到了通用价格的表里导致价格被其他记录覆盖。4.3 “排斥”标识命中即止避免多价格叠加存取顺序里的“排斥”标识作用是在系统成功找到某个表中的条件记录后不再继续搜索后面的表。这个字段必须正确勾选否则系统会把所有层级的有效条件记录全部找出来同时作为定价元素表现就是订单里出现多行价格金额被重复叠加。这里有一个文档里提到的例外情况条件排斥组。当多个条件类型被分配到同一个条件排斥组时系统会在它们之间启用互斥逻辑即使某个存取顺序没有勾选“排斥”也会按排斥组规则只取其中一个。处理返利、促销价这类多个价格并行存在的业务时条件排斥组有时比单纯调整存取顺序更有效因为它解决的是多个条件类型之间的互斥关系而存取顺序解决的是单个条件类型内部多张表之间的优先级关系。5. 定价排错从销售订单反查存取顺序与条件记录5.1 用 VA03 定位定价行的取数来源遇到订单价格不对先打开 VA03 进入定价视图逐行看每个条件类型是怎么取到值的。系统会用图标标识条件行的来源来自条件记录、来自手工输入、来自主数据复制。要快速检查 PR01 的取数路径可以在定价行上使用分析功能查看折扣金额计算过程系统会按步骤列出行项目金额的每一层来源这个分析界面会把存取顺序命中了哪一层条件表直接展示出来远比在后台配置里猜要快。如果分析界面显示条件记录命中的层次和你预期不符比如你以为使用的是“客户物料”层价格实际命中的却是“物料”层价格问题就锁定在存取顺序的优先级或条件记录的维护层级上直接回维护条件类型和存取顺序即可。5.2 手工价格与自动带出冲突时的处理价格异常还有一种常见场景VK11 维护了价格订单里也带出来了但用户手动改了价格后续折扣全部按手工价计算结果和财务预期对不上。遇到这种情况先查人工标识和“必需”标识的组合。人工标识勾选后条件类型不允许自动带出必需标识勾选后要求条件必须有值两者的组合决定了订单保存时系统是放行、警告还是报错。实际项目里控制订单价格修改权限通常不是只靠定价过程配置还会配合订单类型、用户权限、增强校验一起做。但定价侧的底线逻辑要清楚哪些条件类型允许手工改哪些必须锁定这些在定价过程的“人工”字段就要定义好否则后面做的任何控制都会被绕过。5.3 最后再确认一次条件类型与业务场景的匹配做完所有检查还有一个容易被忽视的定位问题你的物料金额到底按含税价维护还是按净价维护。长城公司这类以 PR01 含税价格为主的场景系统的定价过程和条件类型都围绕含税价搭建如果业务上需要在销售订单里以物料净价维护金额定价过程里就要配置 PR00 这类条件类型而不是继续沿用 PR01。这个差异不只是选哪个条件类型的问题它还牵涉税、折扣、返利的计算顺序和过账科目在项目蓝图阶段就要定下来。在排错时确认业务口径与条件类型是否一致往往是最后一个缺口。本文还有配套的精品资源点击获取