SAP_COPA_获利能力分析-给力文档

1.0 COPA

SD & CO （1）我只能想到SD订单或者交货或者发票传到CO的一些字段，比如组织架构元素、条件类型以及其他想细分的东西。综合来看最后得到的一张大表（KE24/KE30），这叫CO-PA获利能力分析。

获利管理包括利润分析（CO-PA）和利润中心会计（CO-PCA），谈到利润分析,就说下利润中心,因为人们总喜欢将这两模块联系在一起讨论。

1. 利润分析从外部市场角度分析利润, 利润中心则是从内部管理单元的角度来分析利润. 2. 在利润中心模块,可以根据产品,地区,管理职能单位(生产,销售,财务等划分利润中心,),另外,在SAP的利润中心模块中,如果按期间将资产负债表项目(固定资产,APAR,库存数据和在产品WIP等,实际上也可实时传输这些资产负债表项目)传送到利润中心, 从而对利润中

心的一些典型的投资收益率、现金流量和销售利润率等财务指标进行分析,因此此时利润中心就扩展成为投资中心。

下面我们分别来阐述这两个部分： （一） 利润分析(Profitability Analysis)

获利能力分析的主要目的是从外部市场的角度分析企业行为对经营利润的影响。CO-PA能同时从业务方面(客户，客户组,产品,产品组等及其组合)和组织单元(比如销售组织，分销渠道，业务范围，工厂级组合)对企业经营利润进行详细分析。

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

（二） 利润中心(Profit Center Accouting) 划分利润中心.通常的划分利润中心的方法有:

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

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

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

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

ii:业务范围是FI的概念,而利润中心是CO的概念,我想why有人这样想呢? 1）是BA的配臵放在FI module,而利润中心(CO-PCA)在CO module.

2）是BA实际上和FI的一般总帐Ledger 0共用一套表(FI行项目BSEG和总帐余额表GLT0都有业务范围字段),这意味业务范围调整只

能通过FI Posting(当然也包括FICO统驭,关于FICO统驭前面篇幅也详细介绍了其原理),如果业务范围需要调整,

显然造成一大堆垃圾FI凭证不大合适,而我们知道利润中心则完全采用另一套帐叫Ledger 8A.

3）.利润分析总是通过销

售成本会计方法(Cost-of-sales accouting)计算利润(换句话说,就是利润分析总是从销售模块开始出发的),而利润中心模块则可以使用销售成本法和期间会计法(Period Accouting)计算利

润.

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

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

图1-[2]:平时使用期初的标准成本做销售成本(如果产品采用标准价的话,SAP比较建议采用STD+ML的方式),平时发货使用标准成本,在月末工单结算和跑物料分类帐时将差异带入CO-PA,并可将差异细到cost component层次而不是一个总差异,为此需要在工单的结算参数文件选择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系统细致剖析一番.COPA可简单理解为利润分析顾名思义就是你要怎样进行利润分析.

如果不上此模块可进行利润分析吗?当然可以的,自定义报表,但是得面对海量数据,比如要抓SO, Billing等数据,巨大的数据量使报表的性能受到影响.

类似的问题还有如果不上物料分类帐能有效地分配差异吗?当然,自定义程序.

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

1.0.1 Profitability Analysis Structures

在解释利润分析配臵前,再此理解下什么是Operating Concern(以下简称OC).

? In order to use Profitability Analysis (CO-PA), in IMG Enterprise Structure, you have to

define operating concern and assign controlling area to an operating concern.

? The structure of an operating concern is determined by analysis criteria (characteristics)

and the values to be evaluated (value fields).

? Define Merck specific characteristics and value fields independently of the

operating concern.

? Before defining a new characteristics, look for existing fixed characteristics

delivered by SAP.

? Maximum allowed user definable characteristics = 50 ? Maximum allowed value fields = 120

IMG Path:

Enterprise structure->Definition->Controlling-> Creating Operating Concern

Enterprise structure->Assignment->Controlling-> Assing Controlling Area to operating concern 分配OC给CO area,在分配前OC必须已经产生了data structure. OC是获利能力分析中的核心组织结构，用来监控及分析各获利分析段Profit Segment。获利分析段通常是销售组织(销售办公室,销售人员),产品(组,Model)、客户(组)等的灵活组合,具体视企业的实际需要，以各获利段为依据生成获利分析报表，考核其获利能力。

图1.0.1

图1.0.1.1-1 1.0.1.1 Maintain Characteristics

T-code: KEA5 如图1.0.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***特征.

图1.0.1.1-2 如图1.0.1.1-2,如在建立WW099时你选择了VBAP表,并且选择了MATNR和CHARG字段,

图1.0.1.1-4 图1.0.1.1-3 很明显,保存后WW099特征并未建立而

是将VBAP-MATNR和VBAP-CHARG建成了特征.

