利润分析Profitability.docx

利润分析Profitability.docx

《利润分析Profitability.docx》由会员分享，可在线阅读，更多相关《利润分析Profitability.docx（111页珍藏版）》请在冰豆网上搜索。

利润分析Profitability

7.利润分析〔ProfitabilityAnalysis〕

首先,并不想在此浪费笔墨讲一堆关于PA的理论,COPA的介绍的文章读者到处都可找到.COPA可简单理解为利润分析顾名思义就是你要怎样进行利润分析,从而为决策提供依据,在下面本人将就如何配置和原理栓释COPA,毕竟夸大和歪曲一个模块的作用和难度是不明智的,而且此书的目的就是揭开FICO的棉纱让更多人能轻易理解FICO.

如果不上此模块可进行利润分析吗?

当然可以的,自定义报表,但是得面对海量数据,比方要抓SO,Billing等数据,巨大的数据量使报表的性能受到影响.

类似的问题还有如果不上物料分类帐能有效地分配差异吗?

当然,自定义程序,因为上ML多出问题的原因本人反而倾向于不使用ML.

从某种程度上讲,COPA是一个相当容易的模块,因为它设计的逻辑理解相对简单,如果愿意,ABAPer吃饱了没事做完全可以不用SAP的COPA而自己写出一个COPA来,事实上很多没上COPA的企业实际上就是这样多的.

从设计逻辑上,启动了利润分析,根据设置动态一些相关表,结构和程序〔SAP很多模块的设计理念都是这样,启动会产生相关ABAP对象〕,然后实时或后续Post数据到CO-PA相关表格,同时SAP提供了相关报表,这样比自写程序更简单而且能提供更多的相关报表而已.

在解释利润分析配置前,再此理解下什么是OperatingConcern〔以下简称OC〕.

IMGPath:

Enterprisestructure->Definition->Controlling->CreatingOperatingConcern建立

IMGPath:

Enterprisestructure->Assignment->Controlling->AssingControllingArea

tooperatingconcern分配OC给Coarea,在分配前OC必须已经产生了datastructure.

OC被翻译成〔业务关联区,或康采恩〕是获利能力分析中的核心组织结构，一个OC可包含多个controllingarea，一个controllingarea只能指派给一OC。

OC用来监控及分析各获利分析段ProfitSegment。

获利分析段通常是销售组织〔销售办公室,销售人员〕,产品〔组,Model〕、客户〔组〕等的灵活组合,具体视企业的实际需。

可按照各获利段为依据生成获利分析报表，考核其获利能力。

7.1Structures

IMGPath如图7.1-1.

.

7.1.1MaintainCharacteristics

T-code:

KEA5SE16:

如图7.1.1-1,[1]进入KEA6维护值子段,[2]所有的OC用到的特征,[3]具体OC所用到的特征,[4]所有OCs中都未用到的特征.[5]自定义特征,特征必须是WW开头的4至5位,在自建特征时如果从客户主数据表KNA1,KNB1,KNVV,物料主数据表MARA,MARC,MVKE,SOheader和itemtableVBAK,VBAP等读取字段,建立的将并不是你所需要的WW***特征.

如图7.1.1-2,如在建立WW099时你选择了VBAP表,并且选择了MATNR和CHARG字段,很明显,保存后WW099特征并未建立而是将VBAP-MATNR和VBAP-CHARG建成了特征.

如果想建立自己的特征,请选择Userdefined,如图7.1.1-3,[1]用户自定义特征,[2]在此特别介绍下第一种选择withownvaluemaintenance,它会产生一个T25**的checktable,如果使用了checktable,这些特征在使用前必须使用KES1定义自己的特征值.

在特征可使用前必须激活它,原理很简单,WW099创立了一个dataelement|domainRKEG_WW099〔所有的自定义的特征都会产生类似RKEG_特征名称的dataelement|domain〕和表T2503|T25A3〔可使用Se11查看〕,所以的abap字典对象在可用前都必须被激活.在建立checktable之前读者甚至可手工选择checktable名称.

1需要怎样的特征取决于你的CO-PA究竟要分析到多细?

上面已经介绍可从哪些表中取字段就可,通常的特征无非是|物料组|销售办公室|销售人员|billingto..等,实际上哪怕用户在维护OC的datastructure中只使用了一个特征,对最常用的特征字段比方公司代码,工厂,利润中心,客户,销售组织,分销渠道,division等最常用的分析字段都已经在CO-PA相关表中了〔请看7.1.3MaintainOC〕,这些是所谓的FixedCharacteristics,SAP已经提供了客户|销售订单等表的相应字段可做特征,如有需要加上这些字段做特征字段,并且用户还可定义自己的特征withChecktable或withoutchecktable,这些特征并不基于上述SAPtables.

