16.3.2.           定价过程

16.3.2.1.       条件技术七要素

1.       条件字段（Condition Field）：条件表（A表）的关键字段，如客户、物料

2.       条件字段目录（Field Catalog）：条件字段的集合，也即AXXX条件表的关键字段，决定在不同层次上的定价

3.       条件表（Condition Table）：即AXXX表，包含一个或多个条件字段为关键字段，关键字段对应一个字段目录

4.       存取顺序（Access Sequence）：存取顺序中包含一个或者多个条件表，多个条件表时需指定读取这些表的顺序

5.       条件类型（Condition Type）：条件类型即条件分类，如计算价格的PR00、计算折扣的K007、计算税额的MWSI

6.       定价过程（Procedure）：由多个条件类型组成，每个一条件类型就是一个定位步骤

7.                定价过程确定（Procedure Determination）：根据销售范围（销售组织+分销渠道+产品组）、客户、订单类型来确定

当创建销售订单时，系统首先确定定价过程，再根据定价过程确定需要的条件类型，然后订单中条件类型（如销售折扣K007）就根据存取顺序在条件表中读取相应价格主数据

16.3.2.2.       条件表V/03、V/04、V/05

  

自定义的条件表编号从600到999。定价条件表中允许的条件字段都来自于定价表KOMK、KOMP

16.3.2.3.       存取顺序 V/07

以PR00为例，该条件类型可根据三个定价的关键字组合（即对应三个条件A表）进行维护，系统则通过存取顺序确定三个条件表的优先级顺序，该优先级顺序称存取顺序（Access Sequence）。

图中存取顺序为PR02，系统按编号10、20、30、40依次读取条件表A305、A306、A304，系统最先读取305，即根据销售组织+分销渠道+客户+物料确定销售单价，图中字段“排斥的”钩选后表示如果在A305表中读取到了数据，则不再继续读取后面的A表

定价参数物料：通常来说定价参考物料等于销售订单中输入的物料，但也可在物料主数据的销售视图维护定价物料，定价物料的目的在于减少价格维护的工作量

16.3.2.4.       条件类型 V/06

条件类型重要属性：

l  条件类型（Condition Class）：定义条件类型属于单价、折扣、还是税收类型

l  计算类型（Calculation Type）：定义单价、折扣、税收是如何计算的

l  条件类别（Condition Category）：对于特殊类型的条件类型，系统预定义了条件类别，如对于条件类型 VPRS，其条件类型为G，因此系统自动根据物料主数据中维护的标准价格（移动平均价格）确定该条件类型的条件类型金额

16.3.2.5.       定价过程V/08与确定OVKK

1、  From ~ To步骤范围

作用：确定条件类型基础（Condition Base Value）

适用情况：仅针对计算类型为百分比的条件类型

逻辑说明：系统中提供三种百分比的计算类型，A（Percentage）、H（Percentage Include）、I（Percentage/travel expenses）。以计算类型A为例，其条件类型金额等于条件类型基础乘以百分数，而条件类型基础默认等于该条件类型的步骤范围内的条件类型的值的合计，当不输入步骤范围时，则条件类型基础等于该条件类型前所有步骤的条件类型金额之和

本例中，折扣的条件类型K007的计算类型设置为百分比，按图中配置，K007条件类型基础等于条件类型K007前所有条件类型的金额之手，即条件类型PR00的条件类型金额，具体为1600元，所以条件类型K007的金额等于条件类型基础（1600）*前台VK11维护的折扣率（10%）=160元。

若设置条件类型K007的步骤范围为“From 11 To 11”与不输入步骤配置时条件类型基础值是相同的

2、  Manual手工的

作用：确定条件类型是否在销售订单定价界面中自动出现

适用情况：无存取的条件类型

逻辑说明：图中一共长个条件类型，条件类型EDI1代表期望的价格，被标准为了“手工”，该条件类型没有分配存取顺序，所以此种条件类型不读取主数据（因为没有条件A表），而是在销售订单中手工输入

3、  Required必须的

作用：如果单据中条件类型没有值，系统数据检查时会提示

适用情况：任何条件类型

逻辑说明：定价类类型（Condition Class）为B（Price 单价）或者A（Discount Or Surcharge 折扣或附加费）的条件类型，必须维护相应的价格主数据，具维护值不能等于0；对于定价类型为D（Taxes 税收）的定价类型，只要维护相应的主数据即可，可以是零（表示无税收）

4、  Statistics统计的

对于一张销售订单来说，金额信息中最主要的是计算订单的不含税金额（Net Value 即净价值，下图中的Net字段）和税额（Tax Value，下图中的Tax字段），后续开票时，不含税金额将过账到账务收入科目，税额将过账到税金科目，二者合计代表着现金（应收账款）

系统将定价过程中的各个中满足下面三个条件的值纳入到订单的净价值（Net Value，下图中的Net字段）计算：

