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

1.0 COPA获利管理包括利润分析（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-34:可以采用完全成本法和变动成本法另外,在启动CO-PA时,有两种类型的利润分析方式:基于成本(Costing-based)和基于帐户(Account-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).n 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. n The structure of an operating concern is determined by analysis criteria (characteristics) and the values to be evaluated (value fields).u Define Merck specific characteristics and value fields independently of the operating concern. u Before defining a new characteristics, look for existing fixed characteristics delivered by SAP.u Maximum allowed user definable characteristics = 50u Maximum allowed value fields = 120 IMG Path: Enterprise structure-Definition-Controlling- Creating Operating ConcernEnterprise structure-Assignment-Controlling- Assing Controlling Area to operating concern分配OC给CO area,在分配前OC必须已经产生了data structure.OC是获利能力分析中的核心组织结构，用来监控及分析各获利分析段Profit Segment。获利分析段通常是销售组织(销售办公室,销售人员),产品(组,Model)、客户(组)等的灵活组合,具体视企业的实际需要，以各获利段为依据生成获利分析报表，考核其获利能力。图1.0.1图- Maintain CharacteristicsT-code: KEA5 如图-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*特征.图-2图-4图-3如图-2,如在建立WW099时你选择了VBAP表,并且选择了MATNR和CHARG字段,很明显,保存后WW099特征并未建立而是将VBAP-MATNR和VBAP-CHARG建成了特征.如果想建立自己的特征,请选择User defined,如图-3:1用户自定义特征,2with 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名称. 如图-41.有的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相关表中了(请看.3 Maintain OC),这些是所谓的Fixed Characteristics,SAP已经提供了 客户|销售订单等表的相应字段可做特征,如有需要加上这些字段做特征字段, 并且用户还可定义自己的特征with Check table或without check table,这些特征并不基于上述SAP tables.2尽量优化使用特征和值字段,毕竟大量使用他们会对系统性能造成影响,虽然道理很明显越多的特征和值字段可能使分析更细,你需要在两者间平衡.3 在建立特征时,读者必须明白这些名词. 1Fix characteristic指固定的特征,比如客户,controlling area,sales.Org等,可这样理解就是这些字段在COPA的相关表固定存在,不管你有没有将其设置成特征字段.(注:你设置的特征字段将会形成COPA相关表的字段).2compound 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的数据量可能是巨大的,下面会有详细分析,所以你需要在利润分析程度和性能两者间平衡. Maintain Value FieldsT-code: KEA6在此着重介绍下如何根据需求维护自己的值字段. 值字段(Value field):是Costing-based PA的最小分析单位,通常它对应到销售数量,销售收入,销售成本,销售折扣,销售条件比如各种销售费用,各种差异等,这视企业对利润分析的细微程度,也可为各种间接费用,营业外|其它业务收支,资产减值损失等建立对应的值字段.关于特征字段,通常并不需要很多自定义的字段,相反,视想Co-PA分析多细,读者可定义很多自己的value fields,特别地, 甚至可定义自己的PA传输架构(T-code: KEI1),全部使用自定义的value field. 图.2-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-22如果需要,全部使用自定义的value fields,然后自定义描述,值字段在接下来来的Flows of Actual values配置中将用来对应科目(实际是成本要素),MM,SD的条件类型.3.是否需要区分主营业务收入(成本)和其他业务收入(成本)? 对于收入类科目使用Tcode:VKOA很容易区分出,但是对于各种销售成本科目就不容易区分了,正常渠道除非建立销售定单类型,再copy移动类型,动作量太大,但在CO-PA模块中就很容易区分,只要建立主营业务国内成本, 主营业务国外成本,其它业务成本的SD condition再建立对应的值字段就区分开了.4如果需要,预留出一两个value fields给未来不可预见业务,毕竟当OC被全部激活后要更改COPA数据结构是不容易的事情,假设企业忽然需要某种费用进入COPA而且还需要和其他费用区别,如有预留字段,需使用只要将其map 到此费用科目就可,这不是必需的,只是有些企业要这样做.5.读者思考:特征通常可理解为有固定数据的字段比如产品-物料,值字段的data通常可变的,比如产品的销售数量,单价和金额,如果将一些数量字段强行设置成特征会有什么结果?建立的值字段是基于Costing-based PA分析的带期间差异的实际利润分析,一般地能做到收入和实际销售成本配比的相对毛利法就可以了,所以你看到值字段包括成本组件(Defined by Tcode:OKTZ,关于成本部件及其差异如何传输进PA稍后会有详细描述)和相应的成本部件差异. Maintain Operating ConcernT-code: KEAO图-1如图-1:1输入OC名称STOC,保存后开始建立data structure ,2可使用Sample OC参考创建,在7.1.4中也可参考创建一OC,34两种类型的PA分析.图中表示STOC可采用两种PA类型,甚至在激活CO-PA (Tcode:KEKE)中可同时激活俩者,很可惜,在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,如图-2,1根据实际业务选择data structure需要的特征字段,为了便于说明,在选择了相关字段后按change view, 2可选择需要的value fields 字段用于建立data structure ,图-23为了便于说明,加上了俩自定义的特征,所以此俩表分别对应到check table 是T2503|T2504.图-3关于value fields,全部采用自定义的value fields,如图-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 itemsCE3STOC: Summary records by profit. segmentCE4STOC: Profitability segment definitionsTable 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.the posting period.CE4STOC_ACCT|CE4STOC_FLAG|CE4STOC_KENC意义?1会发现在CE1XXXX|CE2XXXX表中的COPA_AWSYS| TIMESTMP的字段就是你定义的特征和值字段(视实际情况可能有出入).2销售组织,分销渠道,客户,公司等必须字段尽管你在特征中未定义在这些表中也已经存在,这很容易理解,利润分析连这些最常用的字段都没了还谈得上什么分析?所以就做成default字段了.2 激活Environment 时SAP做了什么动作?就是产生了一堆激活client相关和client不相关的COPA部件,简单的举个例子,KE24|KE25随着不同企业的OC利润分析的需求而生成特征和值字段,这两动态产生的程序当然也不同,这种随配置不同而动态产生不同的程序(当然是有规则的)是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产生一系列表. 两者同样会动态产生一些相关程序.3. You have decided to use both the company code and operating concern currencies in costing-based PA. IMG Controlling Profitability Analysis Structures Define Operating Concern Maintain Operating Concern: Attributes tab Operating Concern Currency: EURO Company Code Currency: Selected Op Concern Crcy PrCtr Valuation: Selected Comp. Code Crcy PrCtr Valuation: Selected Sample Operating Concerns从SAP的sample OC中Copy所需的OC,同时将相关IMG也Copy过来,通常不建议这样做,毕竟每个企业有不同的实际业务需求,Copy SAP Sample OC显然难于达到需求. Define profitability Segment Char.T-code:KEQ3 SE16: V_TKEOE定义PSG所用到的特征,只有为OC定义的特征和值字段在利润分析段(PSG)才可使用,你还可决定客户,销售订单等固定特征是否可在PSG中使用(SAP默认是不用的). Set Operating ConcernT-code:KEBD|KEBI|KEBA 在Set OC时OC需要已经被完全激活(Tcode: KEA0),一个OC一次只可使用一个类型的COPA (Costing-based or Accouting-based)从程序来将,这动作不过是赋给parameter ID一个default值而已,类似的Tcode还有AM中的OAPL :Set charts of Depreciation 和 OKKS:Set default cotrolling area .图如果需要可以维护用户参数(Tcode:SU3|Su01)将参数ID设置一默认值,想获得某字段的参数ID,对着字段按F1就能获知,这是一个小使用技巧.你可以同时使用两种理论分析类型,下面详细描述其不同之处:1.costing-base 和 accounting-based利润分析的区别a.costing-base 和 accounting-based 区别：前者采用value field,可对应到cost/Revenue成本要素,MM|SD的条件类型,而后者采用的只能是成本要素,各种数据都保存在值字段里.b.在对应关系上,value field可对应一到多个科目(成本要素),而后者是一个成本要素和会计科目必须一一对应. 居于前者更灵活,通常企业会选择前种类型,可同时选两者.c.Costing-based更灵活,可以同时采用两种利润分析类型, 在进行利润分析或定义报表可以在两者之间进行切换, Costing-based有其缺点:2.Costing-based CO-PA的缺点分析.a.时间差异一个实例是SD,已发货但是没billing,(销售成本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 Transaction Data DataSource:KEB0如何增加特征和值字段?SE14一下有正常的标准成本估算，月末生产订单差异结算时，此差异如何通过CO-PA能分出其中料、工、费的差异,没上物料帐，CO-PA在PA transfer structure 中有9项对应的差异，但与料、工、费不是一一对应的。不知如何来对应，请高手指点！COPA中的计划用KE1E传输成功, 可是用MC89(销售和运作计划)却看不到数值, COPA_PROFITABILITY_SEGMENTK_COBL_TO_COPADATAK_COBL_CODINGBLOCK_DERIVATION获利分析段PSGPSG是特征的一个唯一组合,通常可将产品,产品组,客户,客户组,销售组织,分销渠道做为一个利润分析段.n It is advisable for performance reasons to keep to a minimum the number of profitability segments and therefore summary records required in CO-PA. This can be controlled through the selection of segment-level and non-segment-level characteristics. n It is possible to configure the system so that certain characteristics are not used in defining profitability segments. The impact of this is that the values for these non-segment-level characteristics will appear on CO-PA line items, but will not be available for reporting with the CO-PA drill-down reporting tool.定义产生获利分析段的特征,PSG的特征可用于信息系统和利润计划,有这么几条原则:1.通常象销售定单,成本对象这样的最好不要用于产生PSG的特征2.客户和产品似乎总是PSG特征,即使你不设置它们为PSG特征.3.为了提高性能,可以考虑将一些特征不设置为PSG特征4.为了提高性能,可以定义PSG特征的例外,即在某些条件下让这些特征不形成PSG5.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关联1.0.2 主数据IMG Path如图-1.图.2.1 Maintain Characteristic Values为用户自定义的特征维护特征值.在图3中我特意强调了data structure采用的这俩字段,WW098,WW099在定义时使用了check table,如果在PSG中要用到此两特征,顾名思义,特征的value必须在check table T2503|T2504内.图为用户自定义的特征维护特征值(Tcode:KES1).1假设在实际应用中WW098是表示产品brand,然后PSG中使用了WW098,逻辑就会检测WW098的check table是否维护了品牌,如果没找到就会有错误.2 对于那些自定义的特征没有采用check table这步不用做,只要使用KEDS维护derivation rule就行.WW098是表示产品Brand,系统就会检测WW098的check table是否维护了品牌,如果没找到就会有错误,而WW099表示销售区域,可以在此维护Region,在接下来将Sales office推导为Sales region.(请参考Derivation rule)对于那些自定义的特征没有采用check table这步不用做,只要直接使用KEDR维护推导逻辑就行. Define Characteristics HierarchyTcode:KES3 将特征分层,这也好理解.如果需要,可将特征分层次. 比如可为产品和物料建立层次. 比如销售车辆的公司的产品层次可能是这样的,第一层次是国产车和进口车,第二层次是汽车,火车，第三层次是具体品牌小轿车等等.*特征层次结构的概念在SAP的BW中被广泛应用. Define Characteristic DerivationTcode:KEDR 使用特征推导,Derivation的意思是派生或推导,简单理解,就是一些特征的可以让用户根据需求去定义自己的逻辑取值, 尤其在自定义的特征设置Derivation 十分必要.下面详细介绍如何使用各种推导 .1Derivation rule,图.3-3有个WW099对应到Sales office的rule,图-12Table lookup的条件和derivation rule不同的table lookup可使用多条件,3使用move可直接直接根据条件从一个COPA特征字段或SAP字段给另一个COPA特征字段赋值,4可根据条件将一些特征字段的值清楚 ,假设定义了一derivation rule,在一些公司中如想让这些derivation不起作用,就可在此设置条件等于此公司的将Derivation的特征值给Clear5可写用户出口给特征赋值(SMOD:COPA0001-函数EXIT_SAPLKEDRCOPA_001- Exit in Derivation Rule), 如果实际业务前面四种方法都不难达到用户需求,小写一个user exit也非难事,毕竟程序是最灵活的.注意：1、 Customer, product, controlling area, company code, 不能够被overwritten by derivation2、图-2图-1表示有5种方式可以建立推导的步骤,下面一一举例介绍这5种推导的玩法.1).Derivation rule.图-3 如图-3,这是一个derivation rule的例子：表示的是是如果Sales office = 3100(双击进去对应图-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中,可使用多条件,如图.-4,以为销售办公室和销售组推导为例,新建Table lookup后输入table KNVV.图-4在表格查询(Table look)中图.-53）.Move直接根据条件从一个COPA特征字段或SAP字段给另一个COPA特征字段赋值,如图.3-4,1move名,2Production name,源字段,3目标字段是自定义的特征WW003,4赋予整个值给目标字段,5ARTNR的值从第11字段开始取后5个字符赋予部分值给WW003.图.-6这个Move推导表示,将源字段Production name(2)第11位起取5个字符到目标-自定义的特征WW003(5), 可以直接Move整个源字段到给目标字段(4),还可选择相关条件(6),表示符合条件的记录Move才生效.4).Clear不贴图了,其实就是将一个特征值内容给清空.5).Enhancement有几种情况下使用增强我觉得比较合适,第一逻辑相当复杂,既然是自定义程序,就应该能满足这个原则:凡是SAP里面有的东西,它就是躲到天涯海角都一定能抓到.第二推导行次过多而这些行次逻辑类似,比如一系统涉及成百上千Sales office的推导,如果用Table lookup那不知道要多少行,第三,用于做特征的组织字段变更比较频繁,这样可以使用增强,然后自定义一配置表格,如果发生变更,只要SE16|SM30维护相应表格就行,不要去维护推导又重新生成传输请求,特别是在大集成的Server,这点非常重要,我负责过一跨国公司的维护,一般我都极力赞同这种方法.依旧以销售办事处和销售组的派生为实例,步骤如下.Step I:建立增强(Tcoede:CMOD).图.-7如图-7,增强项目ZCOPA001包含增强COPA0001,本来一般的增强是可以直接在SMOD激活增强就可以,不一定需要CMOD建立一个项目,但是这个增强需要建立项目.Step II.建立推导增强(Tcode:KEDR)图.-8图-8-1:源文本可以看到增强的源代码.图-8-2:增强的名称 .图-8-34:一定要选择源字段,将源字段作为增强的条件输入从而获得目标字段内容.图-8-5:选择满足什么大条件下才执行该增强,实际上增强程序本身就可以限制条件Step III.准备主数据SE16:V_TVBUR-维护销售办公室SE16:V_TVKGR-维护销售组OVXM:给销售范围分配销售办公室OVXJ:给销售办公室分配销售组XD02:将销售办公室和销售组分配到客户销售主数据中.Step 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)* REFER