2尽量优化使用特征和值字段,毕竟大量使用他们会对系统性能造成影响,虽然道理很明显越多的特征和值字段可能使分析更细,你需要在两者间平衡.

3在建立特征时,读者必须明白这些名词.

[一]Fixcharacteristic指固定的特征,比方客户,controllingarea,sales.Org等,可这样理解就是这些字段在COPA的相关表固定存在,不管你有没有将其设置成特征字段.〔注:

你设置的特征字段将会形成COPA相关表的字段〕.

[二]特征的comboundDependencies,意思是一个特征必须同时依靠另一特征,典型的比方你选择了地区KNA1-REGIO做特征,同时KNA1-LAND1也必须选上,另一个例子就是选择了本钱中心,Fixed特征Controllingarea就是combounddependencies特征.〔为了节省一字段,所以通常自定义一特征,然后KES1维护地区值和KEDR做个derivationrule取REGIO的值就可〕.

4关于dataelement,domain等名词请看附录应该掌握的ABAP知识.

7.1.2MaintainValueFields

T-code:

KEA6SE16:

初始画面和选择根本和维护特征一样,再此着重介绍下如何根据需求维护自己的值字段.

关于特征字段,通常并不需要很多自定义的字段,相反,视想Co-PA分析多细,读者可定义很多自己的valuefields,特别地,甚至可定义自己的PA传输架构〔T-code:

KEI1〕,全部使用自定义的valuefield.〔如图7.1.2-2〕

如图7.1.2-2,全部使用自定义的valuefields,这是采用Costing-basedPAtype的好处〔关于costing-based和accouting-baseCOPA的采用请看下面讨论〕.

Valuefields是costing-basedPA的最小分析单位通常它有销售数量,销售输入,销售本钱,销售折扣,各种差异等组成,必须考虑哪些值字段是需要的,比方需要将差异传到COPA吗?

需要将差异更小层次细分吗?

要怎么细分?

需要建立什么样的valuefield等.

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

2如果需要,全部使用自定义的valuefields,然后自定义描述,值字段在接下来来的FlowsofActualvalues配置中将用来对应科目〔实际是本钱要素〕,MM,SD的条件类型.

3.是否需要区分主营业务收入〔本钱〕和其他业务收入〔本钱〕?

如需要,要建立4valuefield然后去和SDcondition对应〔condition也要建立4种去区别〕.

4如果需要,预留出几个valuefields给未来不可预见业务,毕竟当OC被全部激活后要更改COPA数据结构是不容易的事情,假设企业突然需要某种费用进入COPA而且还需要和其他费用区别,如有预留字段,需使用只要将其map到此费用科目就可.

5.读者思考:

特征通常可理解为有固定数据的字段比方产品->物料,值字段的data通常可变的,比方产品的销售数量,单价和金额,这很容易理解,问题是如果将一些数量字段强行设置成特征会有什么结果?

7.1.3MaintainOperatingConcern

T-code:

KEAOSE16:

如图7.1.3-1,[1]输入OC名称STOC,保存后开始建立datastructure,[2]可使用SampleOC参考创立,在7.1.4中也可参考创立一OC,[3][4]两种类型的PA分析.

图中表示STOC可采用两种PA类型,甚至在激活CO-PA〔Tcode:

KEKE〕中可同时激活俩者,很可惜,在SetOC时〔Tcode:

KEBD〕你只能使用其中一种CO-PA类型,关于使用costing-based还是account-basedPAtype在下面有讨论,通常会试验区使用costing-based,因为其分析更加灵活.[5]建立datastructure〔接下来会重点介绍如何建立datastructure〕.[6]在属性页中可定义Co-PA使用的币别和会计年度变式,只有定义了这些,在Environment才可激活Client-specificpart.

建立datastructure,如图7.1.3-2,[1]根据实际业务选择datastructure需要的特征字段,为了便于说明,在选择了相关字段后按changeview,[2]可选择需要的valuefields字段用于建立datastructure,[3]为了便于说明,加上了俩自定义的特征〔同时定义时->请参照7.1.1:

MaintainCharacteristic选择了withownvaluemaintenance〕,所以此俩表分别对应到checktable是T2503|T2504.

关于valuefields,全部采用自定义的valuefields,如图7.1.3-3,通常GrossSales和COGS是应该用于分析的,在接下来将介绍这些valuefield如何和SD,MMcondtions,PA传输架构等相对应.〔Tcode:

KE4I|KE4IM|KEI1,详细请看7.4Flowofactualvalues配置〕.

建立完datastructure后,必须激活,然后退回OCAttributeTab页维护币别和年度变式,在Environment中激活client相关和client不相关的COPA部件.

1什么是client相关和client无关?

