做顾问并不难,难的在于你很难找到一本真正结合IMG,操作和常用释疑介绍SAP的书,大家很想知道做顾问究竟需要多长时间, 我想,这和很多武打小说描述的一样,如你找到一本秘籍,三个月足够,尤其是对稍有点经验的SAP user来说.
CO-PC难吗?
说SAP博大精深和CO-PC难的可细分为三类:
第一类人是做IT的转做FICO,这些人缺乏甚至基本的财务专业知识.其实掌握一些常用财务知识并不难,
第二类人是做FICO的,他们缺乏对SAP CO-PC设计思路的认识,总以中国传统的成本会计理念去衡量,毕竟CO-PC有些方面是和中国传统的成本会计理念有出入的.
一个典型的例子,一个老CPA问我,为什么SAP要设置生产成本-WIP(P&L)和Inventory-WIP(BS),然后在OKG8还要弄一下,这不是脱裤子放屁多余吗?
实在找不到很好的解释,我只只能回答SAP是个软件它和人不一样,就算它设计比较活但它依旧是死的,为了程序设计的方便,它只好如此做.
第三类人是顾问们,我想这非常不应该,如果他们有这样的思想我想其中有两个原因,处于商业目的刻意渲染或者确实对CO-PC不自信.
我甚至认为很多的朋友在没有真正去研究过CO-PC之前思想就被传统的认识固化,就是认为CO-PC很难. 我在此送给大家一句调侃老话:薄记之作,雕虫小技.
对一个系统来说,既然它已经写好了,从哲学观点上看它的逻辑就是死的,尽管它可能提供很多变动配置,但整体讲,一旦配置固定逻辑就是死的,对于死的东西还有什么难学可言?
6.1 Product Cost Planning
6.1.1 Basic Settings for Material Costing
IMG Path 如图6.1.1-1,接下的17项配置6.1.1.1-6.1.1.17分别对应到图中Item.
6.1.1.1 Define Origin Groups
T-code: OKZ1 SE16: V_TKKH1
如图6.1.1.1-1,定义origin group,origin group通常在Raw material这层用,在能用上它之前,必须在cost 1物料视图中选上合适的origin group(另一个material origin的意思是如你不|忘记选,在分析cost est. 结果你将只能看到相关值而看不到此物料名称)
企业通常根据原料的属性或其它定义origin group,比如电子,五金,塑胶等,可将此
字段By material type(原料类设置为必输,对可能不需要的设置一Dummy origin
group.设置物料视图字段非常灵活可By plant,by material type,by industry,甚至by Tcode等,在MM配置有详细解说),Origin group用途:
1 用于更细By material origin Group分析物料成本,没有origin group,cost est.中只能得到总的物料成本.
2 用于成本核算单(Costing sheet)的calculation base和Credit中. 3 在定义成本组件(OKTZ)中将物料继续按origin group细分. 4 计算差异和WIP能By Originan group细分
如图6.1.1.1-2, 在CK11N后,[1]Org Gp,使分析料所承担成本更细(现在很容易知道电子,五金,塑胶等材料在料成本组成的百分比),[2]User-exit,在此将连接user-exit,其中可使用自定义程序, [3]Cost component View(在接下来的OKTZ中有详解),[4]Item Category,常用的M表示物料,E表示作业类型,G表示Overhead [5]Resouce是Plant+Material
1在6.1.1.1-2[2]中的user exit的三个user-exit名称分别是EXIT_SAPLKASC_
001-003,关于如何使用user-exit在附录中User-exit的使用将有详细描述.本书同时附代有一个简单的自定义程序.
2 6.1.1.1-2[3]中,选择1cost of goods Manufactured(以下简称CGM),2Cost of goods sold(以下简称COGS)和6 Inventory Valuation看到的数据可能相同,选择其他的cost component view通常没有数据(就是说M,E,G数据都是0),想想为什么?(请看OKTZ) 6.1.1.2 Maintain Overhead Cost Elements
Tcode:KA06 SE16:
没有什么特别,维护41->Overhead类型的次级成本要素 6.1.1.3 Define Costing Sheets T-code Se16:
什么是成本核算单(Costing Sheet)? 在理解它之前复习下成本会计的内容. 一.制造企业的费用按经济用途分:
1 期间费用:管理,营业(对制造企业即销售费用)和财务费用. 一定期间内发生的不直接归属于某特定产品生产的费用.
2生产成本:直接费用:直接材料(BOM),直接人工(Routing的Lab),其他直接费
用.
间接费用:间接材料,间接人工,生产机器设备折旧,机物料消耗等.
即产品的生产成本是一定期间所发生的直接和间接费用的总和. 二.对间接费用的处理通常有两种方式.
1先记入制造费用(及明细)后从贷方转入生产成本(按中方成本会计习惯,通常
是生成成本-辅助成本及其明细)的借方. 2 直接记入生成成本-辅助成本及其明细
1 在实际生产过程中,除了F类的成本中心,其它相关成本中心典型的如库房质量控制成本中心虽然并没直接参加生产,这些成本中心间接用于生产的费用结算就通过Costing sheet来完成(毕竟这些成本中心产生的费用还有部分和生产无关,
于是可通过定义一定费用百分比或一定费用数量金额结算到Prod. Order).
2 希望在成本估算之时就能将Overhead算上.(举个简单的例子,一个成品的标准成本中在估算时可能被希望包含有prod. Overhead和其组成其BOM各
component的mat. Overhead,这时就可使用costing sheet). 换句话说,使用costing sheet的目的是在标准成本估算时尽量将所有和生产成本相关的费用都包含进来.
3 再举一个常见实例,关于Assembly报废率,通常scrap rate可在物料主数据中或BOM中维护,这样在计算标准成本时会将这些scrap考虑进去(根据需求cost
variant可选择不同的BOM版本,有些企业希望MPR BOM不考虑报废Costing BOM考类或相反,就可建立两套BOM,如需要还可建立其他类型BOM),这相当于是将scrap费
用直接算在生产成本中,如企业希望将scrap在成本中分离出来,就可使用costing sheet,将scrap费用当作prod. Overhead的一部分(还可有其它Prod. Overhead),读者可定义overhead key,overhead group然后将其用在costing sheet中,在Assembly mat.的物料主数据costing 1 view中加入overhead group. 下面会有个实际例子.
***会计规定,材料的入帐价值除了材料的采购价值,还可包括运输费,保险费,报关费(进口),仓储费,挑拣费,运输途中的损耗,和一些相关税务(增值税除外),在手工记帐时代,显然没有企业愿意这样做,否则做成本的就天天去算这些东西好了,并且这些费用通常占材料价值百分比
比很小,根据重要性的原则,将相关费用计入期间费用.
如果你愿意,使用costing sheet可将上述费用作为mat. overhead记入产品的成本.(标准成本CK11N|Ck40N等,实际成本分歌KSS2),既然由电脑自动完成记帐工作繁重也无所谓,反正是累电脑.
如图6.1.1.3-2,[1]定义的costing sheets名称,(关于base,overhead rate和credit在下面细讲)当选取costing sheet rows显示procedure,暗示成本核算单的配置和MM|SD的
condition配置有一定相似性(condtion不时有pricing procedure吗),[2]选取全部行按list看配置比价比教方便. [3] [4][11]核算基数,(详细请看6.1.1.4 Define Calculation Bases), [5] [6]overhead rate(详细请看6.1.1.5和6.1.1.6),[7]计算基数取第10行
ZM01[8]取第20行ZL01.(这和MM|SDcondtion配置相同).[9][10][12][13]credit,可理解从贷方转入. (各种制造费用(及明细)后从贷方转入生产成本).
读者思考:
有人说costing sheeting在国内企业不大常用,我想这应该取决于企业对成本管理的要求,如企业需要干嘛分国内国外,借鉴下他人的成本管理经验也未尝不可.
1 6.1.1.3-2中ZM01-ZM03表示生产成本中的mat. Overhead,ZL01-ZL03表示Lab Overhead,之所以要分三种是对应三种origin group,比如在实际情况中需要区分出(金属,五金,塑胶材料分别对应的mat. OH和lab OH) 2 ZQTY使用了user exit计算相应费用,是这样的,假设企业生产的产品需要根据不同的数量或其它原因付不同的产权费,就可以使用user exit(详看6.1.1.8). 同时图中的ZR01是quantity-based overhead rate .
3 如果读者还不明白什么是成本核算单,不用着急,接下来会有个实例介绍Costing sheet在计算标准成本时的作用.
6.1.1.4 Define Calculation Bases
如图6.1.1.4-1. [1]选中全部base可方便看所有相关配置. Base中定义那些成本要素会参与OH的计算. [2][3] 读者思考已经介绍很详细.
下面挑选ZL01和ZM01详细介绍,如图6.1.14-1,,[1]base name ZL01, [2]base中定义的cost element,在此可选择cost element group,这些cost element都是类型43->Internal Activity Allocation的成本要素.
如图6.1.14-3, [1]base name ZM01,[2]直接对应材料valuation class对应成本物料类科目相同的初级成本,[3]可使用 cost element group, [4]使用了origin group.
1会计科目编号要按中方标准吗?
62000000-62000199对应的是生产成本-材料类科目(关于科目编号请看会计科目相关配置),在接下来会介绍通常CO-PC中为了便于核算需要设置生产成本相关明显科目.
2 使用origin group是为了细分费用,前面已多次强调.
假设成品700030由800151(origin group B1),800152(Origin group S1),在估算成本(CK11N测试)就会有如6.1.1.4-4 的Item category为G的两项.(关于overhead rate和credit请继续下看.)
***注意plant 5100 Mat. 800151-800152对应的cost element
***为了理解强调下800151和800152的origin group,在OKTZ中还会解释其作用
***通常是使用了多少个Credit就有几个G(Overhead)项出来.在能看到G项,必须保证下面的配置.
1. OKKN定义的costing variant包含的Valuation variant(OKK4)中的Overhead Tab页包含了你定义的costing sheet.
2. 只有在OKTZ中定义了cost element范围,G项才可能有数据. 6.1.1.5 Define Percentage Overhead Rates
什么是overhead rate,再回到图6.1.1.4-4,第3,4项是怎么算出来的呢?一个简单的例子,库房的人工费用一部分是间接用于生产的,还有一部分是和生产无关的期间费用. 有两种overhead rate可使用,基于百分比和基于数量.
如图6.1.15-1,[1]O/H rate名称,看costing sheet的定义(图6.1.1.3-2),在此介绍ZM01(将就图6.1.1.4-4第3,4G项是如何计算出来重点介绍),[2]如
Dependency(Access Sequence存取顺序,MM|SD相同Condition配置有相同概念)选择D010,在Details明显中将可使用overhead Key,关于overhead key请看6.1.1.9 define Overhead Key [3]List选中看配置
如图6.1.1.5-2为ZM01定义明细, [1]注意生效和失效日期,[2]overhead type,1表示实际OH rate,2表示计划OH rate,(计算标准成本的OH type当然是2).[3]读者注意到从06/10/2005起到08/10/2005期间overhead rate是10%.
上面知道800151的orgin group是B1,正好在Base (图6.1.14-3)的orgin group范围, 图6.1.1.5-2 [3]定义了overhead rate ZM01是10%(Mat OH将占物料成本比例的10%),CK11N的时间是06/20/2005,而从6.1.1.7 define credits知道这些费用将credit ->ZM1到cost center|cost element 52-460000|90201000中,这就是图6.1.1.5-3第3 G(overhead)项的由来.
同样第4 G项是base ZM02,overhead rate ZM02和credit ZM2过来的. 读者思考:
1 使用cost sheeting在计算标准成本时就计算了相关的间接费用(overhead),使标准成本的制定更精确.
2 base ZL01-ZL03,Overhead rate ZL01-ZL03,Credit ZL1-ZL3是Lab OH(对应内部作业类成本要素),它在计算标准成本是起什么作用的.
3 base ZQTY,OH rate ZR01 和credit ZR1的计算逻辑在user-exit中,它对产品的标准成本计算和实际成本核算有什么影响?
未经整理,可惜本人非学习中文的, 想表达清晰…未完代续…,接下来会介绍
OKTZ(将OKTZ和costing sheet结合,)定义的cost element和costing sheet 中使用cost element范围的关系.
7.利润分析(Profitability Analysis)
首先,并不想在此浪费笔墨讲一堆关于PA的理论,COPA的介绍的文章读
者到处都可找到.COPA可简单理解为利润分析顾名思义就是你要怎样进行利润分析,从而为决策提供依据,在下面本人将就如何配置和原理栓释COPA,毕竟夸大和歪曲一个模块的作用和难度是不明智的,而且此书的目的就是揭开FICO的棉纱让更多人能轻易理解FICO .
如果不上此模块可进行利润分析吗?当然可以的,自定义报表,但是得面对海量数据,比如要抓SO,Billing等数据,巨大的数据量使报表的性能受到影响.
类似的问题还有如果不上物料分类帐能有效地分配差异吗?当然,自定义程序,因为上ML多出问题的原因本人反而倾向于不使用ML.
从某种程度上讲,COPA是一个相当容易的模块,因为它设计的逻辑理解相对简单,如果愿意,ABAPer 吃饱了没事做完全可以不用SAP的COPA而自己写出一个COPA来,事实上很多没上COPA的企业实际上就是这样多的.
从设计逻辑上,启动了利润分析,根据设置动态一些相关表,结构和程序(SAP很多模块的设计理念都是这样,启动会产生相关ABAP对象),然后实时或后续Post数据到CO-PA相关表格,同时SAP提供了相关报表,这样比自写程序更简单而且能提供更多的相关报表而已.
在解释利润分析配置前,再此理解下什么是Operating Concern(以下简称OC).
IMG Path:Enterprise structure->Definition->Controlling->Creating Operating Concern建立
IMG Path:Enterprise structure->Assignment->Controlling->Assing Controlling Area
to operating concern分配OC给Co area,在分配前OC必须已经产生了data structure.
OC被翻译成(业务关联区,或康采恩)是获利能力分析中的核心组织结构，一个OC可包含多个controlling area，一个controlling area 只能指派给一OC。
OC用来监控及分析各获利分析段Profit Segment。获利分析段通常是销售组织(销售办公室,销售人员),产品(组,Model)、客户(组)等的灵活组合,具体视企业的实际需。可按照各获利段为依据生成获利分析报表，考核其获利能力。 7.1 Structures
IMG Path如图7.1-1.
.
7.1.1 Maintain Characteristics T-code: KEA5 SE16:
如图7.1.1-1,[1]进入KEA6维护值子段,[2]所有的OC用到的特征,[3]具体OC所用到的特征,[4]所有OCs中都未用到的特征.[5]自定义特征,特征必须是WW开头的4至5位,在自建特征时如果从客户主数据表KNA1,KNB1,KNVV,物料主数据表
MARA,MARC,MVKE,SO header和item table VBAK,VBAP等读取字段,建立的将并不是你所需要的WW***特征.
如图7.1.1-2,如在建立WW099时你选择了VBAP表,并且选择了MATNR和CHARG字段,很明显,保存后WW099特征并未建立而是将VBAP-MATNR和VBAP-CHARG建成了特征.
如果想建立自己的特征,请选择User defined,如图7.1.1-3,[1]用户自定义特征,[2]在此特别介绍下第一种选择with own value maintenance,它会产生一个T25**的check table,如果使用了check table,这些特征在使用前必须使用KES1定义自己的特征值.
在特征可使用前必须激活它,原理很简单,WW099创建了一个data element|domain RKEG_WW099(所有的自定义的特征都会产生类似RKEG_特征名称的data
element|domain)和表T2503|T25A3(可使用Se11查看),所以的abap字典对象在可用前都必须被激活.在建立check table之前读者甚至可手工选择check table名称.
1需要怎样的特征取决于你的CO-PA究竟要分析到多细?上面已经介绍可从哪些表中取字段就可,通常的特征无非是|物料组|销售办公室|销售人员|billing to..等,实际上哪怕用户在维护OC的data structure中只使用了一个特征,
对最常用的特征字段比如公司代码,工厂,利润中心,客户,销售组织,分销渠道,division等最常用的分析字段都已经在CO-PA相关表中了(请看7.1.3 Maintain OC),这些是所谓的Fixed Characteristics,SAP已经提供了 客户|销售订单等表的相应字段
可做特征,如有需要加上这些字段做特征字段, 并且用户还可定义自己的特征with Check table或without check table,这些特征并不基于上述SAP tables.
2尽量优化使用特征和值字段,毕竟大量使用他们会对系统性能造成影响,虽然道理很明显越多的特征和值字段可能使分析更细,你需要在两者间平衡.
3 在建立特征时,读者必须明白这些名词.
[一]Fix characteristic指固定的特征,比如客户,controlling area,sales.Org等,可这样理解就是这些字段在COPA的相关表固定存在,不管你有没有将其设置成特征字段.(注:你设置的特征字段将会形成COPA相关表的字段).
[二]特征的combound Dependencies,意思是一个特征必须同时依靠另一特征,典型的比如你选择了地区KNA1-REGIO做特征,同时KNA1-LAND1也必须选上,另一个例子就是选择了成本中心, Fixed特征Controlling area就是combound dependencies特征. (为了节省一字段,所以通常自定义一特征,然后KES1维护地区值和KEDR做个derivation rule取REGIO的值就可). 4关于data element,domain等名词请看附录应该掌握的ABAP知识.
7.1.2 Maintain Value Fields T-code:KEA6 SE16:
初始画面和选择基本和维护特征一样,再此着重介绍下如何根据需求维护自己的值字段.
关于特征字段,通常并不需要很多自定义的字段,相反,视想Co-PA分析多细,读者可定义很多自己的value fields,特别地, 甚至可定义自己的PA传输架构(T-code: KEI1),全部使用自定义的value field.(如图7.1.2-2)
如图7.1.2-2, 全部使用自定义的value fields,这是采用Costing-based PA type的好处(关于costing-based和accouting-base COPA的采用请看下面讨论).
Value fields是costing-based PA的最小分析单位通常它有销售数量,销售输入,销售成本,销售折扣,各种差异等组成,必须考虑哪些值字段是需要的,比如需要将差异传到COPA吗?需要将差异更小层次细分吗?要怎么细分?需要建立什么样的value field 等.
1 Value field有俩种类型,Amount和Quantity型.大多数情况下可能Aggregation都会选择SUM,在选择LAS,AVG必须仔细考虑.
2如果需要,全部使用自定义的value fields,然后自定义描述,值字段在接下来来的Flows of Actual values配置中将用来对应科目(实际是成本要素),MM,SD的条件类型.
3.是否需要区分主营业务收入(成本)和其他业务收入(成本)?如需要,要建立4 value field然后去和SD condition对应(condition也要建立4种去区别).
4如果需要,预留出一两个value fields给未来不可预见业务,毕竟当OC被全部激活后要更改COPA数据结构是不容易的事情,假设企业忽然需要某种费用进入COPA而且还需要和其他费用区别,如有预留字段,需使用只要将其map 到此费用科目就可,这不是必需的,只是有些企业要这样做. 5.读者思考:
特征通常可理解为有固定数据的字段比如产品->物料,值字段的data通常可变的,比如产品的销售数量,单价和金额,这很容易理解,问题是如果将
一些数量字段强行设置成特征会有什么结果?
7.1.3 Maintain Operating Concern T-code: KEAO SE16:
如图7.1.3-1,[1]输入OC名称STOC,保存后开始建立data structure ,[2]可使用Sample OC参考创建,在7.1.4中也可参考创建一OC,[3][4]两种类型的PA分析.
图中表示STOC可采用两种PA类型,甚至在激活CO-PA (Tcode:KEKE)中可同时激活俩者,很可惜,在Set OC时(Tcode:KEBD)你只能使用其中一种CO-PA类型,关于使用costing-based还是account-based PA type在下面有讨论,通常会试验区使用
costing-based,因为其分析更加灵活. [5]建立data structure (接下来会重点介绍如何建立data structure). [6]在属性页中可定义Co-PA使用的币别和会计年度变式, 只有定义了这些,在Environment才可激活Client-specific part.
建立data structure,如图7.1.3-2,[1]根据实际业务选择data structure需要的特征字段,为了便于说明,在选择了相关字段后按change view, [2]可选择需要的value fields 字段用于建立data structure ,[3]为了便于说明,加上了俩自定义的特征(同时定义时->请参照7.1.1:Maintain Characteristic选择了with own value maintenance),所以此俩表分别对应到check table 是T2503|T2504.
关于value fields,全部采用自定义的value fields,如图7.1.3-3,通常Gross Sales和COGS是应该用于分析的,在接下来将介绍这些value field如何和SD,MM
condtions,PA传输架构等相对应.(Tcode:KE4I|KE4IM|KEI1,详细请看7.4 Flow of actual values配置).
建立完data structure后,必须激活,然后退回OC Attribute Tab页维护币别和年度变式,在Environment中激活client相关和client不相关的COPA部件.
1 什么是client相关和client无关?读者可自行思考. 2 在建立data structure时,SAP做了什么动作?
在建立OC->STOC时,系统会产生这样一个结构CE0STOC(注意COPA自动产生的结构和表名称命名规则是CE0-4+OC名称). CE0STOC:结构,用于COPA程序中定义内表/ CE1STOC:保存actual line items. CE2STOC:保存plan line items CE3STOC:保存PSG info .
CE4STOC|CE4STOC_ACCT|CE4STOC_FLAG|CE4STOC_KENC意义读者可自己去研究.
一般地,如果细心的读者使用SE11查看,
[1]会发现在CE1XXXX|CE2XXXX表中的COPA_AWSYS| TIMESTMP的字段就是你定义的特征和值字段(视实际情况可能有出入).
[2]销售组织,分销渠道,客户,公司等必须字段尽管你在特征中未定义在这些表中也已经存在,这很容易理解,利润分析连这些最常用的字段都没了还谈得上什么分析?所以就做成default字段了.
3 激活Environment 时SAP做了什么动作?
其实说白了,CO-PA就是启动了它,建立了几个表在SO creation, Billing generation或FI记帐等时(请看Flows of Actual Values配置)将相关数据写入COPA而已,正如上面所讲,如果你不上CO-PA可使用report,但是庞大的数据和复杂的逻辑可能会是report 运行失败,如果有了CO-PA,直接从那个表抓数据多快. 在这层意思上, COPA倒是和信息结构系统,BW的逻辑一样.
同样地,读者发现COPA在设计上和SPL也很相似,COPA通过维护特征和值字段产生一些列表,SPL通过建立table group产生一系列表. 两者同样会动态产生一些相关程序.
4.一个建议,为了研究COPA逻辑,KE4I维护FI的PA structure,然后FB50记一笔帐选个PSG,然后看看CE1XXXX和CE3XXXX表的变化.同样开个SO,产生billing看其俩表内容.
7.1.4 Sample Operating Concerns
T-code: SE16:
从SAP的sample OC中Copy所需的OC,同时将相关IMG也Copy过来,通常不建议这样做,毕竟每个企业有不同的实际业务需求,Copy SAP Sample OC显然难于达到需求.
读者可自行测试如何使用此功能.
7.1.5 Define profitability Segment Char. T-code:KEQ3 SE16: V_TKEOE
定义PSG所用到的特征,只有为OC定义的特征和值字段在利润分析段(PSG)才可使用,你还可决定客户,销售订单等固定特征是否可在PSG中使用(SAP默认是不用的).
7.1.6 Set Operating Concern T-code:KEBD|KEBI|KEBA SE16:
在Set OC时OC需要已经被完全激活(Tcode: KEA0),一个OC一次只可使用一个类型的COPA(Costing-based or Accouting-based)
从程序来将,这动作不过是赋给parameter ID一个default值而已,类似的Tcode还有AM 中的OAPL :Set charts of Depreciation 和 OKKS:Set default cotrolling area . 7.2 Master Data IMG Path如图7.2-1.
7.2.1 Maintain Characteristic Values
为用户自定义的特征维护特征值.
在图7.1.3[3]中我特意强调了data structure采用的这俩字段,WW098,WW099在定义时使用了check table,如果在PSG中要用到此两特征,顾名思义,特征的value必须check table T2503|T2504.
1假设在实际应用中WW098是表示产品brand,然后PSG中使用了
WW098,逻辑就会检测WW098的check table是否维护了品牌,如果没找到就会有错误.
2 对于那些自定义的特征没有采用check table这步不用做,只要使用KEDS维护derivation rule就行.
7.2.2 Define Characteristics Hierarchy Tcode:KES3
将特征分层,这也好理解.如果需要,可将特征分层次. 7.2.3 Define Characteristic Derivation
Tcode:KEDR Derivation(这个估计要请Xuebi翻译才比较准确,毕竟Xuebi在美国扫过几年垃圾,我想英文应该不错).
Derivation的意思是一些特征的值获取可根据另外一些和它逻辑相关的特征的值,尤其在自定义的特征设置Derivation 十分必要.
下面介绍如何建立一个derivation,稍有编程经验的人看一眼都懂,如图7.2.3-1,[1]Derivation rule,图7.2.3-3有个WW099对应到Sales office的rule,[2]Table
lookup的条件和derivation rule不同的table lookup可使用多条件,[3]使用move可直接直接根据条件从一个COPA特征字段或SAP字段给另一个COPA特征字段赋值,[4]可根据条件将一些特征字段的值清楚 ,假设定义了一derivation rule,在一些公司中如想让这些derivation不起作用,就可在此设置条件等于此公司的将Derivation的特征值给Clear[5]可写用户出口给特征赋值(SMOD:COPA0001->函数
EXIT_SAPLKEDRCOPA_001->Exit in Derivation Rule),如果实际业务前面四种方法都不难达到用户需求,小写一个user exit也非难事,毕竟程序是最灵活的.
如图建立了俩characteristic Derivation .
如图7.2.3-3,这是一个derivation rule的例子,[1]如果PSG中sales office = 3100(对应[3]的KMVKBU字段),则[2]Region的值记到COPA表中是EUROPE(对应的字段是[4]自定义的特征WW099,在此将销售office看成Sales region),因为WW099有check table,所以所有的region值必须在KES1中维护.
这就是Derivation,如果WW099在建立时没选择使用check table,Region值就可随意输入(没有check table),现在用户应明白为什么要check table,其实是防止不合理的数据进入COPA而已.
在维护Derivation rule后, 你可做个很简单的测试,就是FB50手工记笔帐选择PSG,你输入sales office 3100后, 按Derivation按钮看是否Region EUROPE能否带出,你还可测试设置一Clear ,Condition是sales office =3100和plant = 3101, Region EUROPE给清空(其他的plant依旧有效).
除了derivation可给自定义特征赋值,move,table lookup等都可. 图7.2.3-4是一个使用move的例子.
如图7.2.3-4,[1]move名,[2]Production name,源字段,[3]目标字段是自定义的特征WW003,[4]赋予整个值给目标字段,[5]ARTNR的值从第11字段开始取后5个字符赋予部分值给WW003.
关于table lookup,user exit读者自行思考.
本章小节:
1.决定采用什么类型的利润分析?
costing-base 和 accounting-based 区别前者采用value field,可对应到
cost/Revenue成本要素,MM|SD的条件类型,而后者采用的只能是成本要素. 在对应关系上,value field可对应一到多科目(成本要素),而后者很好立即一个成本要素和会计科目必须是一一对应. 居于前者更灵活,通常企业会选择前种类型.
Costing-based CO-PA有些缺点. [一]时差.
一个实例是SD,已发货但是没biling,(销售成本COGS只有当billing时才到CO-PA), 此时COGS 被post到 FI, 但是CO-PA却没有.(这是针对采用手工billing的企业,通常企业采用自动的后台Job 生成billing这问题就不存
在)
[二]应计:
比如在传输sales order到CO-PA时,一些应计费用通过SO的condition传到CO-PA模块,但从财务角度,这些费用并没发生因此在FI中也不存在.. [三]货币转换小数差和汇率差.
一个OC中(企业用俩OC的恐怕很少)可能使用多个controlling area(有的企业使用了两到多个),这俩差异在其它模块也会有类似的不可避免的问题. 2.什么是利润分析段?
PSG是特征的一个唯一组合,比如可将产品号,产品组,客户,销售组织,分销渠道做为一个利润分析段
3 需要为收入类科目建立cost element category 11成本要素吗?
通常如果没上CO-PA和CO-PCA可以不建立,如果只上了CO-PA并且类型是costing-based也可不建立因为采用的是值字段,如果上了CO-PCA利润中心,就必须为收入科目建立成本要素. 如果采用的是accouting-based CO-PA也必须建立为收入类科目建立成本要素. 4.Create Data structure系统产生了那些表和结构? 在激活OC时,下面这些表和结构会产生.CE0STOC(结构)CE1STOC|CE2STOC|
CE3STOC|CE4STOC|CE4STOC_ACCT|CE4STOC_FLAG|CE4STOC_KENC. 其中CE1STOC保存PA实际行项目(类似ledger中的actual line
items),CE2STOC是plan 行项目,CE3STOC保存的是PSG数据(类似Ledger中的Summary table). 5如何删除OC?
首先删除分配KEKK,后才可使用KEA0删除一个OC,删除OC将所有相关的表,结构,动态程序(Environment)全部删除了.还必须进入删除表才会彻底删除干净.
7.2.4 Valuation Strategies
7.2.5 Set Up Valuation Using Material Cost Estimate
7.2.6 Set Up Conditions and Costing Sheets
这步设置可建立CO-PA专用的condtion和成本核算单(关于condition的配置请看附件光盘condition.doc)用于分析使用原始凭证不能做到的边际效益分析,比如用于计算sales order的销售折扣和运输费用等(未发生的虚拟值).鉴于篇幅,读者请自行研究.
7.3 Planning
IMG Path :如图7.3-1
7.3.1 Initial Steps
7.3.1.1 Define Number Ranges for Planning Data 7.3.1.2 Maintain Versions
7..3.1.3 Assign Quantity Fields
7.3.2 Planning Framework
7.3.2.1 Set Up Planning Framework
7.3.2.2 Create Planning Level fro Planning Layout
7.3.2.3 Display Planner Profiles
7.3.3 Manual Entry of Planning Data
7.3.3.1 Define Planning layout
7.3.3.2 Define Value Field Assignments 7.3.3.3 Define Distribution Profiles
7.3.3.4 Calculated Values as Reference
7.3.4 Integrated Planning
7.3.5 Planning Aids
将重点介绍制造Planning version in OKKP, 使用所谓的flexible planning with info. Strucuter, How to use KEPM . 7.3.6 Reorganization
7.4 Flows of Actual Values IMG Path:如图7.4-1.
7.4.1 Initial Steps
7.4.1.1 Define Number Ranges for Actual Postings
T-code: KEN1 SE16:
如图7.4.1.1-1,SAP使用了document这个名词,所以有FI doc. Billing Doc(VF02), Invoice Doc.(MIRO),Mat. Doc等,然后这些document都会给出编号范围. 在此是只PA doc number range,在COPA表CEX+OC中表示为BELNR字段(SE16可检查). [1]Groups可看到Co-PA使用的record type,假设读者将record type B的number range给删了,在FI记帐就会有图7.4.1.1-3的错误,[2]OC名称,[3]可查看并更改当前的number,[4]查看更改number range
SAP允许使用外部编号.什么情况下使用,读者自行考虑,
7.4.1.2 Maintain Characteristic Groups
T-code :KEPA SE16:
如图7.4.1.2-1,[1]定义一个特征组[2]行号而已[3]字段[4]从图中可以看出,BUKRS和KNDNR将是必输字段,VKORG是只读字段,而MATKL是可选字段.
注意:
1特征组包含自定义的多个字段及其输入状态,如果在输入利润段时,用户
可能需要一些特定的个性值(比如在利润分析段屏幕上需要限制某些字段必输,如果不使用特征组,在输入利润段将显示所有的可用特征->KEQ3定义的特征),就可建立特征组.
2这些特征字段状态是用户利润分析段选屏的,和一般科目使用的field status group是两个概念.
7.4.1.3 Assign Cha. Grp. for Assignment Screen
T-code: KE4G SE16:
如图7.4.1.3-1,[1]业务交易类型RFBU指的即是财务记帐,[2]在上一步定义的特征组,(注意Z003不能在此使用,因为特征组字段有BUKRS公司代码字段),[3]可模拟看到将来记帐时输入PSG时的subscreen和特征组所设置的字段及其输入状态.
1什么是business transaction (请参照3.7特别总帐的activity) ,在此就不再解释.
2 FB50,F-02等记帐的Bus. Trn就是RFBU,在配置完后读者可立即测试. 3 从程序的角度看,为RFBU等定义特征组后,在程序中LKEAKF30中有这样的判断就是如果带?的必选字段未输入,就有错误消息message id '00' type 'E' number '055'.
7.4.1.4 Assing Char. Grp. For Line Item Screen
T-code: KEVG2 SE16:
如图7.4.1.1,给record type B赋予特征组Z003,Z003组中必须包含必输状态的字段BUKRS(公司代码).
留给读者问题,上面RFBU指FI Posting,Record type B也是纸direct posting from FI,如两者都定义了特征组,谁在起作用? 如果是RFBU,那么Record type B究竟什么时候在Post PSG时才会起作用呢?
7.4.1.5 Maintain Value Field Groups
T-code :KEVFG SE16:
值字段组和特征组同样道理,就是在输入值字段时希望自定义那些值字段为必输,就可采用它(如某Bus. Trans没有值字段组,就显示利润分析段的全部值字段). 如图7.4.1.5-1,[1]自定义组ZVF1.
7.4.1.6 Assign Value Field Groups for Line Item Screens T-code :KEVG3 SE16:
如图7.4.1.6-1,现在将此value field group分配给record type F和B, record type记录类型,不过是为了区分post到利润分析模块的数据来源而已.
回看图7.4.1.4-1分配特征组给记录类型,现在又将值字段组分配给了记录类型,
为了便于读者理解,举个实例,在一些情况下我们可能需要直接post line
item到利润分析模块. 我们使用Tcode :KE21N ,如图7.4.1.6-2.,KE21N将直接产生PA Document with Line items.
KE21N用于直接产生PA凭证,如图7.4.1.6-2,如果有实际业务比如需要手工调整COPA就可使用它,这些手工Post的数据只反映在PA中并不会影响财务.
[1]通常KEN1 定义的编号范围是自动内部编号的,建议将这些手工建立的PA doc使用外部编号(如图7.4.1.1-2),以便区分那些直接从FI,MM,SD等模块自动post到CO-PA的PA doc.
读者Enter后,会发现Characteristics 和Value Field Tab页显示的字段将是KEVG2和KEVG3 定义的特征组和值字段组所包含的特征和值字段并且带有用户自定义的输
入状态,这些正是用户所需要的,否则看到的将是OC中定义的全部可用特征和值字段.
7.4.1.7 Summarize Data During Update T-code :KE2S SE16:
如图7.4.1.7-1,[1]交易类型,前面已经说明很清楚,[2]如选了表示只会对外部来的数据才会汇总(比如iDoc,假设一大集团甚至有多client,毕竟client之间的数据是完全独立的,为了使跨client的利润分析成为可能,可能使用iDoc,数据从各client汇总),[3],数据是发生在derivation前还是后面.
举一个简单的例子,如FI doc有3个line item都对应到account 10010101且相同的PSG 10074(Amount分别是100,200,300 USD),一般将有3 line item写到COPA行项目表CE1****中,如使用了KE2S,则只有总的600 USD 被post到CE1****. 7.4.1.8 Store Quantities In CO-PA Std. Unit of Measure
T-code :KE4MS SE16:
SAP帮助中的一个例子是说, VVISQ值字段对应到本世纪末FKIMG(Billing qty),现在要求知道Bill了多少 KG,为此,需另外建立一字段VVIQT(描述是Billing KG,如果SO中使用了销售单位是吨,可库存单位是KG,如仅仅传输VVISQ将难于区分billed qty单位究竟是Ton还是KG),然后将转化后的billed KG保存在VVIQT 中. 如图7.4.1.8-1的,这是另外一个实例,就是将At risk(可能的潜在的SO qty,这在做sales forecast和CO-PA 计划版本中很重要) quantity VVQ03数量算进Order qty VVQ02中.
7.4.2 Transfer of Incoming Sales Orders 7.4.2.1 Assign Value Fields Tcode: KE4I|KE4IM SE16:
这步将SD和MM的condition(通常对MM模块只用内部转厂PO->实际上可看成是将supplying plant的SO和receiving plant的PO合并,所以有个intercompany sales的)和值字段对应上.
如企业要求将相关销售费用比如运输费保险费报关费产权费等分配到销售产品,可为每种费用建立condition和value field然后在此维护关系.
如图7.4.2.1-1,[1] Condition type [2]对应的值字段,因为分析的要求,所有的value field都使用了自定义.condition type和value field对应的关系是多个condition type可对应到同一值字段,通常这些值字段是Amount型的(值字段还有quantity 型的) [3]传输的数据是否要正负号.
在KE4IM中,将转厂PO的Intercompany sales的条件类型和VV013联系上,在此不再贴图描述.
7.4.2.2 Assign Quantity Fields
如图7.4.2.2-1,典型地,将销售数量和开飘数量分配给值字段.
7.4.2.3 Activate Transfer of Incoming Sales Orders
如果需要将sales order数据传输到COPA,请激活传输SO,由于图7.4.2.2-1使用了KWMENG,所以在此选择Inc. SO类型为2. 7.4.3 Transfer of Billing Documents Reset Value/Quantity Fields Tcode:KE4W
1. sales order如何传输到COPA,数量改变在COPA如何反映?
假设SO的item 20对应的WWC-001起初数量是100,在保存时,立即有数据在CE1****,CE3****等表,在此特别提示下CE1****实际行项表,假设在
KEA0的Attribute tab页定义了俩currencies,一是OC currencies,一是
company code currencies并且两者不同,在 COPA中一SO item将会产生两条记录分别对应到currency type B0 和10 .(有多少不同的currencies就会对应多少条不同货币类型的记录)
假设现在SO的数量改成50,会产生两条记录,一条是SO qty -100冲前面的100,另一条是改正后的50 .
当传输SO,对应的一些比如报关费运输费由condition传到value field,如开票不及时,造成FI和PA数据存在时间差异,前面在分析costing-based PA也强调过.
2.需不需要传输sales order 到COPA
视你COPA要分析到什么程度,如果连SO都不传,你的COOPA就太粗了,相信绝大多数企业会需要传输sales order的.
使用Flexible planning加信息系统做sales forecast(Plan verion),SO则作为实际值,然后可比较销售计划和实际销售(SO值)的差异. 3为什么要Reset value/Quantity fields.
销售退回,运输保险保关费用已经实现,在billing时只应冲减收入,回增库存,相关费用从condition带过去则必须是0,不能冲已经发生的数据.
注意:销售退回订单的SO qty传到CO-PA是负数,可冲PA实际发生的销售数量.
7.4.4 Order and Project Settlement
7.4.5 Direct Posting from FI/MM
7.4.6 Settlement of Production Variances
7.4.7 Transfer of Overhead
7.4.8 Transfer Customer Rebate Agreements
7.4.9 Multiple Valuation Approaches/Transfer Price
7.4.10 Periodic Adjustments
7.4.11 Activate Profitability Analysis
因篇幅问题不能全部显示，请点此查看更多更全内容