SAP+Condition技术用在MMSD.docx
- 文档编号:8727811
- 上传时间:2023-05-14
- 格式:DOCX
- 页数:32
- 大小:1.20MB
SAP+Condition技术用在MMSD.docx
《SAP+Condition技术用在MMSD.docx》由会员分享,可在线阅读,更多相关《SAP+Condition技术用在MMSD.docx(32页珍藏版)》请在冰点文库上搜索。
SAP+Condition技术用在MMSD
SAPCondition技术用在MM&SDPricing(定价)/Discountsandsurcharges(折扣和附加费计算)/Taxes(计税)/Output(OutputMessage又包括Print,EDI,Fax等)/Costingsheet(成本核算单)等配置上(关于condition技术的各种应用请看本书的相关部分),甚至SD的收入科目确定都依稀能看到condition技术的痕迹.
一个做MM的坛友说PO定价相当复杂,你要我怎么说呢?
实际上Condition配置基本上是SAP最简单的配置之一,因为只要你学会了其中一种,其它的自然就迎刃而解了.
讲一个我的故事,一堆人开会讨论一个新的定价,外包PO取公司提供的材料的一定百分比(OHrate)做componentOH,加上外包费(PB00)乘一百分比(OHrate),再加上产权费计入外包物料(详请看本书的SAP的委外处理),会议实在是开的太多,那此会议有太长,结果我睡着了,睡着也不打紧,可我打鼾了,打个呼噜本也无伤大雅,可老总让我发言时我睡眼朦胧站起来一脸口水,也是,就一个小小的定价还用浪费时间搞这么久,后来碰到类似问题,我总说拜托各位先讨论完毕要怎么定价最好将需求搞的BT些才通知我,定价这东西本来就简单不要老是没等我动起手来一下就搞完.
在本篇中,Condition和pricing是同一个概念,就不再解释.
图1-[1]:
企业通常不希望PO的采购价格直接在POitem中输入而从inforecord中带出来,此
时我们可以使用(SE16:
V_162)将ME21N的layoutselectiongroupquantityandprice组的price
andpriceunit设置成display.
关于inforecordchange不多说了,其更改记录可以通过ME14查看(你也可自定义report,关于
相关表格请看接下来的PO定价表格)
图1-[2]:
空表示建立inforecord可不指定plant,+要指定plant,就是说inforecord是plant级的如选择-表示禁止plant-level的,此时你只能建立purchaseorganization级的inforecord.
inforecord.
一个迷死你(MSN)朋友说,老付你写的东西有点难懂,太着重技术了,所以就这个我要耐心地讲解一下,我向来非常有耐心的,用我家乡的土话说我可以坐在你肚子里慢慢教.
新建物料ZST_SUBCON是委外的(MRP2的procurementtypeFwithspecialprocurementtype30outsourcing,新建很重要以免可能已经有多个inforecord你搞不清楚状况,对于处理多个inforecord接下来会有讨论),假设plant5100|5200同属一个purchaseorg.5100,你将conds.atplantlevel设置成空,建立这么几个inforecord
(1)只输入purchaseorg5100不带工厂,然后使用CK11N去估算
(2)加上plant5100而5200不加,看CK11N结果.当然这个不是我做我对这个已经很了解了,有兴趣的读者自己去try,相信你马上几明白了这个设置的意义.
热身动作完成,开始介绍PO定价,POpricing用到的condition技术非常简单,一般的全部步骤是8步骤(其中有些可能你企业可能并非必需比如[1][3][5]),如图4:
图4-[1]:
扩展条件表字段
SAP定价条件表字段组合非常灵活,你可根据采购组织合同(agreement)供应商物料组物料等等字段自由组合定价.也就是说POheader,POItem等表(EKKO,EKPO,EKET中的字段基本可用来做条件字段).
如果你的定价比较复杂,可以使用自定义字段甚至你自己定义的表中的字段(通常你可以使用SMOD:
MM06E005激活PO屏幕增强SAPMM06E,在该屏幕上输入数据到自定义表中,这些屏幕激活后通常将作为POheader|POItem最后一个Tab页名称叫CustomerData页,如下图6-[3],更详细请看本书相关部分)
大都数情况下并不需要增加额外的条件字段,如何增加条件字段呢?
请看图4-[E]的SystemEnhancement的帮助文档.
一个企业用户说,我们把PurchasinggroupEKGRP对应成采购部的Buyer,现在定价条件需要为同一物料不同的buyer设置不同的采购价格(Itemcondition),可是如果你稍有ABAP知识,你应该知道采购组EKGRP是POheader表EKKO的字段,如果你需要将它用语用于POItemcondition,为此需要先在KOMP和KOMG(SE11,可能你需要申请传说中的Accesskey)俩个定价结构中增加同时ZZEKGRP字段.
如图5-[1],按SAP的说法,你必须在字段面前加上ZZ做前坠,现在purchasinggroup就能用于POitemcondition了,在图5-[2]中另定义了ROUTE(STOItemshippingdata表EKPV-ROUTE字段)作为整单TransferorderPOheaderconditioned定价字段(只有STO才会有shippingTab页才可设置Shippingroute,如图6-[1][2],关于STO处理请参考本书的PO相关配置),对transfer到不同地方的PO设置一定价条件(关于Shipping和routedetermination请参考本书的LogisticsExecutionIMGpath下的shipping和routedetermination相关配置.).
同样,如果你要将某自定义字段用于POheadercondition,请将该字段使用SE11同时加如结构KOMK和KOMG调整.
最后你需要稍微写一点东西,SMOD->LMEKO002(exitfunctionEXIT_SAPLMEKO_002,如是Headercondition,enhancement是LMEKO001),在function中写入下列代码,就两句.
MOVEI_KOMKTOE_KOMP.
MOVEI_EKKO-EKGRPTOE_KOMP-EKGRP.
你根据实际业务决定你是否需要自定义价格条件字段.
图4-[2]:
建立条件表
建立条件表很简单,只要将所需要的条件字段选到坐标就可以,如图7,我建立一个条件表990.
图7-[1]生成条件表A990(SE11,Condition表都以A开头),在A990中我使用了自定义的条件
字段ZZEKGRP.
图7-[2]可不断点击Otherdescription知道出现的是选择的条件字段描述是字段名称,这样比容易理解
图7-[3]增减字段,但是当条件表已经生成一般就不允许再增减条件字段的.
图7-[4]给条件表一个描述,如是灰的按它切换图7-[5]选择的条件字段
*以后MEK1输入的相关的PO条件记录就保存在此表中.
图4-[3]:
定义存取顺序
什么是存取顺序,怎样的条件类型才要存取顺序呢?
存取顺序是帮助找到某条件类型的有效条件记录的一种寻找策略.
如图8,讨论下采购价格conditionPB00(可能你家并不叫PB00,以后就不再区分)的存取顺序0002.
图8-[3][4]:
存取顺序号称|相应条件表
图8-[5]:
|我们知道condition技术不仅仅应用于MM/SD定价所以requirement在多方面也应用,Requirement表示需要什么条件(关于requirement本书有专门讨论),使用Tcode:
VOFM能看到condition技术的各种requirement的应用,你从Requirements菜单->Pricing可看到各种定价使用的SAPdefaultrequirement.
典型地,我们在inforecord中输入PB00condition对应的是图8的第25行表
A017requirement是35.代码如下:
formkobed_035.
sy-subrc=4.
checkkomp-no017eqspace.(如果inforecord读到价格数据返回成功)
sy-subrc=0.
endform.
图8-[6]:
Exclusive,只要抓到一个价格,就不往下继续寻找条件价格记录了.
如果你使用MEK1输conditionPB00的价格数据时实际上这个整是你看到的key
Combination,你MEK1建立PB00并不意味你就建立了inforecord,因为inforecord还包括其它采购数据信息并不仅仅是一个价格(更详细请看接下来的实例).
什么时候需要为conditiontype建立存取顺序?
如果企业不希望用户直接在POitem更改价格,假设我们使用PB00做inforecord的condition,设置存取顺序0002后,PO价格就能将这预先定义的价格直接带到POitem.
我们再将PB00的Manualentries设置成D,PB00就不能输入了,在将POitem的screen的price设置成display,这样要更改PO价格你就必须找有权限建立inforecord的user.
思考:
如果采购conditiontypePB00不建立存取顺序,开PO时还能自动带出采购价格吗?
图4-[4]:
定义条件类型
以为著名的采购价格条件类型PB00为主题讨论一下conditontype是怎么回事?
其存取顺序是0002,而另一个SAPdefault的PBXX没有设置存取顺序.
图9-[1]:
表示PB00的获取是按一定的顺序策略从相应的条件表中取得维护的条件记录,详细请看接下来的accesssequence讨论.
图9-[2]:
表示PB00是价格条件类,表示是基于数量计算的.如果你的价格是基于重量的,可是物料基本数据是PC,你可以选D,如果你这样做可能在开K类PO时会有点小问题,你可能需要重写requirement,我测试过一次是这样的.
图9-[3][8]:
感觉将这[3][8]两项连在一起有点那个.如果你看FRA1(FRA2)-FRC1(FRC2),这块是B表示deliverycost,同时和图8-[8]应计连在一起(选上)表示该condition是运输费类条件类型,并且需要设置Accountkey(会计科目OBYC->你定义或SAP已存在之T/EKey).
你根据实际需求参考copy出所需要的deliverycost或其它类condition,如果需要在PO能default带出,你可能需要建立条件表和自定义的存取顺序,你还可决定是否需要为该condition建立对应会计科目(通常是应计类科目,请看接下来的定义T/EKey).
*如果你使用B类deliverycostcondition在计税方案未设置accountkey在PO中会有错误
提示.同时在MIRO时你可专门对planneddeliverycost进行发票校验.
图9-[4]:
PB00采购价格condition的Manualentries设成D不能手工输入,同时在PO屏幕设置将item的price也设置成display(请看本书相关配置部分),这样采购价格就只能从infoRecord带出,传说这对采购价格管理价格很有效.
图9-[5]:
item级的condition,同时允许你在POitem的conditionlist删除它,不勾就表示不
可删除.通常采购价格condition比如PB00在计价方案会设置是强制必输.
图9-[6][7]:
表示PB00是采用数量类等级价格,比如vendor规定1-100个某料1.00USD/PC,101-500个0.95USD/PC诸如此类的等级价格,另外一个比较实际的例子是采用日期型的等级价格,不同的时间(可是周月旬)给你不同的价格,如果需要你可以自定义等级价格的公式.
你可以从表KONM中读到这些数据,关于conditiontable关系请看接下来的实例.
图9-[9]:
SAP的帮助举了一个实例,物料A,B同属一个materialgroup01,MaterialA100个,MaterialB150个,假设vendor给定1个1%折扣,100个开始给2%折扣这样一个价格等级,A+B=250个,享受2%折扣,如果它不work,不要紧,后面不是有个
Groupcondroutine吗?
自己定义程序逻辑,根据实际业务想咋的逻辑就咋的,SAP不也是代码堆出来的吗?
图9-[10]:
你可使用Rererenceconditiontype,在SD定价中设置了ZPR1的referenceconditiontype是ZPR0,这样VK11只要维护ZPR0就行,K,跳到SD干啥呢?
我的意思MM定价和SD定价原理基本完全大概都一样.
图9-[11]:
如果有必要,你可以将折扣附加费海关运费和PB00使用同一个附加计价方案,SAPdefault的RM0002,这样在维护PB00时,你可同时在此维护这些condition,如图10,FRA(B)1-FRA(B)3是无accesssequence的,这样做的好处是这些condition不用使用accesssequence而在开PO时间也能自动随PB00带出(捆绑在一起同一inforecordnumber嘛).
非常遗憾的是,这样做可能不到好,因为inforecord的PB00通常是针对某物料某vendor某pur.
Org而且某plant的,而通常运输费海关费是只根据国家代码运输Route制定计划价格,所以通
常还是建立accesssequence然后MEK1维护计划价格(更详细关于运输海关费处理请看本书
相关部分).
上面只介绍最常用的几个字段意义,比如还有plus/minus字段,通常一些折扣折让类的是X表示输入内容会自动变成负数,其它字段在本书的SD的定价部分也会继续讨论到.
(1)Inforecord和POconditionrecord的关系
图例1是个合成图,虽然我知道这图搞的不怎么帅,由于能说明问题我还是将它贴上来了.
inforecord是某一物料对应某一vendor的采购信息源.
一个inforecord通常包含最少一个代表(如图例1-3包含了3个conditiontype)
常用Tcode:
ME11(Create)/ME12(change)/ME13(display)/ME14(changes)/ME15(设删除标志)
/MEMASSIN或MASS大批处理.
Inforecord查询:
ME1L(byvendor)/ME1M(bymaterial)/ME1W(bymaterialgroup)/ME1P
ME1E(pricehistory).
(2)POheadercondition和Itemcondition
什么是headercontiion,假设实际业务是供应商就整单PO给你打个折,你定义一个headercondition,因为你在POheader输入的headercondition会自动写入个POitemcondition,同样各POitem的condition会自动汇总到POheadercondition数据里作为整单的condition汇总,这样假设你给一个有5个item的PO一个100RMB的折扣时,注意在
假设因为是从Itemcondtion带过去的,假设PO有俩Item,一itemPB00价格是100USD,另一itemPB00是150USD,在headercondition看到的PB00是多少呢?
250,就是说headercondition包含的是各lineitemconditon的总和再加上本身可能的headercondition比如上面所说的整单PO打折.
图4-[5]:
定义TEKey
什么时候我们要在PO计价方案(calculationschema)为conditiontype定义一个Accountkey呢?
图4-[6]:
定义计价方案
图4-[7]:
定义方案组
图4-[8]:
定义计价方案决定
复习:
1自定义的conditionfield必须在KOMG和KOMK/KOMP(SE11)同时加入才可在conditiontable中使用
2condition配置包括定义conditionfield,然后由这些字段组成conditiontable,MEK1等输入后保存的叫conditionrecord,有些conditionrecord要建立存取顺序,有些不需要,存取顺序是用来按一定规则读取conditionrecord的,Calculationschema是PO如何计价的,它包括一系列conditiontypes,最后需要将calculationschema分配个PO,仅此而已,很简单吧.
3Requirement用在多中地方,举一个实例,有的企业可能SDbilling的产生是后台跑Job现在希望在VL02N后不立即产生销售收入,如是VL02N(除了各种免费的SO)后台不立即产生销售收入,我想除了做一些配置外使用requirement是很容易做到这点的.
4.读者可能很想知道如何配置+Exit来折腾一个最后采购价格,我不告诉你们.
下面让来说明下图1A-G.
[A]plant级的condition控制
[B]控制某conditiontype的最低最高pricingamount
[C]根据采购组织供应商定义(计价)方案组(Schemagroup)
[D]如图8,1[C]定义的方案组,这是为标准PO的,0001组的标准PO采取的Proc.是RM1000,其他的不在此组的是RM0000,这是SAP标准的,实际业务你可能copy出的是ZRM0000.
至此,就将PO的取价和condition配置挂上钩,对于Stocktransferorder有专门的一刀.这方面的业务相对有点复杂,在此就不细述.
[E]说下定义Transaction/Eventkeys,假设我定义了ZF1-ZF3和ZST,如图9,在OBYC就可看到它们,刚才有读者反应说FR1-3不好玩,就Copy了ZF1-ZF3,顺便跑到图7将它们换掉就可,我举这个例子的意思很明显就是不使用形而上学上学的观点去理解OBYC.
[F]在计价方案(CalculationSchema/Procedure)中根据某些条件排除那些conditiontypes.
[G]仔细看看这个帮助文档吧,它详细介绍了如何使用Exit增强Conditionfield,是的,你另外的加入的conditionfield必须写相应的Enhancement程序,
如图7就以RM0000为例,因为在SAPdefault的schemadetermination中PO的定价就是使用了它,实施项目中copyRM0000出来在根据实际业务更改然后分配个标准PO,至于Transferorder(包括公司间或集团内跨公司的)可参考RM2000.
1.ProcedureRM0000,2图7只截取了部分conditiontype,PB00的Mdt打了勾表示在PO的condition(PB00是itemcondition)中POitem必须包含它,3From/to表示此conditiontype或实际价格从哪行到哪行,To是0,或空表示只使用from行,让我们看11,actualprice表示从22(鉴于篇幅图7中被隐藏)行计算到39行,4表示此conditiontype的价格是手工输入的,很显然这些conditiontype通常也就没有必要建立存取顺序然后麻烦你使用MEK1去维护它5表示此conditiontype是用来做统计和管理目的用的,不反应在财务上,将来可使用它做些相关report,6再看11,这是一个subtotal的标志,S表示这个统计的价格将反应在KOMP-EFFWR字段,KOMP我们知道是POitemcondition的一个structure,至于保存在什么,在复习篇中将重点讲述,7又是使用requirement,在此就不再细述8910是和OBYC相关的,打开tcodeOBYC你看到的transaction(所谓的Transaction/EventKey)中有FR1-FR3,RUE,B01,而Accountkey就是Valuationmodif.,好了现在有个问题,有的企业要求在POcondition中将运输费(我想分离出7%的低减增值税额的配置也很简单),包装费,报关费等在MIGO,MIRO能对应到一一相应的费用科目,OK,就是在此设置,你甚至可在OBYC中定义自己的Transaction/EventKey,假设你觉得FR1-FR3不好玩,就定义ZF1-ZF3将他们退换就可,我说这个的意思是,很多人理解OBYC中的Transaction/Eventkey是死理解的,这种思路要换一下.如何定义,请看图1EdefineTransaction/EventKeys,11PO通过各种计算得出的实际价格.
PO定价条件类型相关表格
用于定价的一些结构KOMK(Header),KOMP(Item),KOMG(Conditionallowedfields)
如果你做过CO,你使用OKKN曾想弄个最后一次PO采购价格的成本估算变式,你就可能非常烦恼inforecord究竟是怎么的获取逻辑,如果你对上面的几个小表的关系理解清楚就非常简单了.
MD,太没劲了,这么简单的东西浪费我宝贵的时间,不说了,做点正经事,下次继续,举TNND两火车皮condition实例..
编写用户增强
用户增强通常包括下面3类,顾名思义,就是增强SAP的可能没有提供的功能(通过后台配置也不能实现).
1.EEnhancementexits:
就是常说User_exit(用户出口)
使用SE37搜索EXIT*的函数大都是做exit用的,通常里面预包含了一个Z开头
的程序.SE16查询TFDIR(函数表)输入EXIT*也可.
2.CGUIcodes(GUI接口增强)
3.SSubscreens(屏幕增强)
Enhancement在表MODSAP可看到,而TFDIR字段MAND(值为C表示此出口函数被激活).使用SMOD(CMOD)当然可激活exitfunction,有时候一时难以查询到相关Enhancement时可使用下面程序将出口函数激活.
REPORTZactexitfun.
dataztfdirliketfdir.
*selectsingle*fromtfdirintoztfdir
*whereFUNCNAME=
*'EXIT_SAPMM06E_013'.
*ztfdir-MAND='C'.
*updatetfdirfromztfdir.
*将EXIT_SAPMM06E_013换成实际所需exit函数名
updatetf
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SAP Condition 技术 MMSD