读者可自行思考.

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

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

CE0STOC:

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

CE1STOC:

保存actuallineitems.

CE2STOC:

保存planlineitems

CE3STOC:

保存PSGinfo.

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

一般地,如果细心的读者使用SE11查看,

[1]会发现在CE1XXXX|CE2XXXX表中的COPA_AWSYS|TIMESTMP的字段就是你定义的特征和值字段〔视实际情况可能有出入〕.

[2]销售组织,分销渠道,客户,公司等必须字段尽管你在特征中未定义在这些表中也已经存在,这很容易理解,利润分析连这些最常用的字段都没了还谈得上什么分析?

所以就做成default字段了.

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

其实说白了,CO-PA就是启动了它,建立了几个表在SOcreation,Billinggeneration或FI记帐等时〔请看FlowsofActualValues配置〕将相关数据写入COPA而已,正如上面所讲,如果你不上CO-PA可使用report,但是庞大的数据和复杂的逻辑可能会是report运行失败,如果有了CO-PA,直接从那个表抓数据多快.在这层意思上,COPA倒是和信息结构系统,BW的逻辑一样.

同样地,读者发现COPA在设计上和SPL也很相似,COPA通过维护特征和值字段产生一些列表,SPL通过建立tablegroup产生一系列表.两者同样会动态产生一些相关程序.

4.一个建议,为了研究COPA逻辑,KE4I维护FI的PAstructure,然后FB50记一笔帐选个PSG,然后看看CE1XXXX和CE3XXXX表的变化.同样开个SO,产生billing看其俩表内容.

7.1.4SampleOperatingConcerns

T-code:

SE16:

从SAP的sampleOC中Copy所需的OC,同时将相关IMG也Copy过来,通常不建议这样做,毕竟每个企业有不同的实际业务需求,CopySAPSampleOC显然难于到达需求.

读者可自行测试如何使用此功能.

7.1.5DefineprofitabilitySegmentChar.

T-code:

KEQ3SE16:

V_TKEOE

定义PSG所用到的特征,只有为OC定义的特征和值字段在利润分析段〔PSG〕才可使用,你还可决定客户,销售订单等固定特征是否可在PSG中使用〔SAP默认是不用的〕.

7.1.6SetOperatingConcern

T-code:

KEBD|KEBI|KEBASE16:

在SetOC时OC需要已经被完全激活〔Tcode:

KEA0〕,一个OC一次只可使用一个类型的COPA〔Costing-basedorAccouting-based〕

从程序来将,这动作不过是赋给parameterID一个default值而已,类似的Tcode还有AM 中的OAPL:

SetchartsofDepreciation和OKKS:

Setdefaultcotrollingarea.

7.2MasterData

IMGPath如图7.2-1.

7.2.1MaintainCharacteristicValues

为用户自定义的特征维护特征值.

在图7.1.3[3]中我特意强调了datastructure采用的这俩字段,WW098,WW099在定义时使用了checktable,如果在PSG中要用到此两特征,顾名思义,特征的value必须checktableT2503|T2504.

1假设在实际应用中WW098是表示产品brand,然后PSG中使用了WW098,逻辑就会检测WW098的checktable是否维护了品牌,如果没找到就会有错误.

2对于那些自定义的特征没有采用checktable这步不用做,只要使用KEDS维护derivationrule就行.

7.2.2DefineCharacteristicsHierarchy

Tcode:

KES3

将特征分层,这也好理解.如果需要,可将特征分层次.

7.2.3DefineCharacteristicDerivation

Tcode:

KEDRDerivation〔这个估计要请Xuebi翻译才比较准确,毕竟Xuebi在美国扫过几年垃圾,我想英文应该不错〕.

Derivation的意思是一些特征的值获取可根据另外一些和它逻辑相关的特征的值,尤其在自定义的特征设置Derivation十分必要.

下面介绍如何建立一个derivation,稍有编程经验的人看一眼都懂,如图7.2.3-1,[1]Derivationrule,图7.2.3-3有个WW099对应到Salesoffice的rule,[2]Tablelookup的条件和derivationrule不同的tablelookup可使用多条件,[3]使用move可直接直接根据条件从一个COPA特征字段或SAP字段给另一个COPA特征字段赋值,[4]可根据条件将一些特征字段的值清楚,假设定义了一derivationrule,在一些公司中如想让这些derivation不起作用,就可在此设置条件等于此公司的将Derivation的特征值给Clear[5]可写用户出口给特征赋值〔SMOD:

COPA0001->函数EXIT_SAPLKEDRCOPA_001->ExitinDerivationRule〕,如果实际业务前面四种方法都不难到达用户需求,小写一个userexit也非难事,毕竟程序是最灵活的.

