COPA杀手速成.docx

COPA杀手速成.docx

《COPA杀手速成.docx》由会员分享，可在线阅读，更多相关《COPA杀手速成.docx（31页珍藏版）》请在冰豆网上搜索。

COPA杀手速成

七.利润分析（ProfitabilityAnalysis）

获利能力分析的主要目的是从外部市场的角度分析企业行为对经营利润的影响。

CO-PA能同时从业务方面（客户，客户组,产品,产品组等及其组合）和组织单元（比如销售组织，分销渠道，业务范围，工厂极组合）对企业经营利润进行详细分析。

通过这种分析帮助企业了解在不同市场方面企业的获利能力以及变动趋向，从而帮助企业决策者对产品定价、客户选择，分销渠道及销售条款快速提供决策依据，这在竞争激烈的微利行业尤其重要,接下来会就系统实现进行更细节的讨论.

谈到利润分析,就说下利润中心,因为人们总喜欢将这两模块联系在一起讨论（有个家伙跟我说他就不喜欢将两者扯在一起,我说那好你大概就不属于人们的行列）.

1.利润分析从外部市场角度分析利润,利润中心则是从内部管理单元的角度来分析利润.

2.在利润中心模块,可以根据产品,地区,管理职能单位（生产,销售,财务等划分利润中心,）,另外,在SAP的利润中心模块中,如果按期间将资产负债表项目（固定资产,APAR,库存数据和在产品WIP等,实际上也可实时传输这些资产负债表项目,传说在SAP的ERP200X版本已是如此做法）传送到利润中心,从而对利润中心的一些典型的投资收益率、现金流量和销售利润率等财务指标进行分析,因此此时利润中心就扩展成为投资中心。

划分利润中心.通常的划分利润中心的方法有:

a.从成本中心（组）生成利润中心,实际上利润中心起到一个group成本中心的概念.

b.根据业务范围或将集团下级单位划分成利润中心,这样可以避免为下级单位建立多公司代码,下级单位可以根据利润中心出相关报表.

c.根据成品或地区划分利润中心,说到这里,又扯一下业务范围（有的将这东西干脆翻译成事业部）,比如一个大型电子集团分彩电事业部,通信事业部等,关于利润中心和业务范围又有些民间说法:

i:

利润中心是后来设计用来取代业务范围的?

.

ii:

业务范围是FI的概念,而利润中心是CO的概念,我想why有人这样想呢?

一是BA的配置放在FImodule,而利润中心（CO-PCA）在COmodule.

二是BA实际上和FI的一般总帐Ledger0共用一套表（FI行项目BSEG和总帐余额表GLT0都有业务范围字段）,这意味业务范围调整只能通过FIPosting（当然也包括FICO统驭,关于FICO统驭前面篇幅也详细介绍了其原理）,如果业务范围需要调整,显然造成一大堆垃圾FI凭证不大合适,而我们知道利润中心则完全采用另一套帐叫Ledger8A.

不管如何设计业务范围和利润中心,符合企业需求就行.

3.利润分析总是通过销售成本会计方法（Cost-of-salesaccouting）计算利润（换句话说,就是利润分析总是从销售模块开始出发的）,而利润中心模块则可以使用销售成本法和期间会计法（PeriodAccouting）计算利润.

销售成本法类似中国损益表的概念,从销售收入销售成本出发通过多步方式得到净利润,因此CO-PA分析利润也有所谓的毛利法和净利法.

图1-[1]:

通过期末工单结算将差异传输到CO-PA实现所谓的实际成本.

图1-[2]:

平时使用期初的标准成本做销售成本（如果产品采用标准价的话,SAP比较建议采用STD+ML的方式）,平时发货使用标准成本,在月末工单结算和跑物料分类帐时将差异带入CO-PA,并可将差异细到costcomponent层次而不是一个总差异,为此需要在工单的结算参数文件选择PA传输结构,同时在KEI1定义PA传输结构时可以选择所谓的9种类差异而不是收入/成本.这样就可在期末还原成传说中的”实际成本”.

*遗憾的是,有联副产品的企业差异结算因为工艺等种种将差异强行分配到各产品实际意义

不大,因此差异只是通过生产定单结算科目直接进入总数到PA,实际成本难于实现.

图1-[3][4]:

可以采用完全成本法和变动成本法

另外,在启动CO-PA时,有两种类型的利润分析方式:

基于成本（Costing-based）和基于帐户（Acc

ount-based）,CO-PA模块允许选择其中任何一种,也可同步启动两种利润分析方式.

吸收成本法和部分成本法

