获利能力分析
单纯关于客户、 产品、和收入的销售统计指标信息(最常见的销售指标:销售收入|销售成本|销售折扣)系统越来越不足以用来衡量企业的成功，因为它们忽略了许多获利的重要因素。
获利能力分析的主要目的是从外部市场的角度分析企业行为对经营利润的影，允许从业务方面(客户，客户组,产品,产品组，内销外销等销售类型等及其组合)和组织单元(比如销售组织，分销渠道，业务范围，工厂等组合)对企业经营利润进行详细分析,企业可以自己决定根据何种分析组合来确定某一部分业务究竟是盈利还是亏损。
通过这种分析帮助企业了解在不同市场方面企业的获利能力以及变动趋向，从而帮助企业决策者对产品定价、客户选择，分销渠道及销售条款快速提供决策依据，这在竞争激烈的微利行业尤其重要,接下来会就系统实现进行更细节的讨论.
谈到利润分析,就说下利润中心,因为人们总喜欢将这两模块联系在一起讨论。
1. 利润分析从外部市场角度分析利润, 利润中心则是从内部管理单元的角度来分析利润.
2. 在利润中心模块,可以根据产品,地区,管理职能单位(生产,销售,财务等划分利润中心,),另外,在SAP的利润中心模块中,如果按期间将资产负债表项目传送到利润中心, 从而对利润中心的一些典型的投资收益率、现金流量和销售利润率等财务指标进行分析,因此此时利润中心扩展成为投资中心,利润中心模块提供了客户和产品的收入成本信息,对于小企业,这两个基本的获利分析维度如果足够,本人不大建议其启动获利分析模块,启动一个模块数量剧增占硬盘。
划分利润中心有一定讲究，通常的划分利润中心的方法有:
a.从成本中心(组)生成利润中心,实际上利润中心起到一个group成本中心的概念.
b.根据业务范围或将集团下级单位划分成利润中心,这样可以避免为下级单位建立多公司代码,下级单位可以根据利润中心出相关报表.
c.根据成品或地区划分利润中心,说到这里,扯一下业务范围(事业部),比如一个大型电子集团分彩电事业部,通信事业部等,关于利润中心和业务范围，又有些民间说法:
i:利润中心是后来设计用来取代业务范围的?.
ii:简单理解，业务范围是FI的概念,而利润中心是CO的概念。
一是BA的配置放在FI module,而利润中心(CO-PCA)在CO module.
二是BA实际上和FI的一般总帐Ledger 0共用一套表(FI行项目BSEG和总帐余额表GLT0都有业务范围字段),这意味业务范围调整只能通过FI Posting(当然也包括FICO统驭,关于FICO统驭前面篇幅也详细介绍了其原理),如果业务范围需要调整,显然造成一大堆垃圾FI凭证不大合适,而我们知道利润中心则完全采用另一套帐叫Ledger 8A。
iii.大点的企业可能同时使用业务范围和利润中心,除了两边需要配置外还遗留了一个数据统驭问题,所以在ERP新的版本中,倾向于不再使用业务范围,而引入一个新的组织单元概念-Segment(报表段),Segment被设置在利润中心主数据中,这样大大简化了配置和业务。
3.利润分析总是通过销售成本会计方法(Cost-of-sales accouting)计算利润(换句话说,就是利润分析总是从销售模块开始出发的),而利润中心模块则可以使用销售成本法和期间会计法(Period Accouting)计算利润.
销售成本法类似中国损益表的概念,从销售收入销售成本出发通过多步方式得到净利润。
图1-[1]:CO-PA的数据来源主要有：销售订单数据，销售发票数据，直接费用使用获利段做成本对象的财务过帐期，期末工单结算差异，期末间接成本的分摊等，这些数据通过不同的记录类型(Record Type)区分开,传输到CO-PA实现所谓的实际成本。
记录类型
A
外来销售订单(销售订单)
B
从FI直接记帐(使用获利段做成本对象)
C
定单/项目结算(工单结算)
D
间接费用成本(间接费用分摊)
E
单交易成本
F
出具发票数据(销售发票)
G
客户协议
H
统计指标
I
定单相关的项目
以上表格中是系统自定义的记录类型，其中ABCF是常见的集中记录类型,可以把所有与销售有关的交易数据都包括在获利分析模块中，销售计划，客户订单 、发票行项目、客户询价报价等。比如说将销售订单（实际销售量）传输如获利分析模块，可以和年度季度销售计划进行实际和计划销售执行情况的对比分析。
记录类型字段用来区分数据来源,如果需要,系统允许自定义记录类型来区分业务数据。
图1-[2]:平时使用期初的标准成本做销售成本(如果产品采用标准价的话,ERP厂商比较建议采用STD+ML的方式),平时发货使用标准成本,在月末工单结算和跑物料分类帐时将差异带入CO-PA,并可将差异细到cost component层次而不是一个总差异,为此需要在工单的结算参数文件选择PA传输结构,同时在KEI1定义PA传输结构时可以选择所谓的9种类差异而不是收入/成本.这样就可在期末还原成传说中的”实际成本”.
*一些有联副产品的企业差异结算因为工艺等种种将差异强行分配到各产品实际意义
不大,因此差异只是通过生产定单结算科目汇总进入到PA。
图1-[3][4]:获利分析可以采用净利分析法|完全成本法|吸收成本法或毛利分析法|变动成本法部分成本法。
关键词：净利分析和毛利分析
净利分析|完全成本法|制造成本法也称为制造成本计算法或吸收成本法(名词一大堆):
是指以制造成本为产品成本计算范围的成本计算方法。
毛利分析|变动成本法|部分成本法也称为直接成本法或边际成本法:
是指以变动性生产成本或制造成本为产品成本计算范围的成本计算方法。
变动成本能揭示销售数量和利润变化关系 。
当0库存和JIT生产，变动成本 = 完全成本。
下图是一个典型的制造企业按经济用途的成本费用分类图.
1.完全成本法和变动成本法最核心最本质的差异在于对固定制造费用的处理上.
2.完全成本法计算过程繁琐，尤其是到月底涉及到费用分摊、成本还原工作量大也难于把握
,我在一个项目中，国外用户要求将期间费用在获利模块中分到客户和产品等获利分析特征上，这种BT需求想一想都会昏菜，所以在CO-PA要做到净利法非常困难,所以做到毛利分析一般就可以。
关于完全成本法和变动成本法更详细请参考本书的CO-PC篇。
另外,启动CO-PA时,有两种类型的利润分析方式:基于成本(Costing-based)和基于帐户(Acc
ount-based),CO-PA模块允许选择其中任何一种,也可同步启动两种利润分析方式.
概念先讲到此，下面就CO-PA系统细致剖析一番.
第一节 定义经营范围
首先，认识一个获利分析模快的组织单元-经营范围。
经营范围(Operating Concern,也有翻译成业务关联区或康采恩,主要是这些人英文太好)是CO-PA的最高组织单位,它可包括多个控制区域或公司代码,一个经营范围可以包括多个控制区域(Controlling area),一个控制区域只能分配给一个经营范围(如果哪家集团连多个经营范围都整上了,那业务也太大了)而一个控制区域可以包含多个公司,在前面的篇幅已经花了一定的篇幅分析一个大的跨国集团使用多个控制区域的优缺点，这里就不再讨论。
下图是一个经营范围,控制区域和公司代码的例图.
建立经营范围(以下简称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,如果想建立自己的特征,请选择User defined,在此特别介绍下第一种选择with own value maintenance,它会产生一个T25**的check table,如果使用了check table,这些特征在使用前必须使用Tcode:KES1定义自己的特征的取值范围,这点很容易理解,假设定义了一个区域的特征,在KSE1中可定义该特征的区域只能是华北区,华东区等,不在此范围的区域将是错误区域,要不怎么叫Check table呢?
如图4,在特征可使用前必须激活它,因为特征WW099创建了一个data element|domain RKEG_WW099(所有的自定义的特征都会产生类似RKEG_特征名称的data element|domain)和表T2503|T25A3(可使用Tcode:SE11查看),而SAP的任何ABAP字典对象在可用前都必须激活.
*1.有的CO-PA项目索性将所有的特征和值字段全部使用自定义.
2.如果是自定义字段使用了check table,则需要手工维护特征的取值范围(Tcode:KES1),如果自定义特征选择的Validation是No check(如图4-[3]),可以使用推导规则取得这个特征的值(Tcode:KEDR),自定义的特征还可取Fixed values固定值.
3.在建立check table之前读者可手工选择check table名称..
关于特征,还有几点补充:
Characteristics:我用中文小译一下,各位注意了,中文其实就是固定特征,象Customer,
controlling area,,company code,plant,profit center等特征固定存在,你想一下,一个利润分析连客户,公司代码这样的特征都没有你还分析个啥?
2. Combound Dependencies:复合特征,意思是一个特征必须同时依靠另一特征,比如你选择了地区KNA1-REGIO做特征,则KNA1-LAND1必须同时选上,再比如你选择了成本中心, 则Controlling area就是combound dependencies,因为必须两者结合才有意义,同样的概念在SAP数据仓库BW中也非常常见.
* 有一个推荐做法,为了节省字段从而节省存储空间,记得有个弟兄说CO-PA的特征最好不多于20个,现在服务器性能提高了,NND,各位弟兄现在不再care这个了,有使用上百个特征的,真怀疑利润分析这些字段他们是否真的用的有滋有味?
比如象地区REGIO,为了避免使用KNA1-LAND1做复合特征,则自定义一特征,然后Tcode:KES1维护地区范围值,再使用Tcode:KEDR做个推导规则根据定义逻辑去取REGIO的值,实际上特征值WW099就表示REGION,就是为了省空间,多不容易呀,看看现在搞特征的,做了一大堆特征.
3. 尽量优化使用特征和值字段,毕竟大量使用会对系统性能造成影响,CO-PA的数据量可能是巨大的,下面会有详细分析,所以你需要在利润分析程度和性能两者间平衡,有的家伙在建立特征和值字段时建的太多,恨不得将所有的销售条件类型都建成特征再搞值字段与之对应,恨不得将所有的会计报表项目都建立值字段,也不嫌co-pa跑起来会累的慌.
不过,现在科技发达了,有钱好办事,可以买大服务器.
二.建立值字段(Tcode:KEA6)
值字段(Value field):是Costing-based PA的最小分析单位,通常它对应到销售数量,销售输入,销售成本,销售折扣,销售条件比如各种销售费用,各种差异等,这视企业对利润分析的细微程度,也可为各种间接费用,营业外|其它业务收支,资产减值损失等建立对应的值字段.
图6是一个值字段的例图.
图6建立的值字段是基于Costing-based PA分析的带期间差异的实际利润分析(回顾图1-[1]),一般地能做到收入和实际销售成本配比的相对毛利法就可以了,所以你看到值字段包括成本部件(Defined by Tcode:OKTZ,关于成本部件及其差异如何传输进PA稍后会有详细描述)和相应的成本部件差异.
关于值字段Value field,总结几点:
field有俩种类型,Amount和Quantity型.大多数情况下可能Aggregation都会选择SUM(汇总计算),在选择LAS,AVG必须仔细考虑.
field在Flows of Actual values配置中将用来对应科目(即成本要素),MM,SD的条件类型等.
3.有一个算是比较经典的问题,和SD紧密相关,在利润分析时,需要区分主营业务收入|主营业务成本,其他业务收入|其他业务成本(比如开销售定单销售原材料取得其他业务收入),主营业业务收入还区分国内国外收入等等,对于收入类科目使用Tcode:VKOA很容易区分出,但是对于各种销售成本科目就不容易区分了,正常渠道除非建立销售定单类型,再copy移动类型,动作量太大,但在CO-PA模块中就很容易区分,只要建立主营业务国内成本, 主营业务国外成本,其它业务成本的条件类型再建立对应的值字段就区分开了.
4.可预留出一两个value fields给未来不可预见业务,以免在CO-PA使用过程中去增加.
思考:
特征通常可理解为有固定数据的字段比如产品,物料等,而值字段通常对应的金额,数量数据一般可变的,比如产品的销售数量,单价和金额,现在的问题是如果将一些数量字段强行设置成特征会有什么结果?
三.维护经营范围(Tcode:KEA0)
图7-[3][4]:如果需要,可以同时使用两种利润分析类型.
图7-[5]:使用第一步和第二步建立的特征和值字段建立利润分析的数据结构,必须激活
数据结构,产生Co-PA Table,表名称是CE1-4+经营范围名称.
图7-[6]: 在属性页中定义Co-PA使用的币别和会计年度变式,
然后必须到Environmen激活该经营范围,在激活OC时动态产生client相关或client无关的一些程序代码.
获利分析和辅助核算
国内ERP系统似乎很喜欢整辅助核算项目，比如销售收入科目整了两个核算项目，一个是物料，另一个是销售类型（内销|外贸出口|自营出口），是不是销售成本也要这样整？通过核算项目达到类似的基础的简单的利润分析目的，不知道随意的辅助核算项目在信息分析和业务处理上有什么不便，显然分析维度过于受限制,获利分析的灵活度不高，我总警告说ERP设计不要企图在财务模块中解决一切问题。
不要看获利模块吹呀吹的，说白了，获利分析设计思路上其实非常简单，就是从客户/物料/销售订单等主数据整些字段动态生成一套数据，再在业务处理时将数据写入该模块而已，就是预先将多个模块数据整合，举个实例，做个销售分析报表，从销售订单收入会计凭证客户物料等表去抓数据，中国报表一般比较变态，从10个8个不同数据源抓数据很正常，而这些表都是超大的，尤其是ERP运行了若干年后，所以如果不实现在一个地方组织好这些数据，开发的报表一般跑十个八个小时它是不出数据的，正因为如此，才会有数据仓库（商业智能）系统出现，如果有了商业智能，如果考虑服务器性能和数据空间，实际上基本上也可废除获利分析模块。
关于维护经营范围,也总结几点:
1.在建立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意义读者可自己去研究.
2激活Environment 时SAP做了什么动作?
就是产生了一堆激活client相关和client不相关的COPA部件,简单的举个例子,KE24|KE25随着不同企业的OC利润分析的需求而造成特征和值字段,这两动态产生的程序当然也不同,这种随配置不同而动态产生不同的程序(当然是有规则的)是SAP系统设计的又一大亮点.
四.设置经营范围(Tcode: KEBD|KEBI|KEBA)
这动作不过是赋给OC parameter ID一个default值而已,如果系统使用了多个OC就很有用处,类似的Tcode还有AM 中的OAPL :Set charts of Depreciation 和 OKKS:Set default cotrolling area ERB.
如果需要可以维护用户参数(Tcode:SU3|Su01)将参数ID设置一默认值,想获得某字段的参数ID,对着字段按F1就能获知,这是一个小使用技巧.
你可以同时使用两种理论分析类型,下面详细描述其不同之处:
-base 和 accounting-based利润分析的区别
-base 和 accounting-based 区别前者采用value field,可对应到cost/Revenue成本要素,MM|SD的条件类型,而后者采用的只能是成本要素,各种数据都保存在值字段里.
b.在对应关系上,value field可对应一到多科目(成本要素),而后者很好立即一个成本要素和会计科目必须是一一对应. 居于前者更灵活,通常企业会选择前种类型,可同时选两者.
-based更灵活,可以同时采用两种利润分析类型, 在进行利润分析或定义报表可以在两者之间进行切换, Costing-based有其缺点:
-based CO-PA的缺点分析.
a.时间差异
一个实例是SD,已发货但是没biling,(销售成本COGS只有当billing时才到CO-PA), 此时COGS 被post到 FI, 但是CO-PA却没有.
b.应计问题
比如在传输sales order到CO-PA时,一些应计费用通过SO的condition传到CO-PA模块,但从财务角度,这些费用并没发生因此在FI中也不存在..
c.货币转换时的汇率差.
特别是对一跨国集团,涉及多币种时的转换无可避免地产生汇率差异.
3.在Costing_based和Accounting_based利润分析切换
如果同时使用了两者，可使用KEBA|KEBD在两者间切换,此时KE24,KE25标准的利润实际|计划行项目分析出现的屏幕将不一样,可使用KE3K为Accounting_based分析定义利润分析用的成本要素组.
*关于利润分析报表编写在后面会有详细描述.
基于帐户和基于成本的获利分析
CO-PA模块有两种获利分析， 基于帐户和基于成本的获利分析。
随机获利分析
基于成本的获利分析主要提供用于销售管理的、暂时的利润分析。在该分析 中，成本和收入是按照边际贡献结构的细项存储的，而这一结构则通常对应于生产成本会计中的明细成本组件。
估算成本
除了记录销售收入和销售折扣外，您可以计算一套不同于财务会计中相应信息的成本和折扣。比如，在给客户开发票时，您可以根据估算生产成本 或 原 料 价 格计算销售成本以评价相应交易。
您可以就已记帐的销售收入、折扣和产成 品成本(一般在分配了期间生产成本 差异之后)在帐户组一级或在边际贡献的行项级同财务会计对帐。
基于成本的获利分析通过向您提供完整的、截至目前的获利情况使您可以有 效的控制企业的销售。
一致的获利分析
基于帐户的获利分析的主要目的之一是保证获利分析同财务会计在帐户 一 级是一致的。系统依据财务会计的计值基础将所有的收入和成本同时计入财务会计和获利分析系统。两个模块中有关的帐户分配直接依开发票或定单结算等相应的业务 活 动确定。不同于基于成本的获利分析， 基于帐户的获利分析在发货时计算销售成本，就象财务会计一样。
帐户分类
如果您使用基于帐户的获利分析，那么它的优势在于：在财务会计、管理会 计及获利分析模块中，数据都按帐户存储。这可使您在整个财务系统范围内对所 有的数值定义统一的分类结构。
您可以同时使用两种获利分析方法。如果这样的话， 基于帐户的获利分析就成了财务会计数据同基于成本的获利分析数据对帐的桥梁。
基于帐户的获利分析可使您按帐户反映利润，从而保证在成本会计结算的各阶段，其数据与财务会计始终是一致的。
数据保存：
costing-based :CE1**** CE2****
account-based:COEP COEJ
第二节 获利分析段PSG
在销售成本会计中，必须协调期段获利分析的目的与及时的销售管理的目的。这两个功能的很多需求在 形式和内容上都是重叠的(比如，一个市场段的获利分析单元在特定时期的实际边际贡献)。销售管理经常提及以下问题：
? 销售总额与销售净额的比率是多少？如何对指定获利分析单元的销售折扣作进一步的分析？
? 某一客户定单的毛利是多少？
? 哪一产品或市场的销售额增幅最大，或边际贡献最大？
? 最重要的获利单元是否发生了变化？
? 每个产品计划的边际贡献是多少？
什么是获利分析段？
获利段（PSG）是特征的一个唯一组合,通常可将产品,产品组,客户,客户组,销售组织,分销渠道做为一个利润分析段.
定义产生获利分析段的特征,PSG的特征可用于信息系统和利润计划,有这么几条原则:
1.通常象销售定单,成本对象这样的最好不要用于产生PSG的特征
2.客户和产品似乎总是PSG特征,即使你不设置它们为PSG特征.
3.为了提高性能,可以考虑将一些特征不设置为PSG特征(顾问只要糊弄通配置就可以,
谁搭理什么性能问题?)
4.为了提高性能,可以定义PSG特征的例外,即在某些条件下让这些特征不形成PSG
利润分析段的编号和其它的凭证编号一样.
图1-[1]:客户这字段我故意没用于PSG特征,但系统不买帐, 似乎系统认定客户必须是PSG特征,这好理解,获利分析都不根据客户哪成何体统?
图1-[2]:WBS element&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关联
第三节 特征值派生和值字段评估
幽他一默,我做SAP已经做了整整两年这么久,非常感冒业界两句话,一是XX ERP只有D国
人才能写出来,二是某某ERP博大精深,难于摸透.第一句话实际上就是外国月亮比中国圆的
翻版, 人不都是娘生妈带长大的吗?哪个系统不是无数的Bug修理从小到大走过来的,咱整不
出ERP已经非常可悲,如果别人整出来的东西宰都宰不了那就真的是可耻了;关于第二句话,
我就问什么是博大精深,答曰什么流程在系统都能实现,我再问为什么什么流程都能实现,他
又答不上来.
最近大家忙着学习八荣八耻,其中有一条是”以崇尚科学为荣,以愚昧无知为耻”, 实际上就是人家系统架构搭的好而已,为此我也总结了SAP的八大设计亮点,在此就不一一详介绍,其中一条就是大家熟悉的用户增强,留下出口你想怎么玩就怎么玩,这种设计思路在SAP的各大模块的各个交易事务(码)中被应用得淋漓尽致,但不管如何,任何系统它最终都是代码,代码再复杂一定程度上逻辑也是死的,如果连这点都没意识到有不认真宰就跟着瞎起哄喊什么博大精深那就未免有点愚昧无知了,所以下次我还听到次等荒谬论调,我就准备建议他老板放他几天假让他去参加八荣八耻的培训.
一.定义特征派生(Tcode:KEDR)
为用户自定义的特征维护特征值(Tcode:KES1).
在建立特征时我特意强调了自定义字段的检查表(check table),现在假设WW098,WW099在定义时使用了check table, WW098是表示产品Brand,系统就会检测WW098的check table是否维护了品牌,如果没找到就会有错误,而WW099表示销售区域,可以在此维护Region,在接下来将Sales office推导为Sales region.(请参考本小节的图4的Derivation rule)
对于那些自定义的特征没有采用check table这步不用做,只要直接使用KEDR维护推导逻辑就行.
可以建立特征层次(Tcode:KES3),比如可为产品和物料建立层次. 比如一个销售车辆的公司的产品层次可能是这样的,第一层次是国产车和进口车,第二层次是汽车,火车和坦克(属于贩卖军火),第三层次是具体品牌小轿车等等.
*特征层次结构的概念在SAP的BW中被广泛应用.
使用特征推导
Derivation的意思是派生或推导,简单理解,就是一些特征的可以让用户根据需求去定义自己的逻辑取值而已,下面详细介绍如何使用各种推导 .
图3表示有5种方式可以建立推导的步骤,下面一一举例介绍这5种推导的玩法.
rule.
图4是一个使用Derivation rule推导的例子,表示的是是如果Sales office = 3100(双击进去对应图4-[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,表示改推导规则成功!
loopup
在Table lookup中,可使用多条件,如图5,以为销售办公室和销售组推导为例,新建Table look后输入table KNVV.
在表格查询(Table look)中
move直接根据条件从一个COPA特征字段或SAP字段给另一个COPA特征字段赋值,如图7.
这个Move推导表示,将源字段Production name(图7-[2])第11位起取5个字符到目标->自定义的特征WW003(图7-[5]), 可以直接Move整个源字段到给目标字段(图7-[4]),还可选择相关条件(图7-[6]),表示符合条件的记录Move才生效.
不贴图了,其实就是将一个特征值内容给清空.
有一天有个企业的关键用户X弟兄在MSN是这样和我聊.
X弟兄:增强我现在玩的贼熟.
老屠:你怎么学起我说话来了呢,老是贼呀贼的,干吗呢,最近遇贼了?
X弟兄:你不知道企业上ERP等于上了贼船,最近忙的贼累.
老屠:企业上ERP是上了贼船,你搞ERP那可是贼上了船.
X弟兄:正经跟你讨论CO-PA增强问题.
老屠:哎,虽然我这人一向比较谦虚诚实,但是增强这种杀猪粗活兄弟最好就不要在俺面前炫耀什么贼熟,你知道吗?孔老夫子曾云:Never在屠夫面前炫耀杀猪.
X弟兄:孔子不是只说过君子远庖厨,意思是要远离你这种杀猪的.
老屠:那是孔老大虚伪,要不以前人家称儒生为腐儒呢,大块大块吃肉时这些就忘记了没有杀猪的他那能吃上肉,据历史学家考证,应该是某次孔老大被杀猪的奚落后才说Never在屠夫面前炫耀杀猪,后来他学生觉得此话太粗,所以改成君子远庖厨.
X弟兄:你少来,老孔应该不会说Never吧,那时中国人不说E语.
老屠:他不与时俱进行吗?你看现在这形式,孔老大要是换在今天不懂E文那也是个文盲.
有集中情况下使用增强我觉得比较合适,第一逻辑相当复杂,既然是自定义程序,就应该能满足这个原则:凡是SAP里面有的东西,它就是躲到天涯海角都一定能抓到.第二推导行次过多而这些行次逻辑类似,比如一系统涉及成百上千Sales office的推导,如果用Table lookup那不知道要多少行,第三,用于做特征的组织字段变更比较频繁,这样可以使用增强,然后自定义一配置表格,如果发生变更,只要SE16|SM30维护相应表格就行,不要去维护推导又重新生成传输请求,特别是在大集成的Server,这点非常重要,我负责过一跨国公司的维护,一般我都极力赞同这种方法.
依旧以销售办事处和销售组的派生为实例,步骤如下.
I:建立增强(Tcoede:CMOD).
如图8,使用CMOD建立增强项目ZCOPA001包含增强COPA0001,本来一般的增强是可以直接在SMOD激活增强就可以,不一定需要CMOD建立一个项目,但是这个增强需要建立项目.
II.建立推导增强(Tcode:KEDR)
图9-[1]:源文本可以看到增强的源代码.
图9-[2]:增强的名称 .
图9-[3][4]:一定要选择源字段,这些源字段将作为增强的条件输入从而获得目标字段内容.
图9-[5]:可以选择满足什么大条件在执行这个增强,实际上在增强程序本身就可以限制条件,SAP玩的动作就是花.
III.准备主数据
SE16:V_TVBUR->维护销售办公室
SE16:V_TVKGR->维护销售组
OVXM:给销售范围分配销售办公室
OVXJ:给销售办公室分配销售组
XD02:将销售办公室和销售组分配到客户销售主数据中.
IV:参考增强代码
COPA0001-> EXIT_SAPLKEDRCOPA_001函数包含ZXKKEU1.
增强程序ZXKKEU11程序示例代码如下:
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" 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是输入参数,注意这段输入参数只包含图9-[3]定义的源字段,将I_COPA_ITEM赋给临时的ST_COPA_ITEM,使用它的目的是ST_COPA_ITEM做为一Work area可以更好赋值,然后再将增强修改后ST_COPA_ITEM赋给输出参数 E_COPA_ITEM.
V.测试增强效果
如图10,在KEI1中设置科目400001000的PA传输结构,FB50手工记帐,选择PSG做成本对象,手工记帐是更便于分析推导结果, 然后输入客户,公司代码,销售组织,分销渠道,部门5个条件,可以在增强处设置断点,看是否能正确从客户主数据中获取销售办事处和销售组.
图10-[2]:客户主数据Sales area截图.
图10-[3][4]:输入5个条件然后按图10-[4]的派生就能从客户主数据中带出销售办事处和销售组.
推导小结:
*1.在特征推导中,不要企图对值字段进行进行赋值,否则会有错误,关于值字段的推导在值字段评估增强中编写(Tcode:KE4U),同样在值字段增强中不要企图更改特征内容一样会导致错误.
*2.最近在狂整BW&BCS,在BCS的源数据基础的数据将合并数据加载到合并数据基础中采用的映射(Mapping)原理和这类推导规则的思想基本相同,倒是,在BW的更新规则做成这样table lookup,Move拖拖拽拽多方便.,只要长了手的这种细活都能做, 哎,写BW的这些哥们完全应该向搞Co-PA推导这段程序的哥们多学习学习,方便用户.
二.值字段评估(Tcode: )
图1-[1]:定义和分配评估策略,可以为值字段定义评估增强(Tcode:KE4U).
图1-[2]:定义评估如何访问标准成本估算
图1-[3]:为实际成本/ML定义一通常叫COGS-Adj.的值字段.
图1-[4]:可根据产品,物料类别或其它特征分配成本码Costing Keys.
图1-[5]:将成本部件分配到值字段(Tcode:KE4R).
图1-[6]:利用条件和成本核算单位技术映射条件类型到值字段.
下面将意义从易至难介绍如何使用这些东西.
一．定义访问标准成本
图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 ,则标准成本估算的取值会根据相应的设置逻辑.
图2-[4]:
图2-[5]:
图2-[6]:
可以将定义好的Costing Key分配给产品,物料组或任何特征(Tcode:KE4H|KE4J|KEPC),在
KEPC中可以继续编写增强.
二.定义访问实际成本/物料分类帐
三.为成本部件分配值字段(Tcode:KE4R)
四.定义和分配评估策略(Tcode:KE4U)
KE4U:
设置Exit NO U01.
分配Costing key给Record A,B,C F等.
*----------------------------------------------------------------------*
* INCLUDE ZXKKEU03 *
*----------------------------------------------------------------------*
*field-symbols: <gs_ce_bukrs> type any. assign EP_SOURCE_BUKRS to
*<gs_ce_bukrs>.
*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 .
是将这两值字段给固定值.
有正常的标准成本估算，月末生产订单差异结算时，此差异如何通过CO-PA能分出其中料、工、费的差异,没上物料帐，CO-PA在PA transfer structure 中有9项对应的差异，但与料、工、费不是一一对应的。不知如何来对应，请高手指点！ 我在COPA中的计划用KE1E传输成功, 可是用MC89却看不到数值, 不知道为什么, 哪位能告诉我是不是有什么地方配置没有配呀
COPA_PROFITABILITY_SEGMENT
K_COBL_TO_COPADATA
K_COBL_CODINGBLOCK_DERIVATION
1KEI : transfer Asset to PCA ?
