近几天做门店团购销售订单上传SAP接口程序，SO创建测试过程中， 遇到定价问题，同事在定价过程的增强过不了。

VOFM

了解到定价过程是个非常复杂的环节，此处出现程序处理过程中

ZMP0定价条件下的价格扩大1000倍。

【转http://blog.sina.com.cn/s/blog_6632b9a90100timn.html】

MM采购定价

假设企业采购某物料10吨，1000元/吨(增值税率17%)，其中运输增值税发票100元(税率7%，其中100/(1+7%)=93.46进入存货成本)，商检费20元，代理报关费用50元。

则收货材料入库成本为。

Dr：原材料 10163.46元

Cr: GR/IR 10000元(对应材料采购金额,材料供应商)

运输费 93.46元(100元运输费应入存货成本,另6.54为可抵扣进项增值税,OBYC->ZM5,对应运输商)

商检费20元 (OBYC->ZA5,对于商检队)

代理报关费用50元 (OBYC->ZA6,对应代理报关行)

对于这附加费用,也可使用默认的过帐码,比如一些人喜欢将所有采购附加费用条件类型全部对应到默认的Account Key FR1并且这些采购附加费用科目都对应到GR/IR科目,则上面的分录为:

Dr：原材料 10163.46元

Cr: GR/IR 10000元(对应材料采购金额,材料供应商)

GR/IR 93.46元(100元运输费应入存货成本,另6.54为可抵扣进项增值税,OBYC->ZM5,对应运输商)

GR/IR 20元 (OBYC->ZA5,对于商检队)

GR/IR 50元 (OBYC->ZA6,对应代理报关行)

虽然报表上可通过条件类型获得采购附加费用,但远不如科目直观。

在实务中，往往运输费用，商检费和代理报关费用并不对应到具体单个PO，比如运输发票是月末才统一开来，此时这些费用在收货时实质上是以计划应计值进入存货的，如果发票是下期开来，严格地讲会稍微影响材料成本。

图4-[6]：定义计价方案(define Calculation Schema)

系统已定义好一些范例计价方案，计价方案由一系列按一定规则组织的计价条件类型组成，针对本例，假设定义计价方案ZFRM01，包扩6个条件：

PB00：信息记录中的含税价格。

ZM01：通过计算类型增强909算出的应交进项增值税。

909增强代码如下表：

*909通过含税价格计算出采购净价，反应到条件类型ZM01上,注意XKOMV-KAWR表示

*条件基价(请SE11查看KOMV),即信息记录价格,比如信息记录含税价为1170元/个,则其中

*价外增值税为(1170/1.17得到净价)* 17%, 909考虑不同税率情况.

FORM FRM_KONDI_WERT_909.

CASE KOMP-MWSKZ .

WHEN 'J1'. "17％

XKWERT = XKOMV-KAWRT * 17000 / 117000 * ( -1 ).

WHEN 'J2'. "13％

XKWERT = XKOMV-KAWRT * 13000 / 113000 * ( -1 ).

WHEN 'J3'. " 7％

XKWERT = XKOMV-KAWRT * 7000 / 107000 * ( -1 ).

WHEN 'J4'. " 4％

XKWERT = XKOMV-KAWRT * 4000 / 104000 * ( -1 ).

WHEN 'J5'. " 5％

XKWERT = XKOMV-KAWRT * 5000 / 105000 * ( -1 ).

WHEN 'J6'. " 6％

XKWERT = XKOMV-KAWRT * 6000 / 106000 * ( -1 ).

WHEN 'J0'.

XKWERT = 0.

ENDCASE.

ENDFORM.

ZM05：通过计算类型增强908算出应计入材料成本的运输费用。

增强908代码简单，假设可抵扣运输增值税发票上是100元，由于是运输增值税为价内税(通常税率为7%)，则进入存货成本为100/1.07 = 93.46,可抵扣税额为6.54元,增强代码就一句 :

XKWERT = XKOMV-KWERT * 100 / 107.

ZA05/ZA06：对应本例的商检费和海关代理费用。

图11-[1]:Required如果选上则表示该条件类型必须在确定计价方案存在,比如采购单肯定得有采购价格条件类型,但是对该采购单可能不需要商检费用。

图11-[2]:表示该条件类型是统计性。

图11-[3]:可以在Reqt(Requirement)和计算类型(CalType)增强条件计算,这是系统计价魅力所在, 复杂的条件类型取数逻辑总可通过增强实现,系统还提供了Tcode:VOFM统一组织这些增强。

图11-[4]:通常如果条件类型设置了"应计"标志,在此为其设置记帐码,记帐码对应到科目,自动科目分配统由Tcode:OBYC统一设置,可以想象,在建立采购单时,后勤人员只需要关注条件类型就行,会计科目是自动带出的,我觉得,让并不精通财务的后勤人员直接选择科目是不明智的。