完全成本法|制造成本法也称为制造成本计算法或吸收成本法（名词和Tcode一样多）:

是指以制造成本为产品成本计算范围的成本计算方法。

变动成本法|部分成本法也称为直接成本法或边际成本法:

是指以变动性生产成本或制造成本为产品成本计算范围的成本计算方法。

下图是一个典型的制造企业按经济用途的成本费用分类图.

1.完全成本法和变动成本法最核心最本质的差异在于对固定制造费用的处理上.

2.完全成本法计算过程繁琐，尤其是到月底涉及到费用分摊、成本还原工作量大也难于把握

所以在CO-PA要做到净利法非常困难,在接下来会针对此问题深入讨论

关于完全成本法和变动成本法请参考CO-PC篇,有大量讨论,特别是涉及SAP系统成本逻辑实现部分.

有个网友对上述内容的评价是”两个黄鹂鸣翠柳（你说啥鸟语?

）,一行白鹭上青天（靠越扯越远）”,所以下面就CO-PA系统细致剖析一番.

1.定义经营范围

经营范围（OperatingConcern,也有翻译成业务关联区或康采恩,主要是这些人英文太好）是CO-PA的最高组织单位,它可包括多个控制区域或公司代码,一个经营范围可以包括多个控制区域（Controllingarea）,一个控制区域只能分配给一个经营范围（如果哪家集团连多个经营范围都整上了,那业务也太大了）而一个控制区域可以包含多个公司,在前面的篇幅已经花了一定的篇幅分析一个大的跨国集团使用多个控制区域的优缺点.

下图是一个经营范围,控制区域和公司代码的例图.

建立经营范围（以下简称OC）需要建立特征,值字段在激活就行,步骤如下:

一.建立特征（Tcode:

KEA5）

首先创建OC假定名称为STOC.

特征（Characteristics）:

是将承担销售数量、成本及收入因而与获利性有关的字段,多个特征可以组成所谓的多维利润分析的获利分析段.

从数据库的角度,特征无非是一些分析字段而已,一般地，客户主数据表KNA1,KNB1,KNVV,物料主数据表MARA,MARC,MVKE,销售定单header和item表VBAK,VBAP这些标准字段都可以做为分析特征,利润分析无非就是根据客户|客户组|产品|产品组等分析利润.

除这些标准字段可用做特征外,还可自定义特征,这些自定义特征通常必须是WW开头的4至5位的,如图2-[5]自定义特征WW099（WW099表示销售Region）.

点击Create/Change图标,进入图3,如果想建立自己的特征,请选择Userdefined,在此特别介绍下第一种选择withownvaluemaintenance,它会产生一个T25**的checktable,如果使用了checktable,这些特征在使用前必须使用Tcode:

KES1定义自己的特征的取值范围,这点很容易理解,假设定义了一个区域的特征,在KSE1中可定义该特征的区域只能是华北区,华东区等,不在此范围的区域将是错误区域,要不怎么叫Checktable呢?

如图4,在特征可使用前必须激活它,因为特征WW099创建了一个dataelement|domainRKEG_WW099（所有的自定义的特征都会产生类似RKEG_特征名称的dataelement|domain）和表T2503|T25A3（可使用Tcode:

SE11查看）,而SAP的任何ABAP字典对象在可用前都必须激活.

*1.有的CO-PA项目索性将所有的特征和值字段全部使用自定义.

2.如果是自定义字段使用了checktable,则需要手工维护特征的取值范围（Tcode:

KES1）,如果自定义特征选择的Validation是Nocheck（如图4-[3]）,可以使用推导规则取得这个特征的值（Tcode:

KEDR）,自定义的特征还可取Fixedvalues固定值.

3.在建立checktable之前读者可手工选择checktable名称..

关于特征,还有几点补充:

1.FixCharacteristics:

我用中文小译一下,各位注意了,中文其实就是固定特征,象Customer,

controllingarea,sales.Org,companycode,plant,profitcenter等特征固定存在,你想一下,一个利润分析连客户,公司代码这样的特征都没有你还分析个啥?

2.ComboundDependencies:

复合特征,意思是一个特征必须同时依靠另一特征,比如你选择了地区KNA1-REGIO做特征,则KNA1-LAND1必须同时选上,再比如你选择了成本中心,则Controllingarea就是combounddependencies,因为必须两者结合才有意义,同样的概念在SAP数据仓库BW中也非常常见.

*有一个推荐做法,为了节省字段从而节省存储空间,记得有个弟兄说CO-PA的特征最好不多于20个,现在服务器性能提高了,NND,各位弟兄现在不再care这个了,有使用上百个特征的,真怀疑利润分析这些字段他们是否真的用的有滋有味?