如果想建立自己的特征,请选择User defined,如图1.0.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.0.1.1-4 1.有的CO-PA项目索性将所有的特征和值字段全部使用自定义. 2.如果是自定义字段使用了check table,则需要手工维护特征的取值范围(Tcode:KES1),如果自定义特征选择的Validation是No check(如图4-[3]),可以使用推导规则取得这个特征的值(Tcode:KEDR),自定义的特征还可取Fixed values固定值. (如图4-[4]) 3.在建立check table之前读者可手工选择check table名称..

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

1需要怎样的特征取决于你的CO-PA究竟要分析到多细?上面已经介绍可从哪些表中取字段就可,通常的特征无非是|物料组|销售办公室|销售人员|billing to..等,实际上哪怕用户在维护OC的data structure中只使用了一个特征,对最常用的特征字段比如公司代码,工厂,利润中心,客户,销售组织,分销渠道,division等最常用的分析字段都已经在CO-PA相关表中了(请看1.0.1.1.3 Maintain OC),这些是所谓的Fixed Characteristics,SAP已经提供了 客户|销售订单等表的相应字段可做特征,如有需要加上这些字段做特征字段, 并且用户还可定义自己的特征with Check table或without check table,这些特征并不基于上述SAP tables.

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

[1]Fix characteristic指固定的特征,比如客户,controlling area,sales.Org等,可这样理解就是这些字段在COPA的相关表固定存在,不管你有没有将其设臵成特征字段.(注:你设臵的特征字段将会形成COPA相关表的字段).

[2]compound Dependencies, 意思是一个特征必须同时依靠另一特征,典型的比如你选择了地区KNA1-REGIO做特征, 同时KNA1-LAND1也必须选上,另一个例子就是选择了成本中心, Fixed特征Controlling area就是compound dependencies特征. (为了节省一字段,所以通常自定义一特征,然后KES1维护地区值和KEDR做个derivation rule取REGIO的值就可).

有一个推荐做法,为了节省字段从而节省存储空间,记得有个弟兄说CO-PA的特征最好不多于20个。比如象地区REGIO,为了避免使用KNA1-LAND1做复合特征,则自定义一特征,然后Tcode:KES1维护地区范围值,再使用Tcode:KEDR做个推导规则根据定义逻辑去取REGIO的值,实际上特征值WW099就表示REGION,就是为了省空间,多不容易呀,看看现在搞特征的,做了一大堆特征.

[3]尽量优化使用特征和值字段,毕竟大量使用会对系统性能造成影响,CO-PA的数据量可能是巨大的,下面会有详细分析,所以你需要在利润分析程度和性能两者间平衡.

1.0.1.2 Maintain Value Fields

T-code: KEA6

在此着重介绍下如何根据需求维护自己的值字段. 值字段(Value field):是Costing-based PA的最小分析单位,通常它对应到销售数量,销售收入,销售成本,销售折扣,销售条件比如各种销售费用,各种差异等,这视企业对利润分析的细微程度,也可为各种间接费用,营业外|其它业务收支,资产减值损失等建立对应的值字段.

图1.0.1.1.2-1 关于特征字段,通常并不需要很多自定义的字段,相反,视想Co-PA分析多细,读者可定义很多自己的value fields,特别地, 甚至可定义自己的PA传输架构(T-code: KEI1),全部使用自定义的value field.

如图1.0.1.1.2-2, 全部使用自定义的value fields,这是采用Costing-based PA type的好处.

Value fields是costing-based PA的最小分析单位通常它有销售数量,销售收入,销售成本,销售折扣,各种差异等组成,必须考虑哪些值字段是需要的,比如需要将差异传到COPA吗?需要将差异更小层次细分吗?要怎么细分?需要建立什么样的value field 等. 关于值字段Value field,总结几点: 1 Value field有俩种类型,Amount和Quantity型.大多数情况下可能Aggregation都会选择SUM,在选择LAS,AVG必须仔细考虑. 2如果需要,全部使用自定义的value fields,然后自定义描述,值字段在接下来来的Flows of Actual values配臵中将用来对应科目(实际是成本要素),MM,SD的条件类型. 3.是否需要区分主营业务收入(成本)和其他业务收入(成本)? 对于收入类科目使用Tcode:VKOA很容易区分出,但是对于各种销售成本科目就不容易区分了,正常渠道除非建立图1.0.1.1.2-2 销售定单类型,再copy移动类型,动作量太大,但在CO-PA模块中就很容易区分,只要建立主营业务国内成本, 主营业务国外成本,其它业务成本的SD condition再建立对应的值字段就区分开了. 4如果需要,预留出一两个value fields给未来不可预见业务,毕竟当OC被全部激活后要更改COPA数据结构是不容易的事情,假设企业忽然需要某种费用进入COPA而且还需要和其他费用区别,如有预留字段,需使用只要将其map 到此费用科目就可,这不是必需的,只是有些企业要这样做. 5.读者思考: 特征通常可理解为有固定数据的字段比如产品->物料,值字段的data通常可变的,比如产品的销售数量,单价和金额,如果将一些数量字段强行设臵成特征会有什么结果?

