SAP Profitability Analysis Configuration

SAP Profitability analysis configuration updated Jun 2, 2011 8:46 am | 43,561 views

[edit] CO-PA Profitability Analysis CO-PA Profitability Analysis is a drilldown report which allows s lice & dice multi-dimensional sales profitability analyses by variety of analytical segment (which is called Characteristics) such as market / region, prod uct, customer, product hierarchy, customer hierarchy, profit center etc.., most of those characteristics can be filled in by standard SAP functionality i.e. customer master or material master. By making Distribution Channel as a c haracteristic, CO-PA enables more flexible analysis. Distribution channel is filled in when sales order is entered. User can differentiate distribution channel if they need to take separate analysis (such as between wholesale / retail, goods sale / commission sale / service sale etc..) without maintaining master data. (The customer & material master maintenance hassle caused by multiple distribution channels can be solved by VOR1 (IMG Sales and Distribution > Master Data > Define Common Distribution Channels).) CO-PA allows to take in non SAP standard data by using External Data Transfer, but the major benefit of CO-PA is that it has close relation with the SAP SD module. SD profitability data is automatically sent forward and stored within the same system. In fact, SAP SD module without CO-PA Profitability Analysis is like air without oxygen. It is pointless using SAP without it. Overhead cost allocation based on sale is possible by CO-PA, which is not possible in the cost center accounting. Gross Profit report is possible by sales order base (as a forecast, in addition to billing base actual) by using costbased CO-PA.

CO-PA is especially important since it is the only module that shows financial figures which is appropriate in terms of cost-revenue perspective. For this reason, BW(BI) is taking data from CO-PA at ma ny projects. BW(BI) consultants are sometimes setting up CO-PA without FI/CO consultants' knowing. CO-PA captures cost of goods sold (COGS) and revenue at billing (FI release) at the s ame time (cost-based CO-PA). This becomes important when there is timing difference between shipment and customer acceptance. COGS should not be recognized, but FI module automatically creates COGS entry at shipment, while revenue entry will not be created until billing (or FI release). Such case happens when for example customer will not accept payment unless they finish quality inspection, or for example when goods delivery takes months because goods are sent across by ocean etc.. [pdekyvere: It is especially delicate to customize the copa infosource to map to your specific operating concern. This seems to be easier since s ince ECC6.0 Enh pack 4 (auto generated).] For this point, CO-PA (cost-based) does not reconcile with FI. But this is the whole point of CO -PA, and this makes CO-PA essential. Account-based CO-PA is more close to FI module in this point. Account -based CO-PA is added later on, and it could be that it is simply for comparison purpose with the c ost-based. Cost-based CO-PA is used more often. When CO-PA is used in conjunction with CO-PC Product Costing, it is even m ore outstanding. If fixed cost and variable cost in CO-PC cost component are appropriately assigned to CO-PA value fields, Break-Even-Point analysis is possible, not to mention contribution margin or Gross Profit analyses. Consider that BEP analysis o r GP analysis are possible by detailed level such as market / region, product group, customer group etc.. This is not a surprise. CO-PC is for COGM and inventory. CO-PA is for COGS. What do you d o without CO-PA when you use CO- PC? It’s a set functionality. This doesn’t necessary mean CO-PA is only for manufacturing business, though. Conservative finance/sales managers are reluctant to implement SAP R/3 sometimes because they are frightened to expose financial figures of harsh reality. Needless to s ay it helps boosting agile corporate decision-m aking, and this is where top-down decision to implement SAP R/3 is necessary. Those managers will never enc ourage R/3. SAP R/3

