Many of my clients use both the R/3 Controlling module’s Profitability Analysis (CO-PA) and the SAP Business Information Warehouse (BW). When one of them asked me which application would best satisfy a particular reporting requirement, I dismissed the issue as unimportant. Then a second client asked the same question, and I came to understand its validity.

Some firms issue guidelines that determine when to use CO-PA or BW for reporting requirements. Other companies might simply satisfy the requirement as quickly as possible without investing much thought as to which tool is best to use. Having guidelines is a good idea, because choosing the wrong tool might cost you in terms of performance, flexibility, or the integrity of the result. The following four factors will help you decide whether CO-PA or BW will better meet profitability reporting requirements such as sold-to customer project expense/revenue data, profitability by geographic region, or allocated overhead by product number. (See Figure 1 for a summarization of these factors.)

 1. Does the desired profitability reporting data involve data fields (characteristics) native to CO-PA? Even if the answer is Yes, can CO-PA feasibly report on them?

If the data requirement involves data elements that are not native to CO-PA, then obviously the reporting requirement must be met in BW. Examples of this include any profitability-related reporting requiring purchase-order data or accounts-receivable balance information.

What is more difficult to discern is whether the data with CO-PA-native elements can be reasonably reported upon within CO-PA. I define "feasible" in this case as reporting on segment-level or summarization-level data, not information residing at the line-item level.¹

The segment-level in CO-PA can be reported on using PA’s drill-down Report Writer. Certain characteristics are defined to be segment-level within configuration (transaction code KEQ3), and these characteristics are used for reporting on the data stored within CO-PA. The line-item data in CO-PA contains all the detailed, transactional information and can only be viewed by using the line-item display function (transaction code KE23) or the ABAP Query tool. Neither tool is particularly flexible for reporting functions.

Certain fields might not be designated as profitability segments due to performance concerns, but you might encounter a reporting requirement containing one of those fields. For example, the sales-order field is seldom identified as a segment-level characteristic. If it were, each sales order posted into CO-PA would, barring other segment-level characteristics, generate a profitability segment and thus degrade performance. A sales manager in certain circumstances might wish to see sales and detailed, broken-out cost of sales amounts by sales order, and this information is not available using the Sales Information System (SIS). In this case, BW is the appropriate avenue to satisfy the reporting need.

 2. How much flexibility does the reporting requirement demand?

This question directly relates to my first point in that you are trying to determine the feasibility of satisfying the reporting requirement in CO-PA. Is the required reporting grouped by the desired attributes? For example, CO-PA’s drill-down Report Writer gives you the ability to shift the characteristics about in the drill-down and report hierarchically among them. Does the reporting requirement mandate this level of sophistication within the report?

Let’s say that a sales manager would like gross margin information by sales organization and broken out by customer by fiscal period and year. Also, the manager has requested the ability to sort among these characteristics to show data by sales organization in a particular month or show data by sales organization by customer. Due to an oversight in the site’s PA configuration, sales organization was not selected as a segment-level characteristic. The information is instead in the line-item table in CO-PA (CE1GENU where GENU is the Operating Concern name). Consequently, providing the desired flexibility will be difficult with either ABAP Query or an ABAP report.

Generally, you should use BW if you need greater flexibility and more polished presentation to provide the report. BW’s query functionality allows users to sort and filter through this information much more easily in the above scenario. CO-PA can be used to satisfy simple slicing-and-dicing by characteristics defined at the segment-level within the Operating Concern.

 3. Will reporting on the requirement slow performance in CO-PA or require significant rework?

Depending upon your configuration, CO-PA reporting could already involve significant run times despite efforts to minimize them. Will satisfying the new requirement in CO-PA exacerbate runtime performance issues?

Meeting the new reporting requirement, for example, might involve adding a new characteristic to the Operating Concern and to the segment level. This will increase table size and create additional profitability segments, which will likely worsen reporting performance within CO-PA and, potentially, summarization levels. Perhaps the additional work of adding the characteristic to the segment-level and the summarization levels (and re-filling the summarization levels) is not worth the effort.

When accommodating a requirement in CO-PA can create or worsen performance issues, or if accommodating the requirement in CO-PA involves significant re-work, BW is a better fit to satisfy the reporting need.

 4. What level of data manipulation is required to arrive at the reporting result?

This consideration can be difficult to think through. How much calculation or data manipulation is required to arrive at the desired reporting attribute? The level of complexity of the data needed could dictate the use of either CO-PA or BW.

I usually recommend taking advantage of CO-PA’s natural ability to easily retrieve data by customer- and product-related attributes rather than force potentially complex extraction procedures within BW. For example, say you would like to view customer profitability containing certain selling expenses. These selling expenses are non-customer specific; the organization incurs them for most customers and posts them to cost centers. You determine that the most appropriate manner in which to allocate these expenses to the customers is by the quantity sold to them.

One possible method of meeting this requirement is to use CO-PA assessment cycles to allocate these costs to PA characteristics. The assessment cycle provides a tracing factor that allows you to specify the method of allocation for the costs.

If system performance is not a concern with processing the allocation, the assessment cycle can be created and managed rather easily within CO-PA. Attempting to perform such an allocation within BW would require more design effort. Data residing in transfer structures containing cost center data and profitability data would have to be combined using a transfer rule to perform the allocation. This risks damaging the integrity of the data to be reported upon.

BW and CO-PA offer different levels of reporting flexibility. Configuration changes or other projects that add functionality to your existing system will drive the need for additional reporting requirements, and you might be faced with a decision of where to satisfy them. It is always wise to have guidelines to enable you to decide upon the application best suited to satisfy the reporting requirements and avoid data redundancy.