比如象地区REGIO,为了避免使用KNA1-LAND1做复合特征,则自定义一特征,然后Tcode:

KES1维护地区范围值,再使用Tcode:

KEDR做个推导规则根据定义逻辑去取REGIO的值,实际上特征值WW099就表示REGION,就是为了省空间,多不容易呀,看看现在搞特征的,做了一大堆特征.

3.尽量优化使用特征和值字段,毕竟大量使用会对系统性能造成影响,CO-PA的数据量可能是巨大的,下面会有详细分析,所以你需要在利润分析程度和性能两者间平衡,有的家伙在建立特征和值字段时建的太多,恨不得将所有的销售条件类型都建成特征再搞值字段与之对应,恨不得将所有的会计报表项目都建立值字段,也不嫌co-pa跑起来会累的慌.

不过,现在科技发达了,有钱好办事,可以买大服务器.

二.建立值字段（Tcode:

KEA6）

值字段（Valuefield）:

是Costing-basedPA的最小分析单位,通常它对应到销售数量,销售输入,销售成本,销售折扣,销售条件比如各种销售费用,各种差异等,这视企业对利润分析的细微程度,也可为各种间接费用,营业外|其它业务收支,资产减值损失等建立对应的值字段.

图6是一个值字段的例图.

图6建立的值字段是基于Costing-basedPA分析的带期间差异的实际利润分析（回顾图1-[1]）,一般地能做到收入和实际销售成本配比的相对毛利法就可以了,所以你看到值字段包括成本部件（DefinedbyTcode:

OKTZ,关于成本部件及其差异如何传输进PA稍后会有详细描述）和相应的成本部件差异.

关于值字段Valuefield,总结几点:

1.Valuefield有俩种类型,Amount和Quantity型.大多数情况下可能Aggregation都会选择SUM（汇总计算）,在选择LAS,AVG必须仔细考虑.

2.Valuefield在FlowsofActualvalues配置中将用来对应科目（即成本要素）,MM,SD的条件类型等.

3.有一个算是比较经典的问题,和SD紧密相关,在利润分析时,需要区分主营业务收入|主营业务成本,其他业务收入|其他业务成本（比如开销售定单销售原材料取得其他业务收入）,主营业业务收入还区分国内国外收入等等,对于收入类科目使用Tcode:

VKOA很容易区分出,但是对于各种销售成本科目就不容易区分了,正常渠道除非建立销售定单类型,再copy移动类型,动作量太大,但在CO-PA模块中就很容易区分,只要建立主营业务国内成本,主营业务国外成本,其它业务成本的条件类型再建立对应的值字段就区分开了.

4.可预留出一两个valuefields给未来不可预见业务,以免在CO-PA使用过程中去增加.

读者思考:

一个弟兄留给我的问题，现在就转给你们思考:

特征通常可理解为有固定数据的字段比如产品,物料等,而值字段通常对应的金额,数量数据一般可变的,比如产品的销售数量,单价和金额,现在的问题是如果将一些数量字段强行设置成特征会有什么结果?

三.维护经营范围（Tcode:

KEA0）

图7-[3][4]:

如果需要,可以同时使用两种利润分析类型.

图7-[5]:

使用第一步和第二步建立的特征和值字段建立利润分析的数据结构,必须激活

数据结构,产生Co-PATable,表名称是CE1-4+经营范围名称.

图7-[6]:

在属性页中定义Co-PA使用的币别和会计年度变式,

然后必须到Environmen激活该经营范围,在激活OC时动态产生client相关或client无关的一些程序代码.

关于维护经营范围,也总结几点:

1.在建立datastructure时,SAP做了什么动作?

在建立OC->STOC时,系统会产生这样一个结构CE0STOC（注意COPA自动产生的结构和表名称命名规则是CE0-4+OC名称）.

CE0STOC:

结构,用于COPA程序中定义内表/

CE1STOC:

保存actuallineitems.

CE2STOC:

保存planlineitems

CE3STOC:

保存PSGinfo.

CE4STOC:

CE4STOC_ACCT|CE4STOC_FLAG|CE4STOC_KENC意义读者可自己去研究.

2激活Environment时SAP做了什么动作?

就是产生了一堆激活client相关和client不相关的COPA部件,简单的举个例子,KE24|KE25随着不同企业的OC利润分析的需求而造成特征和值字段,这两动态产生的程序当然也不同,这种随配置不同而动态产生不同的程序（当然是有规则的）是SAP系统设计的又一大亮点.