1、    条件1：该步骤勾选上统计，如钩选统计，则代表该金额不纳入净价值

2、    条件2：该步骤存在条件类型。如下图（VA03）中的最后一个步骤“Test Only”不存在条件类型，因此尽管未被勾选统计，但系统也不将该步骤的值纳入净价值中。不存在条件类型的步骤，系统一律认为是统计性

条件3：该步骤的条件类型的定价类型（Condition Class）不是“税类型D”（Taxes：税收）。如上图中的MWSI，虽然未勾选统计，但系统也不将它纳入净价值统计

5、  subtotal小计

小计即将步骤（条件类型）的值或者价格赋值到小计中，不同的小计有不同的用途，有些小计可以用来做后续的计算，有些小计的值将会保存到数据库中。上上图中条件类型PR00的小计被设置为5，表示小计对应字段为KOMP-KZWI5，KOMP-KZWI5的金额等于条件类型PR00金额，当销售订单保存后，VBAP-KZWI5的值等于KOMP-KZWI5

下面列举了定价过程中预置的22个小计，并对这些小计做了简单分类，划分为四类型：

第一类：不可以随意使用，系统已经赋予其特定含义。该类小计的值最终都会保存到VBAP相同名称的字段里

第二类：系统预留的，可根据公司需要赋予特定含义。这6个小计的值最终都会保存在销售订单行项目表字段VBAP-KZWI1 ~ VBAP-KZWI6中。如可设置小计1用来记录领导审批的折扣金额，小计2用来记录客户期望价格

第三、四类：系统未赋予特定含义。这两类小计字段值不会保存到数据表中，仅作为中间变量使用，是为了定价过程中进行一步计算使用。其中第三类小计是将步骤的条件类型金额赋值到小计中，第四类是将条件类型价格赋值到小计中

6、  Requirement需求

条件类型生效的前提条件，可以写自定义的程序来定义条件类型生效的前提条件，系统也提供了很多程序可供选择。查看程序代码：

 

7、  Condition Value Formula条件金额公式

通过该字段主要用来改变当前条件金额的值（字段XKWERT），也可同时改变当前条件类型的其他字段的值，如条件类型价格。

条件类型NTPW（含税金额）等于折扣前含税金额减去折扣金额，因此系统将条件类型（PR00）含税价金额复制到小计字段5（KOMP-KZWI5），将条件类型折扣（K007）的金额复制到小计字段（KOMP-KZWI6）中，同时该条件类型NTPW条件金额公式的例程设置为81，下面是例程81源码：

在程序81中定义了条件类型NTPW金额（XKWERT）等于小计5（komp-kzwi5） + 小计6（komp-kzwi6），同时在程序还根据条件类型NTPW金额计算得到该条件类型价格（XKOMV-KWERT）

8、  Condition Base formula条件基础公式

与条件金额公式类似，主要是通过例程来改变条件类型基础值

9、  Acckey和Accruals账户码和应计项

通过定价过程的账号码（Account Key）和应计码（Accrual Key）实现与销售开票时的会计科目的确定无缝集成，实现收入、折扣、成本、税额进入各自的会计科目

销售开票的会计科目确定一般由6个条件字段确定，销售组织、分销渠道、产品组、客户的科目分配组、物料的科目分配组、账户码（应计项），其中客户科目分配组由客户确定，物料的科目分配组由物料确定，而账户码（应计项）则由定价过程中的定价类型确定

另外，凡是纳入销售订单净值计算的条件类型都必须有对应的账户码

16.3.2.6.       VK11：价格主数据维护

通过VK11维护条件后，数据存放在对应的条件AXXX表中

 

 

16.3.2.7.       定价计算：KONV

系统根据定价过程，并结合价格主数据（AXXX表中的数据）计算得到条件类型金额，并将条件类型单价（KBETR）、条件类型基础（KAWRT）、条件类型金额（KWERT，计算结果）一并存放到KONV表中

下表为最终KONV计算结果：

注：为了阅读方便，本表做了适当加式，如对于百分比的条件类型MWSI，表中实际存储的为170，而非17%

KONV-KBETR：从价格主数据（AXXX表）表中读取得到

KONV-KAWRT：部分条件类型（如折扣、税）是根据定价过程定义在创建订单时动态计算得到

KONV-KWERT：以KBETR、KAWRT为基础，并通过相应的计算公式计算得到，该字段即为最终计算出的定价结果

 

创建销售订单时，条件屏幕的字段在内表XKOMV中，最终内容将保存在数据库表KONV中，VBAK与KONV通过KNUMV（条件记录号）进行关联（注，只有VBAK里才有KNUMV，VBAP里没有，因为一张单就只对应一个定价过程，所以整张单只需一个KNUMV，与Item无关）

16.3.2.7.1.              条件类型的计算公式