图4-[7]：定义方案组(Define Schema Group)

在一个大集团中，可能建立了很多不同的计价方案，典型地，有国内采购计价方案和国外计价方案，普通采购单和转储单计价方案，那么集团各种的采购订单如何确定计价方案呢？

系统提供了一个叫方案组的东西，可以为不同供应商或采购组织设置方案组，图12假设为供应商设置了M1-M3方案组，接下来将在供应商主数据的采购视图中设置方案组，如图13。

你还可为不同采购组织定义方案组。

图13中，供应商40114500对应采购计价方案组M1。

图4-[8]：定义方案确定(Define Schema Determination)

设置好计价方案和为方案组后，最后一步就是让采购单如何确定计价方案了，计价将系统的采购单分普通采购单和转储单(Stock transfer order，通常包括同一公司代码下不同工厂下的转储和同一集团不同公司代码下的转储)。确定计价方案配置如图14，很容易理解。

图14中，由采购组织方案组和供应商方案组联合决定计价方案，注意到采购组织方案组为空，实际上表示不设置采购组织方案组，也就是说，建立采购单时其计价方案直接由供应商主数据设置的供应商方案组(如图13)决定计价方案。

假设某集团设置了采购组织方案组A001(国内采购组织)和A002(国外采购组织)，供应商方案组设置了M1,M2,M3,则允许用户设置多达6种不同的计价方案,系统在为不同采购组织和供应商建立采购订单都能确定到，当然，实务上一般并不会出现如此多的个性计价方案。

现在为供应商建立40114550建立一个采购单，其计价方案如图15。