如图建立了俩characteristicDerivation.

如图7.2.3-3,这是一个derivationrule的例子,[1]如果PSG中salesoffice=3100〔对应[3]的KMVKBU字段〕,那么[2]Region的值记到COPA表中是EUROPE〔对应的字段是[4]自定义的特征WW099,在此将销售office看成Salesregion〕,因为WW099有checktable,所以所有的region值必须在KES1中维护.

这就是Derivation,如果WW099在建立时没选择使用checktable,Region值就可随意输入〔没有checktable〕,现在用户应明白为什么要checktable,其实是防止不合理的数据进入COPA而已.

在维护Derivationrule后,你可做个很简单的测试,就是FB50手工记笔帐选择PSG,你输入salesoffice3100后,按Derivation按钮看是否RegionEUROPE能否带出,你还可测试设置一Clear,Condition是salesoffice=3100和plant=3101,RegionEUROPE给清空〔其他的plant依旧有效〕.

除了derivation可给自定义特征赋值,move,tablelookup等都可.图7.2.3-4是一个使用move的例子.

如图7.2.3-4,[1]move名,[2]Productionname,源字段,[3]目标字段是自定义的特征WW003,[4]赋予整个值给目标字段,[5]ARTNR的值从第11字段开始取后5个字符赋予局部值给WW003.

关于tablelookup,userexit读者自行思考.

本章小节:

1.决定采用什么类型的利润分析?

costing-base和accounting-based区别前者采用valuefield,可对应到cost/Revenue本钱要素,MM|SD的条件类型,而后者采用的只能是本钱要素.在对应关系上,valuefield可对应一到多科目〔本钱要素〕,而后者很好立即一个本钱要素和会计科目必须是一一对应.居于前者更灵活,通常企业会选择前种类型.

Costing-basedCO-PA有些缺点.

[一]时差.

一个实例是SD,已发货但是没biling,〔销售本钱COGS只有当billing时才到CO-PA〕,此时COGS被post到FI,但是CO-PA却没有.〔这是针对采用手工billing的企业,通常企业采用自动的后台Job生成billing这问题就不存在〕

[二]应计:

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

[三]货币转换小数差和汇率差.

一个OC中〔企业用俩OC的恐怕很少〕可能使用多个controllingarea〔有的企业使用了两到多个〕,这俩差异在其它模块也会有类似的不可防止的问题.

2.什么是利润分析段?

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

3需要为收入类科目建立costelementcategory11本钱要素吗?

通常如果没上CO-PA和CO-PCA可以不建立,如果只上了CO-PA并且类型是costing-based也可不建立因为采用的是值字段,如果上了CO-PCA利润中心,就必须为收入科目建立本钱要素.如果采用的是accouting-basedCO-PA也必须建立为收入类科目建立本钱要素.

4.CreateDatastructure系统产生了那些表和结构?

在激活OC时,下面这些表和结构会产生.CE0STOC〔结构〕CE1STOC|CE2STOC|

CE3STOC|CE4STOC|CE4STOC_ACCT|CE4STOC_FLAG|CE4STOC_KENC.

其中CE1STOC保存PA实际行工程〔类似ledger中的actuallineitems〕,CE2STOC是plan行工程,CE3STOC保存的是PSG数据〔类似Ledger中的Summarytable〕.

5如何删除OC?

首先删除分配KEKK,后才可使用KEA0删除一个OC,删除OC将所有相关的表,结构,动态程序〔Environment〕全部删除了.还必须进入删除表才会彻底删除干净.

7.2.4ValuationStrategies

7.2.5SetUpValuationUsingMaterialCostEstimate

7.2.6SetUpConditionsandCostingSheets

这步设置可建立CO-PA专用的condtion和本钱核算单〔关于condition的配置请看附件光盘condition.doc〕用于分析使用原始凭证不能做到的边际效益分析,比方用于计算salesorder的销售折扣和运输费用等〔未发生的虚拟值〕.鉴于篇幅,读者请自行研究.

7.3Planning

IMGPath:

如图7.3-1

7.3.1InitialSteps

7.3.1.1DefineNumberRangesforPlanningData

7.3.1.2MaintainVersions

7..3.1.3AssignQuantityFields

7.3.2PlanningFramework

7.3.2.1SetUpPlanningFramework

7.3.2.2CreatePlanningLevelfroPlanningLayout

7.3.2.3DisplayPlannerProfiles

7.3.3ManualEntryofPlanningData

7.3.3.1DefinePlanninglayout

7.3.3.2DefineValueFieldAssignments

7.3.3.3DefineDistributionProfiles

7.3.3.4CalculatedValuesasReference

7.3.4IntegratedPlanning

7.3.5PlanningAids

7.3.6Reorganization

7.4