建立的值字段是基于Costing-based PA分析的带期间差异的实际利润分析,一般地能做到收入和实际销售成本配比的相对毛利法就可以了,所以你看到值字段包括成本组件(Defined by Tcode:OKTZ,关于成本部件及其差异如何传输进PA稍后会有详细描述)和相应的成本部件差异.

1.0.1.3 Maintain Operating Concern

T-code: KEAO 如图1.0.1.3-1:

[1]输入OC名称STOC,保存后开始建立data structure , [2]可使用Sample OC参考创建,在7.1.4中也可参考创建一OC,

[3][4]两种类型的PA分析. 图中表示STOC可采用两种PA类型,甚至在激活CO-PA (Tcode:KEKE)中可同时激活

图1.0.1.3-1 俩者,很可惜,在Set OC时(Tcode:KEBD)你只能使用其中一种CO-PA类型,通常会使用costing-based,因为其分析更加灵活.

[5]:使用第一步和第二步建立的特征和值字段建立利润分析的数据结构,必须激活数据结构,产生Co-PA Table,表名称是CE1-4+经营范围名称. (接下来会重点介绍如何建立data structure).

[6]: 在属性页中定义Co-PA使用的币别和会计年度变式, 只有定义了这些,在Environment才可激活Client-specific part. 在激活OC时动态产生client相关或client无关的一些程序代码.

建立data structure,如图1.0.1.3-2, [1]根据实际业务选择data structure需要的特征字段,为了便于说明,在选择了相关字段后按change view, [2]可选择需要的value fields 字段用于

建

立

data

structure ,

[3]为了便于说明,加上了俩1.0.1.3-2 自定义的特征,所以此俩表分别对应到check table 是图T2503|T2504.

图1.0.1.3-3 关于value fields,全部采用自定义的value fields,如图1.0.1.3-3,通常Gross Sales和COGS是应该用于分析的,在接下来将介绍这些value field如何和SD,MM condtions,PA传输架构等相对应.(Tcode:KE4I|KE4IM|KEI1,详细请看1.0.4 Flow of actual values配臵).

建立完data structure后,必须激活,然后退回OC Attribute Tab页维护币别和年度变式,在Environment中激活client相

关和client不相关的COPA部件. 注意：

1. After you generate the operating concern, and before you activate Profitability Analysis for

data entry, add the valid characteristic values to the check tables generated for the new characteristics.

2. You must reactivate the environment after you change the data structures of an operating

concern (for example, after you add a new characteristics or value field).

3. The regeneration process does not affect any existing transaction data. However, it also does

not automatically back-populate any new fields for existing transaction data (although this sometimes may be carried out using the CO-PA realignment and/or periodic valuation functions).

4. The regeneration process will also not affect any characteristic values which have already

been entered in check tables for user-defined characteristics.

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

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

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

CE0STOC:结构,用于COPA程序中定义内表/ CE1STOC:保存actual line items. CE2STOC:保存plan line items

CE3STOC: Summary records by profit. segment CE4STOC: Profitability segment definitions

Table CE4xxxx represents the profitability segments (the profitability segments are created based on the business considerations which are defined when creating an operating concern). The table CE3xxxx contains the values posted to the profitability segments that are additionally available broken down into

The CO-PA drill-down reporting tool accesses the data in the CE3… and CE4… tables. Line item and details from the CE1… and CE2… tables can be accessed through line item display features.

下面详细介绍如何使用各种推导 .

[1]Derivation rule,图1.0.1.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也非难事,毕竟程序是最灵活的. 注意：

1、 Customer, product, controlling area, company code, 不能够被overwritten by derivation 2、

图1.0.2.3-2 图1.0.2.3-1

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

如图1.0.2.3-3,这是一个derivation rule的例子：表示的是是如果Sales office = 3100(双击进去图1.0.2.3-3 对应图1.0.2.3-3-[3]的KMVKBU字段),则Region的值是EUROPE(对应的CO-PA字段是图4-[4]自定义的特征WW099), 也就是将Sales Office根据条件推导为Sales region,这个比较简单. 前面已经强调过自定义特征WW099有check table,所以这里推导的Region值必须在KES1中维护.现在用户应明白为什么要check table,很简单,就是防止不合理的随意数据进入CO-PA而已. *在维护Derivation rule后, 可做个很简单的测试,就是FB50手工选择一在PA传输结构中定义的费用科目记一笔帐,成本对象选择PSG,在PSG中输入sales office 3100后, 然后按Derivation按钮看是否Region EUROPE能否带出,If OK,表示改推导规则成功! 2).Table loopup 在Table lookup中,可使用多条件,如图1.0.2.3.-4,以为销售办公室和销售组推导为例,新建Table lookup后输入table KNVV. 图1.0.2.3-4 在表格查询(Table look)中 3）.Move 直接根据条件从一个COPA特征字段或SAP字段给另一个COPA特征字段赋值,如图1.0.1.2.3-4,[1]move名,[2]Production name,源字段,[3]目标字段是自定义的特征WW003,[4]赋予整个值给目标字段,[5]ARTNR的值从第11字段开始取后5个字符赋予部分值给WW003.

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

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