realizes this BEP analysis even for manufacturing company. No other ERP software has realized such functionality yet. Even today R/3 is this r evolutionary if CO-PA is properly used. Role of capturing COGS-Sale figures is even more eminent in the cases of s ales order costing or Resource Related Billing, and Variant Config (configurable materials) with PS module or P M/CS module. (Equipment master of PM/CS is also a must to learn.) After determining WIP by Result Analysis, CO-PA is the only module that displays cost revenue-wise correct financial figures. PS is n ecessary for heavy industry or large organization, Variant Config (configurable materials) are also handy for large manufacturer or sales company. RRB is usable to nonmanufacturing industry. RRB is indispensable for IT industry or consulting companies. The importance of CO-PA will be proven if used with these. Production Cost Variance analysis is possible b y assigning variance categories to different COPA value fields in the customizing. There are projects who had to d evelop production variance reports because they k icked COPA out of the scope without ever considering SAP s tandard functionality. Why do you cripple standard SAP functionality, simply because you are ignorant of anything more than CCA Cost Center Accounting or PCA Profit Center Accounting? Naturally it takes time to apprehend overall SAP functionality. This is where experience makes difference, which makes no wonder. Settling production variances to COPA raises one issue. Variances originated from WIP or Finished Goods at month end all go to COPA i.e. COGS. Actual Costing by using ML Material Ledger solves this issue for the most part. Variance reallocation whose origin is unknown is only made to COGS and FG, not made to WIP. This is something SAP should have rectified long time ago. They made excuses that they didn't have enough resource to do that, developing BW, SEM-BCS, or New G/L on the other hand. Realtime consolidation became impossible in SEM -BCS, and New G/L isn't adding much of new functionality other than parallel fiscal year variants, in a practical sense. What SAP does is, they spent all their resource and effort in only revising the same functionality using the new technology, but nothing much was made possible from an accounting point of view. [pdekyvere: ML can also be used to reflect transfer pricing or group valuations with specific buckets i nto copa value fields.] Actual cost component split is also poss ible with ML, but you have to plan well in advance lest you use up value fields. [pdekyvere: COPA can also handle planning and actual/plan reporting. it has a built in forecasting engine (planning framework) and can handle top down or bottom up planning (using different versions, as well as plan allocations and distributions from Cost centers. an FI/MM interface allows you to post to specific COPA value fields for FI or MM based transactions (overheads or non-trade specific charges that impact the product profitability) such as trade show expenses etc..] Configuration of CO-PA can sometimes be a bit of hassle. But it is far e asier, cheaper and quicker than building infocube in BW(BI) from the scratch. If you know what you do with BW(BI), in m any projects they take data from CO PA table. Then why bother creating additional work of building BW(BI)? It is not the first thing to t urn to. Training course of CO-PA is just 5 days. Competent consultant should not spare such sm all investment. You will see there is more to learn about it in addition to that. SAP is whimsical and they sometimes exclude CO-PA, CO-PC from the academy curriculum. They are not eager to keep trainees to have the right understanding of how to use their product. This is why many FI/CO consultants are ignorant of CO-PA and CO-PC, and o nly an experienced consultant knows its necessity. CO-PA is a must for experienced FI/CO consultant.

One point which has to be a dded is, keep Segment Level Characteristics as little as possible. I sometimes hear users linked too many characteristics, and completely ruined CO-PA database. If you look in their config, they link 5 customer hierarchies, 6 us er-defined product hierarchies on top of standard product hierarchy,

material code, sales rep in the sales order line level, and 4 other user -defined derivation segments as Segment Level Characteristics. Now their CO-PA table doesn't respond other than s hort dump in 3 years usage. SAP clearly explains and dissuades from just adding sales order as segment level, a nd it is always a struggle. Whatever they were thinking in adding 45 segment levels. It was once a controversy. Data segregation from program logic, data normalisation and elimination of duplicate entries. That gave birth to SQL database which SAP is running on. Now SAP users don't know such history, and repeat the same failure. They have corporate reshuffling and need to revise product lineup, then maintain product hierarchy. Why adding segment levels every time you have reshuffling? No matter how you have new tool, there's no end. It's not tool itself. It's people who is twisting the case. Successful usage would be product hierarchy 1 , and maybe 2. Segment data is stored at sales order line level unless you configure summarization. You can download the segment da ta, this may be a remedy. Data feeding and presentation in BW maybe another way. If you set up created CPU date (HZDAT) as an Index Key of your COPA db (CE1xxxx) (maybe development or technical topic), Delta extract for the BW cube works fine even after 5-7 years or more. You would do data arc hiving by the time it face any problem.

Related White Papers and Webcasts