7利润分析(Profitability

更新时间:2023-07-05 13:15:35 阅读：评论：0

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:Enterpri structure->Definition->Controlling->Creating Operating Concern建立

IMG Path:Enterpri structure->Assignment->Controlling->Assing Controlling Area

to operating concern分配OC给Co area,在分配前OC必须已经产生了data structure.

creative design

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建成了特征.

如果想建立自己的特征,请选择Ur 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-bad PA type的好处(关于costing-bad和accouting-ba COPA的采用请看下面讨论).

Value fields是costing-bad 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-bad还是account-bad PA type在下面有讨论,通常会试验区使用costing-bad,因为其分析更加灵活. [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三级人力资源管理师产生一系列表. 两者同样会动态产生一些相关程序.