图1.0.2.3.-5 5).Enhancement 有几种情况下使用增强我觉得比较合适,第一逻辑相当复杂,既然是自定义程序,就应该能满足这个原则:凡是SAP里面有的东西,它就是躲到天涯海角都一定能抓到.第二推导行次过多而这些行次逻辑类似,比如一系统涉及成百上千Sales office的推导,如果用Table lookup那不知道要多少行,第三,用于做特征的组织字段变更比较频繁,这样可以使用增强,然后自定义一配臵表格,如果发生变更,只要SE16|SM30维护相应表格就行,不要去维护推导又重新生成传输请求,特别是在大集成的Server,这点非常重要,我负责过一跨国公司的维护,一般我都极力赞同这种方法. 依旧以销售办事处和销售组的派生为实例,步骤如下. Step I:建立增强(Tcoede:CMOD). 图1.0.2.3.-7 如图1.0.2.3-7,增强项目ZCOPA001包含增强COPA0001,本来一般的增强是可以直接在SMOD激活增强就可以,不一定需要CMOD建立一个项目,但是这个增强需要建立项目. Step II.建立推导增强(Tcode:KEDR) 图1.0.2.3-8-[1]:源文本可以看到增强的源代码. 图1.0.2.3-8-[2]:增强的名称 .

图1.0.2.3.-8 图1.0.2.3-8-[3][4]:一定要选择源字段,将源字段作为增强的条件输入从而获得目标字段内容. 图1.0.2.3-8-[5]:选择满足什么大条件下才执行该增强,实际上增强程序本身就可以限制条件 Step III.准备主数据

SE16:V_TVBUR->维护销售办公室 SE16:V_TVKGR->维护销售组 OVXM:给销售范围分配销售办公室 OVXJ:给销售办公室分配销售组

XD02:将销售办公室和销售组分配到客户销售主数据中. Step IV:参考增强代码

COPA0001-> EXIT_SAPLKEDRCOPA_001函数包含ZXKKEU1. 增强程序ZXKKEU11程序示例代码如下:

*\*\*\ IMPORTING

*\ VALUE(I_OPERATING_CONCERN) LIKE TKEB-ERKRS *\ VALUE(I_DERIVATION_DATE) LIKE SY-DATUM *\ VALUE(I_STEP_ID) LIKE TKEDRS-STEPID

*\ VALUE(I_COPA_ITEM)

*\ VALUE(I_GLOBAL) LIKE KEDRCOPA STRUCTURE KEDRCOPA *\ EXPORTING

*\ REFERENCE(E_COPA_ITEM) *\ REFERENCE(E_GLOBAL) *\ REFERENCE(E_EXIT_IS_ACTIVE) *\ REFERENCE(E_FAILED) *\ EXCEPTIONS

*\ DERIVATION_FAILED

**\*输入参数: *KNDNR:Customer

*BUKRS:Company code(读取KNVV销售主数据可不需要) *VKORG:Sales Org.

*VTWEG:Distribution Channel *SPART:Division *输出参数:

*VKBUR:Sales Office *VKGRP:Sales Group

DATA : ST_COPA_ITEM LIKE CE1SINO . DATA: BEGIN OF ST_WA_VK,

VKBUR LIKE KNVV-VKBUR , VKGRP LIKE KNVV-VKGRP , END OF ST_WA_VK .

CASE I_OPERATING_CONCERN . WHEN 'STOC' .

CLEAR :ST_WA_VK , ST_COPA_ITEM . ST_COPA_ITEM = I_COPA_ITEM .

SELECT SINGLE VKBUR VKGRP INTO ST_WA_VK FROM KNVV WHERE KUNNR = ST_COPA_ITEM-KNDNR AND VKORG = ST_COPA_ITEM-VKORG AND VTWEG = ST_COPA_ITEM-VTWEG AND SPART = ST_COPA_ITEM-SPART .

ST_COPA_ITEM-VKBUR = ST_WA_VK-VKBUR . ST_COPA_ITEM-VKGRP = ST_WA_VK-VKGRP . E_COPA_ITEM = ST_COPA_ITEM. ENDCASE. 这段代码非常简单,稍微解释一番, I_COPA_ITEM是输入参数,注意这段输入参数只包含图1.0.2.3-8-[3]定义的源字段,将I_COPA_ITEM赋给临时的ST_COPA_ITEM,使用它的目的是ST_COPA_ITEM做为一Work area可以更好赋值,然后再将增强修改后ST_COPA_ITEM赋给输出参数 E_COPA_ITEM. Step V.测试增强效果 图1.0.2.3.-9 如图1.0.2.3-9,在KEI1中设臵科目400001000的PA传输结构,FB50手工记帐,选择PSG做成本对象,手工记帐是更便于分析推导结果, 然后输入客户,公司代码,销售组织,分销渠道,部门5个条件,可以在增强处设臵断点,看是否能正确从客户主数据中获取销售办事处和销售组.