四.设置经营范围（Tcode:

KEBD|KEBI|KEBA）

这动作不过是赋给OCparameterID一个default值而已,如果系统使用了多个OC就很有用处,类似的Tcode还有AM 中的OAPL:

SetchartsofDepreciation和OKKS:

SetdefaultcotrollingareaERB.

如果需要可以维护用户参数（Tcode:

SU3|Su01）将参数ID设置一默认值,想获得某字段的参数ID,对着字段按F1就能获知,这是一个小使用技巧.

你可以同时使用两种理论分析类型,下面详细描述其不同之处:

1.costing-base和accounting-based利润分析的区别

a.costing-base和accounting-based区别前者采用valuefield,可对应到cost/Revenue成本要素,MM|SD的条件类型,而后者采用的只能是成本要素,各种数据都保存在值字段里.

b.在对应关系上,valuefield可对应一到多科目（成本要素）,而后者很好立即一个成本要素和会计科目必须是一一对应.居于前者更灵活,通常企业会选择前种类型,可同时选两者.

c.Costing-based更灵活,可以同时采用两种利润分析类型,在进行利润分析或定义报表可以在两者之间进行切换,Costing-based有其缺点:

2.Costing-basedCO-PA的缺点分析.

a.时间差异

一个实例是SD,已发货但是没biling,（销售成本COGS只有当billing时才到CO-PA）,此时COGS被post到FI,但是CO-PA却没有.

b.应计问题

比如在传输salesorder到CO-PA时,一些应计费用通过SO的condition传到CO-PA模块,但从财务角度,这些费用并没发生因此在FI中也不存在..

c.货币转换时的汇率差.

特别是对一跨国集团,涉及多币种时的转换无可避免地产生汇率差异.

3.在Costing_based和Accounting_based利润分析切换

如果同时使用了两者，可使用KEBA|KEBD在两者间切换,此时KE24,KE25标准的利润实际|计划行项目分析出现的屏幕将不一样,可使用KE3K为Accounting_based分析定义利润分析用的成本要素组.

*关于利润分析报表编写在后面会有详细描述.

CO-PATransactionDataDataSource:

KEB0

如何增加特征和值字段?

SE14一下

有正常的标准成本估算，月末生产订单差异结算时，此差异如何通过CO-PA能分出其中料、工、费的差异,没上物料帐，CO-PA在PAtransferstructure中有9项对应的差异，但与料、工、费不是一一对应的。

不知如何来对应，请高手指点！

COPA中的计划用KE1E传输成功,可是用MC89却看不到数值,COPA_PROFITABILITY_SEGMENT

K_COBL_TO_COPADATA

K_COBL_CODINGBLOCK_DERIVATION

本章小节:

2.获利分析段PSG

PSG是特征的一个唯一组合,通常可将产品,产品组,客户,客户组,销售组织,分销渠道做为一个利润分析段.

定义产生获利分析段的特征,PSG的特征可用于信息系统和利润计划,有这么几条原则:

1.通常象销售定单,成本对象这样的最好不要用于产生PSG的特征

2.客户和产品似乎总是PSG特征,即使你不设置它们为PSG特征.

3.为了提高性能,可以考虑将一些特征不设置为PSG特征（顾问只要糊弄通配置就可以,

谁搭理什么性能问题?

）

4.为了提高性能,可以定义PSG特征的例外,即在某些条件下让这些特征不形成PSG

5.PSG利润分析段的编号和其它的凭证编号一样.

图1-[1]:

客户这字段我故意没用于PSG特征,但系统不买帐,似乎系统认定客户必须是PSG特征,这好理解,获利分析都不根据客户哪成何体统?

图1-[2]:

WBSelement&Order最好不用于PSG特征.

图1-[3]:

公司代码必须用于形成PSG特征

什么意思?

假设公司代码,客户,产品,成本中心是用于产生PSG的特征,如果公司代码A+客户B+产品C+成本中心D产生了一PSG号123,如果下次记帐同样是公司代码A+客户B+产品C+成本中心D则PSG依旧是123,如果再下次记帐是公司代码A+客户B+产品C+成本中心E,Ok,成本中心不同了,看看以前有没有符合这些特征的PSG,如果没有产生一个新的PSG号,显然,随着产生PSG的特征多,性能应该会受到影响.

如何测试PSG的产生?

