Anda di halaman 1dari 7

SAP Profitability analysis configuration

updated Jun 2, 2011 8:46 am | 43,143 views


CO-PA Profitability Analysis

CO-PA Profitability Analysis is a drilldown report which allows slice & dice multi-dimensional sales profitability analyses by variety of analytical segment (which is called Characteristics) such as market / region, product, 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 characteristic, 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 cost-based 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 many projects. BW(BI) consultants are sometimes setting up CO-PA without FI/CO consultants' knowing. COPA captures cost of goods sold (COGS) and revenue at billing (FI release) at the same 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 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. Accountbased CO-PA is added later on, and it could be that it is simply for comparison purpose with the costbased. Cost-based CO-PA is used more often. When CO-PA is used in conjunction with CO-PC Product Costing, it is even more 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 or 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 do without CO-PA when you use CO-PC? Its a set functionality. This doesnt 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 say it helps boosting agile corporate decision-making, and this is where top-down decision to implement SAP R/3 is necessary. Those managers will never encourage 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 revolutionary if CO-PA is properly used. Role of capturing COGS-Sale figures is even more eminent in the cases of sales order costing or Resource Related Billing, and Variant Config (configurable materials) with PS module or PM/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 necessary for heavy industry or large organization, Variant Config (configurable materials) are also handy for large manufacturer or sales company. RRB is usable to non-manufacturing 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 by assigning variance categories to different COPA value fields in the customizing. There are projects who had to develop production variance reports because they kicked COPA out of the scope without ever considering SAP standard 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 into copa value fields.] Actual cost component split is also possible 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 easier, cheaper and quicker than building infocube in BW(BI) from the scratch. If you know what you do with BW(BI), in many 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 turn to.

Training course of CO-PA is just 5 days. Competent consultant should not spare such small 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 only an experienced consultant knows its necessity. CO-PA is a must for experienced FI/CO consultant.

One point which has to be added 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 user-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 short dump in 3 years usage. SAP clearly explains and dissuades from just adding sales order as segment level, and 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 data, 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 archiving by the time it face any problem.

1. What are the differences between Profit Center Accounting (PCA) and Profitability Analysis (CO-PA)? PCA PCA is aimed at Profit reporting on internal responsibility lines or SBU's PCA is limited to reporting by the profit center hierarchies that you can setup. PCA can be reconciled easily back to the GL CO-PA CO-PA is aimed at external market segment reporting for example by customer and customer groupings (industries), geographical areas. PCA can slice & dice your information by a variety of dynamic hierarchies (a 'Rubiks' cube is often used to symbolize this idea. PCA has 2 'styles'

Account based which will reconcile to the GL Costing Based which Allows approximations, estimations or standards to be posted, which may make reconciliation difficult to explain to the user

2. Why does SAP talk about statistical assignments in CO - why are these different from real Cost Accounting assignments? The reason is to facilitate reconciliation between FI and CO. The sum of all 'real' assignments in CO should add up to the sum of all expense and revenue postings (where cost/revenue elements have been created for the GL account of course) in FI. A normal expense invoice posting to expense accounts / cost elements will be a 'real' posting. If the system is displaying an error message insisting on a 'cost accounting assignment' and you think you have entered one, then possibly you have specified a statistical assignment. A common error is in thinking that the business area will do - Business areas are FI elements not CO elements.
Example: All Profit Center assignments are statistical EC-PCA is defined as statistical, therefore if posting to a revenue element, the system will insist on a real cost accounting assignment even if profit center is specified. A cost center will not do, since revenue elements are statistical in cost centers. The system will accept the following as real: CO-PA profitability segment, sales order, customer project or a revenue bearing order. 'Revenue' when defined to the system by setting up a revenue element is always statistical in a cost center. If however you

Revenue elements assigned to cost centers will always be statistical

have setup your revenue accounts as primary cost elements then the assignment will be 'real'.

3. What do you mean by Period based accounting (GL based) and cost of sales accounting (COPA based)?
'Period Based Accounting' is Accrual Accounting and 'Cost of Sales' is 'Cost of Goods Sold' Accounting. Period based Accounting "Period based" means that during the month or period, all and only actual events / transactions are posted in the appropriate period. At the end of the period estimated accruals and deferrals are made and posted to that posting period to give a more accurate view of profit. IE any expected revenues and expenditures that should relate to the current period are accrued for and equally any prepaid expenses or revenues are deferred to the next period. (Accruals and Deferrals are posted temporarily, usually to special accounts, and reversed prior to the next period end.) These accruals and deferrals are usually done at a fairly high level of summarization (eg: at company or business area). The FI Ledgers and financial statements etc are always period based. Cost of Sales Accounting Cost of Sales in SAP means that we attempt to record or rather report the "costs of sales" against the actual sale at as low a level as possible and during the period. (In CO-PA this is down to a transaction level.) This enables the company to get a reasonably accurate view of profitability on a real time basis. This is done by using either standards or estimates for many of the components that make up the "cost of goods sold". Any variations from the standards are usually posted through to the cost of sales system either at month end or when they occur. For example: A product cost estimate might be used to calculate and post a manufactured cost through to CO-PA when every sale goes through. The actual production orders variances from the product cost estimate can then be settled to a separate line in CO-PA. This has the benefits that a reasonably accurate gross profit could be reported in real time at a transaction level and of course therefore at all the characteristic levels in CO-PA. The impact of any abnormal variances in production can quite clearly be seen and analyzed separately from the normal profitability of a product.

4. How data flows from SD to COPA?

The normal SD document flow is as follows:

1. Sales order 2. Delivery (the delivery creates the goods issue, which debits COGS and credits Inventory COGS is updated in CO-PA at this time)

3. Billing Document (the billing document updates A/R, Sales revenue, Discounts, Freight, etc.) 5. How data flows from CO to COPA? Through Assessments. Allocates costs from cost centers to profitability segments. 6. How data flows through MM into FI? Through Account assignment model OKB9. Automatic postings created in materials management, can be passed on to CO-PA by means of automatic account assignment to a profitability segment. 7. How data flows from PP into FI & COPA? Through Production Variances. It Posts variances from the production (product cost) estimates or standards to the GL accounts and to Profitability Analysis if real costs are required (vs standard costs). Standard cost figures would have been used to update Stock and Cost of Goods sold figures when finished stock was issued from the production runs. 8. What do you mean by value field groups?
Value Field Groups represent the possible combinations of value fields in an operating concern. Value field groups are used to specify:

Which value should be made available to users entering or displaying a line item In what order these value fields should be displayed Which specific value fields can be filled

You plan your data for the characteristics Product, Product group and Customer group. You define three planning levels for which planning data is to be entered:Customer group/product group (independent of the product), product/product group(independent of the customer group), and product/product group/customer group(the lowest, most detailed level). By using transactionbased top-down distribution, you can ensure that all planning data is saved at the lowest level

9. What are Characteristics Values? Characteristics are aspects on which we want to break down the profit logically such as customer, region product, sales person etc. 10. What do you mean fixed characteristic fields? Predefined characteristic fields in SAP R/3 system, which are obvious, are known as fixed characteristic fields such as product, sales org and customer

11. What are Non-Fixed characteristics or user defined characteristics?

Up to 50 non-fixed characteristics can be added to an operating concern. E.g. Bill-to-party Create -> Derived the value from Table PAPARTNER (SD partner that can be used in COPA) -> Create user defined characteristic name WW008 -> Save