图1.0.2.3-9-[2]:客户主数据Sales area截图.

图1.0.2.3-9-[3][4]:输入5个条件然后按图1.0.2.3-9-[4]的派生就能从客户主数据中带出销售办事处和销售组. 推导小结: 1.在特征推导中,不要企图对值字段进行赋值,否则会有错误,关于值字段的推导在值字段评估增强中编写(Tcode:KE4U),同样在值字段增强中不要企图更改特征内容一样会导致错误. 2.最近在狂整BW&BCS,在BCS的源数据基础的数据将合并数据加载到合并数据基础中采用的映射(Mapping)原理和这类推导规则的思想基本相同,倒是,在BW的更新规则做成这样table lookup,Move拖拖拽拽多方便.,只要长了手的这种细活都能做, 哎,写BW的这些哥们完全应该向搞Co-PA推导这段程序的哥们多学习学习,方便用户. 4.4.2.4 值字段评估 It is necessary to decide to what record types (F, A, B, C, and 0-9) and at what points (known as points of valuation) each valuation strategy should apply. Likewise, if a strategy is to be applied to planning data, the relevant planning version must be specified (this is all configuration). The various valuation techniques populate the value fields in different ways:

? with costing sheets, condition types are mapped to value fields ? from Product Costing, cost components are mapped to value fields ? value fields are updated directly through user exits 图1.0.2.4-1 图1.0.2.4-1-[1]:定义和分配评估策略,可以为值字段定义评估增强(Tcode:KE4U). 图1.0.2.4-1-[2]:定义评估如何访问标准成本估算 图1.0.2.4-1-[3]:为实际成本/ML定义一通常叫COGS-Adj.的值字段. 图1.0.2.4-1-[4]:可根据产品,物料类别或其它特征分配成本码Costing Keys. 图1.0.2.4-1-[5]:将成本部件分配到值字段(Tcode:KE4R). 图1.0.2.4-1-[6]:利用条件和成本核算单位技术映射条件类型到值字段. 1.0.2.4.1 Set Up Valuation Using Material Cost Estimate 下面将意义从易至难介绍如何使用这些东西. 一．定义访问标准成本 图2-[1]:建立Costing Key Z01,Z01可以传输到值字段使用标准成本估算(Tcode:CK11N|Ck40N),也可使用MTO的销售订单成本核算(Tcode:VF01|CK51N),MTO生产方式直接将Sales order link到工单,这样工单的结算差异也就可直接传输到Sales order. 图2-[2]:可以选取成本估算的变式(Tcode:OKKN|OKK4)和估算版本,这部分在CO-PC章节有详细描述.

图2-[3]:这个设臵有时比较重要,特别是销售发货(Tcode:VL02N)和发票形成跨月时,可以选择3 Material cost estimate matching posting date或者4 Release standard cost estimate matching goods issue date ,则标准成本估算的取值会根据相应的设臵逻辑.

可以将定义好的Costing Key分配给产品,物料组或任何特征(Tcode:KE4H|KE4J|KEPC),在 KEPC中可以继续编写增强.

1.0.2.4.2 Set Up Conditions and Costing Sheets

这步设臵可建立CO-PA专用的condtion和成本核算单(关于condition的配臵请看附件光盘

condition.doc)用于分析使用原始凭证不能做到的边际效益分析,比如用于计算

order的销售折扣和运输费用等(未发生的虚拟值).鉴于篇幅,读者请自行研究.

sales

1.0.2.4.3定义和分配评估策略(Tcode:KE4U)

设臵Exit NO U01, 分配Costing key给Record A,B,C F等.

*----------------------------------------------------------------------*

* INCLUDE ZXKKEU03 * *----------------------------------------------------------------------*

*field-symbols: type any. assign EP_SOURCE_BUKRS to *.

*if EP_SOURCE_BUKRS+225(4) <> ''. * AUTHORITY-CHECK OBJECT

*'Z_CO_BUKRS' ID 'BUKRS' FIELD EP_SOURCE_BUKRS+225(4). * if sy-subrc <> 0.

* message e001(ZCO) with EP_SOURCE_BUKRS+225(4). * endif. *endif.

DATA : LS_CE1SINO LIKE CE1SINO . CASE ERKRS. WHEN 'SINO'. IF EXIT_NR = 'U01'.

LS_CE1SINO = EP_SOURCE. LS_CE1SINO-VV010 = 100 . LS_CE1SINO-VV020 = 200 . EP_TARGET = LS_CE1SINO . ENDIF. ENDCASE .

一样的原理, EP_SOURCE是源头, LS_CE1SINO是临时, EP_TARGET是目标, 在