使用FB50|F-02什么的,然后看CE1STOC|CE3STOC|CE4STOC几个表的变化,我们发现CE1STOC-COPA_AWTYP参考过程是RFBU,CE1STOC-RBELN对应到会计凭证,这样财务凭证就和利润分析凭证相互关联了,CE1STOC,CE3STOC和CE4STOC当然通过PAOBJNR联系.

*BSEG-PAOBJNR<>CE1STOC-PAOBJNR,它们是通过CE1STOC-RBELN=BSEG-BELNR关联

3.特征值派生和值字段评估

幽他一默,我做SAP已经做了整整两年这么久,非常感冒业界两句话,一是XXERP只有D国

人才能写出来,二是某某ERP博大精深,难于摸透.第一句话实际上就是外国月亮比中国圆的

翻版,人不都是娘生妈带长大的吗?

哪个系统不是无数的Bug修理从小到大走过来的,咱整不

出ERP已经非常可悲,如果别人整出来的东西宰都宰不了那就真的是可耻了;关于第二句话,

我就问什么是博大精深,答曰什么流程在系统都能实现,我再问为什么什么流程都能实现,他

又答不上来.

最近大家忙着学习八荣八耻,其中有一条是”以崇尚科学为荣,以愚昧无知为耻”,实际上就是人家系统架构搭的好而已,为此我也总结了SAP的八大设计亮点,在此就不一一详介绍,其中一条就是大家熟悉的用户增强,留下出口你想怎么玩就怎么玩,这种设计思路在SAP的各大模块的各个交易事务（码）中被应用得淋漓尽致,但不管如何,任何系统它最终都是代码,代码再复杂一定程度上逻辑也是死的,如果连这点都没意识到有不认真宰就跟着瞎起哄喊什么博大精深那就未免有点愚昧无知了,所以下次我还听到次等荒谬论调,我就准备建议他老板放他几天假让他去参加八荣八耻的培训.

一.定义特征派生（Tcode:

KEDR）

为用户自定义的特征维护特征值（Tcode:

KES1）.

在建立特征时我特意强调了自定义字段的检查表（checktable）,现在假设WW098,WW099在定义时使用了checktable,WW098是表示产品Brand,系统就会检测WW098的checktable是否维护了品牌,如果没找到就会有错误,而WW099表示销售区域,可以在此维护Region,在接下来将Salesoffice推导为Salesregion.（请参考本小节的图4的Derivationrule）

对于那些自定义的特征没有采用checktable这步不用做,只要直接使用KEDR维护推导逻辑就行.

可以建立特征层次（Tcode:

KES3）,比如可为产品和物料建立层次.比如一个销售车辆的公司的产品层次可能是这样的,第一层次是国产车和进口车,第二层次是汽车,火车和坦克（属于贩卖军火）,第三层次是具体品牌小轿车等等.

*特征层次结构的概念在SAP的BW中被广泛应用.

使用特征推导

Derivation的意思是派生或推导,简单理解,就是一些特征的可以让用户根据需求去定义自己的逻辑取值而已,下面详细介绍如何使用各种推导.

图3表示有5种方式可以建立推导的步骤,下面一一举例介绍这5种推导的玩法.

a.Derivationrule.

图4是一个使用Derivationrule推导的例子,表示的是是如果Salesoffice=3100（双击进去对应图4-[3]的KMVKBU字段）,则Region的值是EUROPE（对应的CO-PA字段是图4-[4]自定义的特征WW099）,也就是将SalesOffice根据条件推导为Salesregion,这个比较简单.

前面已经强调过自定义特征WW099有checktable,所以这里推导的Region值必须在KES1中维护.现在用户应明白为什么要checktable,很简单,就是防止不合理的随意数据进入CO-PA而已.

*在维护Derivationrule后,可做个很简单的测试,就是FB50手工选择一在PA传输结构中定义的费用科目记一笔帐,成本对象选择PSG,在PSG中输入salesoffice3100后,然后按Derivation按钮看是否RegionEUROPE能否带出,IfOK,表示改推导规则成功!

b.Tableloopup

在Tablelookup中,可使用多条件,如图5,以为销售办公室和销售组推导为例,新建Tablelook后输入tableKNVV.

在表格查询（Tablelook）中

c.Move

move直接根据条件从一个COPA特征字段或SAP字段给另一个COPA特征字段赋值,如图7.

这个Move推导表示,将源字段Productionname（图7-[2]）第11位起取5个字符到目标->自定义的特征WW003（图7-[5]）,可以直接Move整个源字段到给目标字段（图7-[4]）,还可选择相关条件（图7-[6]）,表示符合条件的记录Move才生效.

d.Clear

不贴图了,其实就是将一个特征值内容给清空.

e.E