图15-[1][2][3][4[5][6]：首先，点击 [6]的“Analysis”按钮能发现供应商40114550建立的采购单(采购数量为10)的计价方案正是图14设置的ZFRM01，假设信息记录(Tcode:ME11)维护的价格为包含增值税的价格1170,通过增强909计算出的增值税为(1170/1.17) *17% * 10 = 1700元,对应条件类型ZM01，而采购净值(Net)为10000元。

ZM05为运输发票，100元自动计算出应计材料成本为100/1.07 = 93.46元。

ZA05为商检费，注意到ZA05/ZM05采购数量无关，检查条件类型Cond.class/Calculate type /Cond. category为A/B(fixed amount)/B，而假设报关费用和数量相关系，ZA06 Cond.class/Calculate type /Cond. category为为A/C(quantity)/B，表示费用和采购量相关。

图15-[7]：运输费用，商检费和报关费这些采购费用一般和材料供应商并不是同一家公司，

有时甚至连货币都不同，比如国外运输商要求用USD结算，所以可以按此按钮进去设置不同服务供应商。在后勤发票校验时，系统也可非常方便地分别为这些供应商确定应付帐项。

PO定价条件类型相关表格

EINA:(信息记录一般数据表)

INFNR:Pur info recd No.

MATNR:Material

LIFNR:VendorEINE:(信息记录采购组织数据)

INFNR:Pur info recd No.

EKORG:Pur. Org

ESOKZ:Pur info category

WERKS:PlantKONP:(Condition Item)

KNUMH:COndition record number

KSCHL:Condition type

KBETR:cond. Amt(rate wo scale)

KONWA:Rate unit

KMEIN:Condition pricing unitKONH:(Condition Header)

KNUMH:Condition record number

KOTABNR:Condition table

KSCHL:Condition type

DATAB|DATBI:Valid from|Valid toA017:(工厂级信息记录,对应存取顺序0002),其它的A***表

KNUMH:Condition record number

KSCHL:Condition type

LIFNR:Vendor

MATNR:Material

EKORG:Pur.Org

WERKS:PlantKONV:(条件交易数据表)

KNUMV:No. of doc. cond.

KSCHL:Condition type

KBETR:Cond. amount

WAERS:Currrency

KMEIN:Pricing unit

KVSL1:Account key

KVSL2:Accr/prov. account key

LIFNR:vendorEKKO:采购订单header表

KNMUV:No. of Doc. cond.

EBELN:PO No.KONM:条件等级价格表

KNUMH:Condition record no.

KSTBM:Condition scale qty

KBETR:Rate(Condition amt)EIPA:订单价格历史:信息记录

INFNR:No. of pur. info record.

EBELN:PO doc No.

EBELP:PO item

ESOKZ:info record category

EKORG:Pur. org

SD销售定价

MM/SD销售定价原理相同，下面简单叙述下SD的定价和计价确定

图1-[1]:定义定价条件表

Tcode: SE16:V_T681F|V/03|V/04|V/05

在此步你可定义SD定价允许字段和自定义条件表,请看本篇的SD定价实例.

图1-[2]:定义条件类型

Tcode: SE16:V_T685A|SE16: V_T685Z

和MM一样,一般是比如你为销售定价PB00定义一个参考价格ZPB0什么的,只是参

考程序在SD选V而MM是选M的,如需要设置条件类型的上下限(在VK11时输入的条件值就会受限制).

我记得在MM的info record PB00比如设置了上限100HKD,下限50HKD,这样在ME11

时PB00就只能在50<=X<=100取值.但是如果PB00是允许手工更改在Po condition

里手工输入的值并不受这个范围限制,估计SD的一样,留点东西给读者自行测试.

图1-[3]:定义存取顺序

Tcode:SE16:V_T682

和MM一样,实际上所有的使用到条件技术(MM定价|SD定价|Tax|output|costing sheet

甚至SD的收入科目确定)的东西都共用了一些相关表格和程序,所以说condition非常

简单,一通百通.

:定义和分配计价过程

在MM模块的定价中,我们是先定义方案组(schema group),方案组可以是vendor和采

购组织,然后根据方案组为标准PO和转移单分配计价方案(Calculation Schma).

显然SD的定价非常灵活但是只要掌握也很简单，实际中也不过是copy几个东西而已,SAP项目实施最后配置不就是按实际业务copy来copy去的吗?

简而言之, SD的计价过程由(1)customer(Pricing procedure assigned to this

customer)(2)sales document type (销售订单类型)(3)sales

area(销售组织+分销渠道+division)三部分决定,这是什么意思呢?如上图3.

图3-[1]:定义customer pricing procedure,你在客户主数据的sales area data的sales

tab页的Pricing/Statistics的Cust. Pric.proc栏位填写.

图3-[2][3[4][5]:定义document pricing procedure,在图3-[3]对应到销售订单和billing类型.

图4是一个合成图,假设我开了个sales order type OR的销售定单,客户是1,item

category是TAN. 你从下面三个步骤去理解计价过程是如何由customer|SO type|Sales area决定.

(1):图4-[5][7]我们知道客户主数据sales area data的prcing statistics的cust.

Pric.proc.是1,

(2):图4-[1][2][3][4]我们定义了sales area

5100|80|10,对于A(因为我开的是OR类型销售订单,从上图3-[3]我们知道OR对应的doc

pricing是A),customer pricing

1的定价过程是RVAA01,销售价格condition默认是PR00 .

(3):你从图4-[9]的那个⑤按进去就能看到condition明细,在condition屏幕点击图4-[10]的那个Analysis按钮,就能知道的确我没有蒙你这个销售订单的pricing

procedure是RVAA01.

练习:

现在假设你使用XD02将customer 1的Cust. Pric. Proc.

1改成我定义的Z,然后再开一个刚才一样的销售订单,将会有什么结果?

是的,系统会告诉你没有计价过程,因为在图4-[1][2][3][4] Define Pricing Procedure

Determination时我并没有为sales area 5100|80|10, Do Pr A, CuPP

Z定义一个计价过程.

从上面的描述里,可以知道SD的定价过程比较灵活.

如果你的pricing procedure 没有,请用OVKK检查.

图1-[5]:define pricing by item category.

图5-[1]表示item category为TAN的必须确定销售成本(通常是VPRS conditon),我们还看到即使是free of charge

item TANN也要确定销售成本.

什么样的销售订单的行项目不要确定成本,典型的比如寄兽发货的KAN(consignment pick-up),KBN(consignment

fill-up)和文本行项目G2TX(text item).

*关于寄售请参考本书的SD寄售流程.

图5-[2]表示item category为TAN的行项目允许直接带出销售定价condition type

amount(如果VK11维护了的话),TANN则没有(free of

charge当然不需要销售价格条件).

图1-[6][7]:定义计价相关的主数据字段和condition负责员工.

假设你的SD定价过程的condition type是PR00对应的access sequence是PR00,你看一下access sequence

PR00可以发现有一些AcNo(Access No.)使用了price list,material pricing group.

如果需要更细的销售定价或分类,你可以自定义包含price list,customer pricing group(Customer主数据 sales

area data 的sales tab页定义)和material price

group(在物料销售view定义)的条件表,将这些条件表加入销售定价condtion type使用的access sequence.

决定SD pricing procedure的是三个条件:sales area |Sales order type(对应docPr)|Cupp.

Price list,pricing group,material pricing group你可用于建立一些自己的condition

table然后加到销售定价条件比如说PR00的存取顺序让销售定价更灵活点而已.

PR00只是SD pricing procedure的其中的一个销售价格条件而已.