LS_CE1SINO自定义逻辑更改值字段,想多复杂就有多复杂,想什么逻辑就整什么逻辑, LS_CE1SINO-VV010 = 100 . LS_CE1SINO-VV020 = 200 .

是将这两值字段给固定值.

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

1.0.1.4 Flows of Actual Values

IMG Path:如图1.0.1.4-1.

1.0.1.4.1 Initial Steps

1.0.1.4.1.1 Define Number Ranges for Actual Postings

T-code: KEN1

在COPA表CEX+OC中表示为BELNR字段(SE16可检查).

[1]Groups可看到Co-PA使用的record type,假设读者将record type B的number range给删了,在FI记帐就会有图1.0.1.4.1.1-3的错误, [2]OC名称

[3]可查看并更改当前的number [4]查看更改number range

SAP允许使用外部编号.什么情况下使用,读者自行考虑, 图1.0.1.4.1.1-1 图1.0.1.4.1.1-2 1.0.1.4.1-2

1.0.1.4.1.2 Maintain Characteristic Groups

T-code :KEPA

图1.0.1.4.1.1-3

图1.0.1.4.1.2-1 如图1.0.1.4.1.2-1,[1]定义一个特征组[2]行号而已[3]字段[4]从图中可以看出,BUKRS和KNDNR将是必输字段,VKORG是只读字段,而MATKL是可选字段. 注意:

1特征组包含自定义的多个字段及其输入状态,如果在输入利润段时,用户可能需要一些特定的个性值(比如在利润分析段屏幕上需要限制某些字段必输,如果不使用特征组,在输入利润段将显示所有的可用特征->KEQ3定义的特征),就可建立特征组.

2这些特征字段状态是用户利润分析段选屏的,和一般科目使用的field status group是两个概念.

1.0.1.4.1.3 Assign Cha. Grp. for Assignment Screen

T-code: KE4G

如图1.0.1.4.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'.

1.0.1.4.1.4 Assing Char. Grp. For Line Item Screen

T-code: KEVG2 SE16:

图1.0.1.4.1.3-1 如图1.0.1.4.1.4-1,给record type B赋予特征组Z003,Z003组中必须包含必输状态的字段BUKRS(公司代码).

图1.0.1.4.1.4-1 留给读者问题,上面RFBU指FI Posting,Record type B也是纸direct posting from FI,如两者都定义了特征组,谁在起作用? 如果是RFBU,那么Record type B究竟什么时候在Post PSG时才会起作用呢?

1.0.1.4.5 Maintain Value Field Groups

T-code :KEVFG SE16:

值字段组和特征组同样道理,就是在输入值字段时希望自定义那些值字段为必输,就可采用它(如某Bus. Trans没有值字段组,就显示利润分析段的全部值字段). 如图1.0.1.4.1.5-1,[1]自定义组ZVF1.

1.1利润中心

1.1.1 基本设置(Basic Settings)

首先熟悉一下利润中心的基本设臵,配臵路径如图1 . [1]Tcode:OKKS

图1-[1],如果使用了多个controlling area可自由切换,读者可遇到多次类似操作比如AM 中set折旧表,PA中set Operating concern, 实际上不过是改变一下parameter ID之值,CO area 的parameter ID是CAC.

在此你设臵的Controlling area就是接下来0KE5维护的Controlling area,可能集团会使用多个Controlling area(详细请回顾本书CO的一般控制设臵章节). [2]Tcode:0KE5

图2-[1]设臵Dummy profit center,成本对象Account assignment如没抓到profit center(比如记帐时cost center主数据忘记维护profit center,OKB9也没维护)就取它.

图2-[2]利润中心顶层标准层次名称,关于如何建立利润中心层次请看下面的主数据 图2-[3]是假设属于同一profit center的cost center间的CO操作比如分摊数据不post到利润中心会计,但是不影响FI post过来的数据,主要是为了减少不必要的数据量.

图2-[4][5]作用很明显,虽然从理论上可做到Profit center currency,controlling area currency,Group currency,Operating concern currency不同,你可能要尽量使用统一的货币,毕竟在各种报表时去转换货币太麻烦.

图2-[6]表示利润中心会计在会计年度2005/2006被激活,在此你并不能增加新的会计年度,你必须使用Tcode OKKP增加,如图3-[2],比如你要增加2007会计年度,然后自动反应在图2-[6]的会计年度,当然你也可在图3-[1]activate components/control indictors勾上Profit center激活利润中心会计.

SAP的常见Currencies关系(Skip) Profit center currency: Controlling area currency: Group currency: Operating currency: 这些currency的关系如何? [3]Tcode:1KEF

Tco

设臵EC-PCA实际数据控制参数,如图4-[1]表示是否需要传输Actual data line item, 图4-[2]表示FI|CO的数据实时在线传输到EC-PCA模块,如没设臵Locked标识的话不传输.