条件类型金额的计算公式三要素：

1.         条件类型价格[Rate（condition amount or percentage）]：如单价（800元/个）、折扣（10%）、税率（17%），来自VK11所维护的价格主数据

2.         条件类型基础（Condition Base Value）：如数量（2个）、折扣前金额（即销售金额 1600元），部分条件类型（如折扣、税）是根据定价过程定义动态计算得到，一般为前面几步条件类型统计结果

3.         条件类型金额（Condition Value）：以条件类型价格和条件类型基础为基础计算出来的金额，如含税金额1600元、折扣160元

条件类型金额是以条件类型单价、条件类型基础为基础，通过某个公式计算得来

 

根据条件类型的计算类型，条件类型金额有不同的计算方式，最常用的三种计算方式：

1.         条件类型中的计算类型KONV-KRECH为C（数量）：条件类型金额 = 条件类型价格（单价）* 条件类型基础（数量），如销售金额PR00的金额等于单价800元/个 * 数量2个 = 金额1600元

2.         条件类型中的计算类型KONV-KRECH为A（百分比）：条件类型金额 = 条件类型价格（百分比）* 条件类型基础（金额），如折扣K007的金额等于10% * 1600 = 160元

3.         条件类型中的计算类型KONV-KRECH为H（包括在内的百分比）：条件类型金额 =条件类型基础（金额）/（1+百分比）*百分比，如税收MWSI的金额等于1440/(1+17%)*17% = 209.23元

16.3.2.8.       定价过程示例

其中NTPW（含税金额）的条件类型价格 = 1440 / 2 = 720 ，NTPS（不含税净价）的条件类型价格 = 1230.77 / 2 = 615.385

 

另一个自己设计的定义过程：

16.3.2.9.       销售订单中的定价示例

销售单价：800元                                                折扣：10%                                                     税率：17%

最终销售含税金额：1440元                           不含税金额：1230.77                               税额：209.23

注：上图中的条件类型NTPW、NTPS描述错误，应该分别为含税金额和不含税金额，弄反了

销售订单的净值（实为NTPS条件类型的KONV-KWERT的值）和税额（实为MWSI条件类型的KONV-KWERT的值）还存储在了销售订单行项目表VBAP-NETWR与VBAP-MWSBP中（还有一个VBAP-NETPR净价（实为NTPS条件类型的KONV-KBETR的值？），也直接存储在了VBAP表中）；

与之对应的采购订单的净价EKPO-NETPR、净值EKPO-NETWR也是直接存储在了Item表EKPO中了：

另外还有两个重要的字段：VBAP-KWMENG：销售数量、EKPO-MENGE：采购数量。（这两个字段实际上可对应到某个条件类型如PR00/NTPW/NTPS 的KONV-KAWRT的基础值?）

 

创建订单时，系统根据 销售组织+分销渠道+产品组+客户的定价过程+单据的定价过程 来确定一个定价过程，其中客户的定价过程在客户主数据（KNA1，XD03）中定义：

 

单据的定价过程（不同的单据类型有不同的定价过程）通过事务代码OVKJ分配给销售订单：

16.3.2.10.定价通信表KOMK、KOMP

系统通过两个表KOMK、KOMP为销售单与前台价格主数据、后台定价配置之间建立桥梁。创建订单时，系统首先根据销售订单中的信息为这两个表赋值，然后根据这两个表中的值确定销售单据中的定价，即这两个表起通信（Communication）作用

创建销售单时，会将VBAK中的部分信息赋值给KOMK表，VBAP同赋值给KOMP表

这两个表仅仅起通信作用，是销售订单维护时产生的两个内表，当销售订单保存后，表中的信息也会消失

 

定价表KOMK、KOMP的字段与VBAK、VBAP中的字段，大多相同，但并不是所有字段命完全相同，系统也并非根据字段名进行赋值，在系统内部有一套默认赋值规则

 

对于定价表KOMK、KOMP赋值是定价的基础，系统只是将部分信息赋值了，某些字段如物料主数据中销售视图下的物料组1字段MVKE-MVGR1就没有自动赋值过去，现在某个折扣需要根据物料组1确定，标准功能无法实现，原因是该字段的值系统没有将其复制到定价表KOMP中。此时首先检查该字段是否在表KOMK、KOMP中存在，SE11时发现KOMP中有同名字段MVGR1，此时只需要利用SAP系统预留的用户出口程序MV45AFZZ，在USEREXIT_PRICING_PREPARE_TKOMP FORM中加入以下代码即可：TKOMP-MVGR1 = VBAP-MVGR1.在创建订单时系统会自动将TKOMP-MVGR1原封不动的复制到表KOMP-MVGR1中。如果有相应字段，可通过SE11修改KOMK、KOMP表，修改时查找CI_ 开头的 .INCLUDE 结构可其他以Z打头的INCLUDE或APPEND结构