Overview
In SAP COPA, you can use summarisation level as one of the key measure to improve processing time of reporting, planning and assessments. This will also lead to better system performance.
Transaction processing within COPA, initially, reads data from summarisation tables and then from segment tables and then from line item tables. By building summarisation levels (in COPA) tailored for specific transactional processes that involve large volumes of data or large processing times, you can significantly reduce those processing times and improve the performance of the system.
In this blog, I will provide a step-by-step demonstration of how to define a summarisation level in SAP Profitability Analysis (COPA). In my previous blog, I provided an overview of summarisation and its importance to SAP COPA.
Blogs on summarisation
To identify this series of blog, I have categorised the blogs under SAP > COPA Summarisation. If you have questions/ comments/ suggestions, please send me your comments in the form below. Sharing your questions and experience using comment box below will help other readers to gain additional knowledge involved in this functionality.
Share this blog with your network using one of the social media icons at the top or bottom of this page.
#1 Summarisation levels in SAP COPA – an overview
#2 Summarisation levels in SAP COPA – define your summarisation level
#3 Summarisation levels in SAP COPA – build your summarisation level
#4 Summarisation levels in SAP COPA – Tips to optimise your summarisation level
Assumptions for this blog
I will assume you are aware of SAP Profitability Analysis module and its functionality and semantics. My previous blog provides an overview of the functionality of summarisation in COPA. It is useful to read that blog before you proceed with this. Operating concern ID used in these blogs is V000.
Business Scenario
Our SAP client wants to create a COPA product profitability report by plant, company code, and sales organisation. In this report, customer information is not required. They have defined the value fields required in the report. Since summarisation is relevant to characteristics only, I will not detail the value field requirement of the business.
In this scenario, we will create a summarisation level with product, plant, company code, and sales organisation as the characteristics.
Define Summarisation levels
The following tables are configured to define summarisation levels. Configuration can be done in IMG Path
Controlling > Profitability Analysis > Tools > Summarisation Levels > Define summarisation levels
- Define summarisation level ID
- Define characteristics to summarise (define which characteristics should be summarized and which not)
- Define indexes for summarisation level (fine-tune the way the system accesses the summarization levels)
Define summarisation level ID
Here you define a numeric code (maximum 6 digits) and a description to identify your summarisation level. Once you create a summarisation level ID, the system automatically created a key table (equivalent of CE4V000) and a total table (equivalent of CE3V000).
Data is populated when you build the summarisation level. Data is not populated when the level is defined.
Each summarization level has a status which tells you whether or not the summarization level can be used.
- To be created: This is the status when summarisation level is being defined and has not been saved.
- Active, without data: The summarisation level has been defined and saved, the tables are generated and the status changes to “Active, without data”.
- Active: Once Summarisation levels are built with data, the status changes to “Active”.
The overview screen shows the technical details associated with this summarisation level.
Define characteristics to summarise
Here you can define which characteristic you want to summarise data by. You have multiple options on how to populate the field:
- Wildcard “ * “ – this will summarise all characteristic values for that specific characteristic
- Specific entry (eg..company code = “V001”) – this will summarise data for only that characteristic value against that characteristic. In the example, it will only summarise data for company code V001
- Blank – this will exclude the characteristic from summarisation
- Hashtag – this will include the characteristic for summarisation where the characteristic value = blank.
Default characteristics in summarisation
When you define characteristics you want to summarise, the system will default some characteristics (like Fiscal Year, Period, Plan/ Act Indicator) with a wildcard entry. These cannot be removed; they can be substituted with specific entry.
Define indexes for summarisation levels
If you do not define any indexes here, the system will create a default when you save. This default should be sufficient in most cases. You should not need to change this until your summarization levels contain a large amount of data in the key table.
You can define upto 15 indexes. Index can be single column (one characteristic per index) or multi-column (up to 5 characteristics per index).
Conclusion
Configuring summarisation level is, by itself, straightforward. The critical part is the designing of COPA to ensure you define a summarisation level fit for purpose and optimised for performance.
However, SAP COPA will read summarisation level only if the summarisation table is optimised for that transaction. If it is not so optimised, it will read the segment table or even the line item table. It is very critical that summarisation levels are defined with precision and care. You need to run transactions in pilot or test mode and optimise the summarisation level till you are sure that the system reads only the summarisation level. To identify which summarization level could be created, we can run transaction KEDVP. SAP will do some checks on usages and propose appropriate Summarisation levels (Thanks, Phillipe for the suggestion).
In the next blog, I will illustrate how to build/ populate summarisation tables with data. I will also offer tips and recommendations, based on my experience and SAP recommendations, on how to optimise the use of summarisation levels.
Please Share
I hope this blog has helped you understand the design of summarisation levels in SAP COPA. Please do leave your comments below whether this article was helpful; and whether you have any suggestions/ comments; or if you would like to share your experience with Summarisation levels.
I strongly recommend you share this blog with your network using one of the social media icons at the top or bottom of this page.
You could subscribe to a newsletter from this blog using the rss icon on the top right of this page.
Blogged: Summarisation levels in SAP COPA #2 – define your summarisation level bit.ly/JFWuBW #in
— Rajesh Shanbhag (@rshanbhag) May 15, 2012
View my presentation on Slideshare
Summarisation levels in sap copa slideshare
Index of my blogs on SAP COPA Summarisation
#1 Summarisation levels in SAP COPA – an overview
#2 Summarisation levels in SAP COPA – define your summarisation level
#3 Summarisation levels in SAP COPA – build your summarisation level
#4 Summarisation levels in SAP COPA – Tips to optimise your summarisation level
———————————————————————————————————
Rajesh has optimised SAP Finance solutions for several customers. Rajesh has 12 years experience implementing SAP / IT / BPM Finance solutions for several customers globally; with a strong focus on Management Accounting and Reporting primarily Product Costing, Profitability Reporting and Material ledger (Transfer Pricing, Actual Costing). He also has 7 years experience working in the business in Finance and Accounting functions. His business process knowledge combined with his IT expertise enables him to provide his customers with best-of-breed advice on business process / IT implementations.
Hello
Nice article, I have some suggestion,
For identify which summarization level could be created, we can run transaction KEDVP. SAP will do some checks on usages and propose it. If we validate it, we will able it into KEDV transaction like you mention.
Second point, on index. I’m not full agree with your position. Base on my experience, I check assessments and add in index fields used it (same with Topdown). By this way, we increase performance.
Philippe
Hi Phillipe
Thanks for your suggestions. I have included your suggestions in the blog.
Rajesh