EC-PCA有两种模式选择一是account-based period account 二是cost-of-sales accounting methods.EC-PCA的数据收集实际上也采用的SPL的概念,什么是SPL?简单理解就是凡是非Ledger 0的ledger都是SPL(详细请看<>的SPL篇),SPL包含一个table group,这group通常包含*A,*P,*T三表,同样EC-PCA ledger是SPL的Ledger 8A,对应的三表是GLPCA(Actual line)/GLPCP(Plan line)/GLPCT(Summary table) . 到目前为止,假设0KE5(1)已经给当年度打上了激活标志,(2)设臵了Dummy profit center,(3)1KEF也设臵了online transfer,然后你在FI和CO中测试着post几个凭证看看EC-PCA的几个表变化. 最简单的方法是FB50(FI module)直接选俩P&L科目记一笔帐,然后使用SE16看表GLPCA和GLPCT的变化,如果你没有设臵传输line item,凭证post后只在GLPCT有Ledger 8A/version 0的数据而actual line表GLPCA没有任何数据,除非你勾选了传输line item.如你连online transfer都没选上,就没有任何数据实时传到EC-PCA任何表,你就必须manual传输数据,请参照IMG path:Profit Center Accounting->Actual Postings->R/3 Internal Data transfer(1KE8/1KE9/1KEC). 一般有业务数据时相关配臵不再允许更改,在test server可使用0KE1 reset test数据,将测试数据删除,这次1KEF里勾上line item传输选项,再使用KB11N(CO module) ,MB1A 551 scrap(MM module)和9KE0(EC-PCA直接)看看EC-PCA的数据变化,是的,你很快就明白了FI/CO的数据是如何传输到EC-PCA的,就这么简单!

[4]Tcode: OKEQ/OKEQN

等一下,上面这样弄一下数据就传到EC-PCA了?不是还要设臵一下版本吗?是的,所以如果SAP工程师能从设计逻辑上多多思考学习SAP就是小菜一碟 在实际值post到EC-PCA版本自动是0,并且似乎Ledger 8A和相应的表是固定的,我没有看到有相关配臵去更改另外的Ledger比如ZA为EC-PCA的Ledger,也没有看到允许用户更改Ledger 8A table group的配臵,比如我希望加多几个字段到EC-PCA table ,这点和一般的SPL不同. 当然对于EC-PCA的field movement是可设臵和增强的.

图5[1]-[2]我们看到CO General Version 0,SAP default很多version,你设臵可以不要version 1,2,不要任何其他的version,但是version 0是必需的的,因为它承载了Actual CO data当然也可用于Co Plan,也就是说当MM/FI/SD/HR/PP等模块实时非计划数据post到CO模块一定是

Version 0.

一般根据实际需求会建立其他CO版本 .

图5-[3]将CO 版本在PCA中设臵,单独在PCA(CO-PA一样)设臵的版本而没在CO中设臵会不能使用,所以一个有效的版本首先必须是CO版本,然后才可以是PCA/PA版本.

能用在PS的版本,CO版本的Exclusive Vesion必须是3 .

图5-[4]-[5]表示CO版本的会计年度设臵,上面讲过PCA,PA版本首先必须是CO版本.

让我们再回顾一下CO version的设臵,如图6-[1],CO version 50和PCA version/PA version使用不同的汇率类型,CO version使用M,而后俩者使用专门为计划设臵的P汇率, 图6[2]表示内部作业分摊使用的版本,默认是0 .

图5[6]表示允许实时传输数据(实际上对Plan data即使没有选择online transfer它似乎依旧会online transfer,所以这选项似乎没有作用, 这和实际值传输有所不同),

图5[7]如没有选上,就不会有plan line item数据post到GLPCP表中,数据直接进入summary table GLPCT .

图5[8]表示计划数据使用的汇率,你可使用和记帐使用的M平均汇率不同的其它汇率,为此你需要使用OB07定义exch. Rate type比如图5[8]P 然后OB08维护P汇率. 什么是所谓的版本? 简单地说,就是用来分割数据用的,这很容易理解某中学初一招收到新生250人,将它分成5个班就相当于5个版本. PCA表:GLPCP(plan line)/GLPCA(actual line)/GLPCT(Summary)/GLPCO|GLPCC这种table grouop(表组)熟悉SPL的应该非常容易理解,而版本使数据保存在可通过它分割 PCA模块的Record type和PA的record type(详细请看PA相关章节)不同,它分0(actual)/1(plan)/2(actual ass./dis.)/3 (plan ass./dis.) 实际项目中你可能需要建立多个版本这就决定于业务需求复杂度. 很好,你可使用7KE1/7KE3进行PCA plan,测试后的数据使用0KE1删除,在能顺利测试之前,你必须使用GB02分配PCA document type P0编号范围, PCA默认的doc type就俩->实际的A0和计划的P0(当然你可定义自己的doc type名称).

[5]Tcode:KEE0

简单地说,这只是调整plan table GLPCP和Summary Table GLPCT之间的差异,对实际值使用

的是1KE8/1KE9/1KEC等tcode重传,你在什么情况下需要这样做,请自看帮助 . [6]Tcode:1KE1/0KE4

SAP似乎告诉我们,EC-PCA的Ledger 8A和相应的表都是Fixed的,在一些情况下,你可能要执行0KE4去更新一些东西,让我们回顾以下CO-PA,允许自定义characteristic和value field,在激活时EC产生包含这些characteristic和value field的各种表,同时必须激活所谓的环境Environment,实际上就是动态产生一些相关control table,Strucure和支持程序.0KE4一样的道理.

[7]Tcode:0KE6

激活所谓的平均余额帐Ledger 8Z,如激活了,在GLPCT表中就会有Ledger 8Z的数据,你什么时候根据企业需要激活ledger 8Z 请看SAP帮助. [8]Tcode:2KET/SE16: V_T030_GL/OC08

2KET设臵是否允许2KES做年度余额结转.SE16: V_T030_GL(OB53 for single)配臵留存利润科目.OC08维护transaction type(AM|Consolidation),请参考<>AM和EC-CS相关配臵.

二） 利润中心(Profit Center Accounting) 企业组织(Enterprise Organization)

EC-PCA需要怎样的组织结构? 从cost center copy. 按事业部, 按销售地区

主数据(Master Data)

主数据部分很多是在前台可操作的,故在此不再描述,当然前台操作Tcode和后台的配臵Tcode并没什么不可逾越的鸿沟,通常只是一个标志的转换而已.请看本节例1如何使配臵可前台操作. [1]

[2]Tcode:KE59

建立dummy profit center,如没抓到profit center系统自动使用它.

[3]Tcode:1KE6

请看例2 Matchcode和Search help [4]Tcode:KK01/KK02|KBH1/KBH2|3KEG 维护统计指标,同时作为set传到report painter. [5]Tcode:3KEJ

使用代表物料在分析时不但可By account而且可by此代表物料,可能的情形是,比如有的企业使用了变式BOM产生一堆FG material No,实际上这些FG可能只是某些component的颜色和尺寸有所不同而已。

如图3[1]输入VGCd,这个就是OMWD用来将valuation area (OX14,SAP default valuation level->Valuation area is a plant,只要是copy出的plant就一定会出现在OMWD中)group起来的Val. Grpg code,也是MM科目自动分配OBYC中的Valuation modif . SAP推荐这个只对成品使用,毕竟这会影响系统性能.（代表性物料） [6]Tcode:3KEK

如图4-[1]建立了一代表物料ASSORT0109 . [7]Tcode:8KEO

建立派生规则,步骤和CO-PA特征派生规则(KEDR)定义一样,

图5[3] definition的source fields选MATNR,其它的比如你想将BUKRS和BWKEY做source field似乎行不通, 图5[2]表示只对plant(valuation area)5100有效, 然后单击图5[1]维护规则. 如图[6]

设臵物料580286的代表物料是图[4]设臵的物料ASSORT0109 . 实际上PCA模块的GLPCA/GLPCP/GLPCT表都有字段REP_MATNR用来保存所谓的代表物料 一个简单的测试,MB1A 551报废一个580286,然后看看GLPCA和GLPCT表,是的,当成功post后,REP_MATNR保存的是ASSORT0109. 如果你需要更负责的逻辑可使用Exit. 在测试成功前,你必须使用3KEH定义580286 OBYC->BSX对应的存货科目,因为如不设臵,CO-PCA(此乃CO模块,BS科目又未建立cost element)默认是不会将数据存货科目的分录数据post到PCA模块的,当然报废费用科目的分录数据也会有REP_MATNR

利润中心分配(Assignments to Profit Centers)

分配利润中心很容易理解,比如图1-[1]基本在物料主数据中你可将利润中心字段设臵为必输,对历史物料主数据的更改除了使用MM17 mass change外,CATT/BDC/LSMW或使用BAPI(BAPI_MATERIAL_SAVEDATA)写个小程序怎么着都行.

定义和分配SO替代规则:Tcode:0KEM/0KEL ,如图1-[2]-[3] .

什么情况下需要使用Sales order substitution? For mat. Item. 通常Sales order item的利润中心是根据plant+material自动从物料主数据带出来如在物料主数据维护了利润中心的话,显然这满足不了复杂的业务需求.典型的实际需求是希望根据不同的销售组织,销售区域或其它更复杂的组合条件决定相应的利润中心. 你必须使用替代,即使在建立/修改(VA01/VA02)Sales order item你能单击item进入item account assignment Tab页将从plant+material带出的Profit center更改成新的利润中心,交货开票时,利润中心凭证的利润中心 For COGS account你使用OKB9. 创建订单的时候不能自动记录利润中心,原来的销售组织可以自动带出来.我手工维护了

本文来源：https://www.bwwdw.com/article/9b9g.html