Copa Summarization Level

Profitability Analysis CO-PA
Strategies for Using Summarization Levels

Content
Content and Target Group

This documentation contains the answers to some frequently asked questions about summarization levels in costing-based Profitability Analysis. Where necessary, some basic information about drill-down reporting is repeated in the appendix (section ). A second document will be produced on performance strategies, i.e. which of the available performance-improving tools (summarization levels, summarization data, frozen report data, report/report interface) should be used and when. This document is written for CO-PA consultants, advanced users, and others who deal with questions about optimizing performance when reading the data in Profitability Analysis. The subject matter here is of a very technical nature. Consequently, it requires a certain amount of time to familiarize oneself. A few rules that should at all times be observed are written in bold type and surrounded by a red frame. You should not deviate from these rules unless the situation has been analyzed in detail (where necessary, with the help of SAPs Second Level Support). In addition to reading this documentation, it is strongly recommended that you work on a project that allows you to gain practical knowledge.
Basic Facts About Summarization Levels

Please read the online documentation on summarization levels under Controlling Profitability Analysis Tools. In the transaction data1 in Profitability Analysis, the profitability segments are represented by a combination of individual values for all characteristics. A Summarization level is a copy of the
1
We consider the transaction data in Profitability Analysis to include the segment table CE4xxxx (the profitability segments), the segment level CE3xxxx (the period values for the profitability segments) and the two line item tables CE1xxxx (actual line items) and CE2xxxx (plan line items). In these table names, xxxx stands for the name of the operating concern. In other contexts, the profitability segments have more the character of master data.
Date: 30.01.2003 08:30:00 vorm.
Page 1 of 40
SAP AG
transaction data in summarized form. Summarize2 means to group the original profitability segments together into new segments that no longer contain some characteristics: profitability segments from the original dataset that have the same definition after the values of these characteristics are replaced by the INITIAL value are grouped together in the summarization level as one segment. The system adds up the values in the value fields of the involved segment level records. Example: Let us look at an operating concern E001, which contains the characteristics Customer and Product and the value field Revenue. The segment table CE4E001 contains the following profitability segments: (PS = profitability segment): PS 1 Customer 1 Product 1 PS 2 Customer 1 Product 2 PS 3 Customer 1 Product 3 PS 4 Customer 2 Product 4 The segment level CE3E001 contains the following period values:3 PS 1 Period 001/1997 Revenue USD 100.00 PS 1 Period 002/1997 Revenue USD 90.00 PS 2 Period 002/1997 Revenue USD 80.00 PS 3 Period 002/1997 Revenue USD 70.00 PS 4 Period 002/1997 Revenue USD 110.00 If this dataset is summarized across the characteristic Product (i.e. if the product is ignored), we obtain the following summarized segments:4 PS 5 Customer 1 Product INITIAL PS 6 Customer 2 Product INITIAL and the periods PS 5 Period 001/1997 Revenue USD 100.00 PS 5 Period 002/1997 Revenue USD 240.00 PS 6 Period 002/1997 Revenue USD 110.00
Summarization Levels and Summarization Data

Since Release 3.0C, you can use summarization levels to store presummarized datasets in costing-based Profitability Analysis for use in different areas of CO-PA.5 Summarization levels that are active and contain data are automatically used for the functions: online planning complete planning transfer to SOP
2 3
The terms aggregate and aggregation also appear frequently in the literature. The characteristics Plan/actual indicator, Record type and Plan version are also included in the segment level. However, this information is irrelevant to helping you understand the subject matter and was therefore excluded. These could also be the profitability segments in operating concern E001 if Product had not been included as a segment-level characteristic. See the chapter under Tools Summarization levels in the online documentation and in Customizing. The terms that are explained there will be used in this document without further explanation.
Date: 30.01.2003 08:30:00 vorm.
Page 2 of 40
SAP AG
assessment of cost center costs to CO-PA (for the purpose of determining the tracing factor based on variable shares) You could also use summarization levels in drill-down reporting by activating the Information system button in Customizing6 when defining the summarization levels. If this flag is active (Use summarization levels in reports), the system reads summarization levels when you execute reports. If the flag is not active (Use summarization data (as in Release 2.2)), the summarization levels are not used for reports. Instead, the system reads the summarization stored separately for each report, a technique that was already available in Release 2.2 and is explained in detail in OSS note 21773. Note that the decision to use summarization levels in reports only can be made once for each operating concern, whereas you can decide separately for each report whether or not you want to use summarization data (provided that the flag Information system is set to Use summarization data (as in Release 2.2)). This means that you cannot store summarization data for any individual reports once you have set the flag to Use summarization levels in reports.7 This does not affect the option to freeze report data.8 Note: For operating concerns created in Release 3.0C or higher, the Information system flag is set to Use summarization levels in reports by default. For operating concerns from Release 3.0B or earlier, the default setting is Use summarization data (as in Release 2.2) even after an upgrade to Release 3.0C or higher. In many of these operating concerns, the customers have optimized their reports for the use of summarization data. This presetting was chosen so that the customer can easily continue using the system as before after the upgrade. You can switch to Use summarization levels at any point in time. It is also possible to switch back to using summarization data at any time. If you want to do this, see OSS note 70339.
Data Structure
Every summarization level consists of two tables (similar to the data basis itself9): the key table corresponds to the segment table and contains those market-oriented characteristics10
6 7
8 9 10
Transaction KEDV In some customer projects both summarization levels and summarization data are being used simultaneously with the support of the SAP development team. For more information, see note 82468 (not released for customers). See the online documentation or note 21773. See note 21773 in OSS, section 3. Market-oriented characteristics in this documentation are those characteristics that are stored in the segment table CE4xxxx. This includes the characteristics to which values can be assigned. In addition to
Date: 30.01.2003 08:30:00 vorm.
Page 3 of 40
SAP AG
that were selected for the summarization level, plus the plan/actual indicator and plan version. The summary table contains the transaction-specific characteristics Period, Fiscal year and Record type, plus the value fields and quantity unit fields.11 Example: Let us look at operating concern E001 again. If we define a summarization level 0001 that contains the characteristic Customer, but not Product, the key table will look like this: Key no. 1 Customer 1 Product INITIAL Key no. 2 Customer 2 Product INITIAL and the summary table will look like this: Key no. 1 Period 001/1997 Revenue USD 100.00 Key no. 1 Period 002/1997 Revenue USD 240.00 Key no. 2 Period 002/1997 Revenue USD 110.00
Read Access
A Formula for Measuring Reading Speed
The system reads the summarization levels the same way it reads the data basis (see section ). Take R to be the reading performance in records per second. This value is a constant which also depends on the hardware one is using. This value needs to be redetermined for each installation.12 The following formula yields the time needed to read a report from a summarization level: Tread [sec] = N Pv ( 1 + Pp ) / R The letters in this formula mean the following: N is the number of combinations of values of the required market-oriented characteristics in the key table. Pv is the number of plan versions being read (actual data counts as one version in this context). Pp is the number of combinations of periods and record types (including the full number of periods for each fiscal year in the report). The appendix (section ) contains a detailed description of how the system accesses the data,
the market-oriented characteristics, there are also transaction-specific ones -- Record type, Plan/actual indicator, Plan version and Period that are stored in the segment level CE3xxxx. Furthermore, there are technical characteristics that are only updated in the CO-PA line item (Cost object, WBS element, and so on) but are not included in the segment table or the segment level. Using the settings in Customizing (transaction KEDV), you can only influence the structure of the key table. As an initial estimate for reading performance, you can expect approx. 500.000 records per hour (approx. R=140 records per second). In contrast to the practice recommended in note 21773, it makes sense to calculate the read time in seconds, because we are interested in how long it takes to read online. Reading from summarization levels yields better performance than reading from the segment level because the data structures contain fewer fields and are designed more for the purpose of allowing efficient access than for business functionality.
Date: 30.01.2003 08:30:00 vorm.
11
12
Page 4 of 40
SAP AG
how the above formula was deduced, and briefly how to find the reading performance that applies for your system. The formula was referred to here only to show which parameters you can influence if the read times are too long.
Example (Runtime for Reading and Displaying a Report)

The Data Operating concern X001 contains the characteristics Customer (1000 different characteristic values), Customer group (10 values), Product (1000 values) and Product group (100 values). Summarization level 000001 for this operating concern contains the characteristics Customer group, Product group, Fiscal year, Period, Plan/actual indicator, and Record type. Each combination of customer group and product group has received both actual and plan data in all periods. Costing-based Profitability Analysis is using a fiscal year variant with 12 periods (no weeks). The Report You want to define a simple sales statistic that compares billing data to date for the fiscal years 1996 (previous year) and 1997 (current fiscal year) with a plan version. You do not want to specify individual characteristics. Report SALES1 is based on a form with one axis and key figure, and should contain the characteristics Customer group and Product group as drill-down characteristics. The drill-down list when you call up the report might look like this:
Customer grp CG01 CG02 CG03 CG04 CG05 CG06 CG07 CG08 CG09 EX10 Result Actual sales Planned sales Var. Act.sales PY Var. 001-005/1997 001-005/1997 001-005/1996 354,321 370,000 0.96 346,236 1.02 34,534 60,000 0.58 63,576 0.54 536,231 600,000 0.89 598,546 0.90 265,625 270,000 0.98 267,007 0.99 721,366 710,000 1.02 714,724 1.01 365,747 370,000 0.99 364,795 1.00 362,563 370,000 0.98 368,054 0.99 45,767 100,000 0.46 98,678 0.46 457,342 500,000 0.91 486,543 0.94 67,620 70,000 0.97 69,889 0.97 3,211,116 3,420,000 0.94 3,378,048 0.95
Calculating the Runtime As described in section , summarization level 000001 can be used to select this report. Let us now apply the formula from section : As we have said earlier, all the combinations of customer group and product group have received postings in all periods. Thus N = number of customer groups number of product groups = 1000. Furthermore, it is clear that Pv = 2 (one for the actual data plus the plan version) and Pp = 24 (2 years 12 periods and only one record type). The read time required for this report is: Tread [sec] = 1.000 2 ( 1 + 25 ) / R Page 5 of 40 SAP AG
Date: 30.01.2003 08:30:00 vorm.
If we assume that R = 140/s (our first estimate above), we obtain a read time of 371 seconds, or about 6:11 minutes. This amount of time is surely not acceptable in most cases. Potential for Optimization Assume we have a second summarization level 000002 which contains the characteristics Customer group, Fiscal year, period, Plan/actual indicator, and Record type. If we reduce our requirements so that it is no longer possible to drill down to the product group level in the same report, we can read the report data from summarization level 000002, and the number of combinations of characteristics is reduced to 10. The time needed to read a report defined in this way (SALES2) would be less than four seconds. As you will see in section , you can then jump to report SALES1 for a single customer group. In this case, however, the customer group serves as a selection criterion. This reduces the number of combinations of characteristic values that the system has to read to 100 (every possible product group for that customer group). The time the system needs to read this data for SALES1 is thus reduced to about 37 seconds. Read times of this length are usually acceptable. From the users point of view, the system displays the first list (customer groups) on the screen almost immediately. When the user double-clicks on a customer group to see the product group level, he or she has to wait 37 seconds.
What Summarization Levels Are Suitable?

In addition to the characteristics you select in Customizing, each summarization level always contains all the quantity unit fields and all value fields (in the summary table). Please read the section Controlling Profitability Analysis Tools Summarization levels in Customizing, and go to the topic Examples. In order for the system to be able to read from a summarization level, the level needs to contain all the characteristics that are required to fulfill the selection criteria. For reports, these are the characteristics from the general data selection the characteristics from the rows and columns of the form the characteristics defined as drill-down characteristics in the report For cost center cost assessment, these are the characteristics specified in the selection criteria for the cycle the characteristics specified in the selection criteria for the tracing factor of a segment the characteristics to which the data should be assessed for a segment the controlling area (which is implicitly defined in the cycle) For planning layouts, these are Page 6 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
the characteristics in the general data selection (header) the characteristics specified in the lead columns (or rows and lead columns) the characteristics that occur in the value columns13 For the complete planning functions (such as Copy complete plan), these are the characteristics Period (or Week), Plan version, Record type and Plan/actual indicator, which appear on the initial screen of the functions the characteristics specified in the selection criteria with either an asterisk (*) or a fixed value (on the Characteristics screen). (For top-down distribution, this also includes the characteristics in the distribution level!) If you enter a fixed value for a characteristic in the definition of the summarization level14 (instead of an asterisk (*)), exactly this value of the characteristic must be selected by the selection criteria. For example, if you have defined a summarization level for controlling area 0001, this controlling area must appear explicitly in the report, planning layout, etc. (for example, in the general data selection), even if the database contains no other data. If this selection criterion is not specified in the report, etc., the system cannot use the summarization level. Furthermore: 1. If a characteristic is a constant, i.e. if it only has one possible value in the entire operating concern, you should either exclude this characteristic entirely from your summarization levels or include it with an asterisk (*). 2. It normally does not make sense to enter fixed values for characteristics in summarization levels. This is designed solely for when you want to access separate datasets of very different size. Example: There is no advantage in defining four separate summarization levels for four separate company codes 0001, 0002, 0003 and 0004 of similar size if the summarization levels differ only in the fixed value for the company code. Example: However, if one of the company codes (0001) is very large in comparison to the others, and if you do not need a summarization level to analyze this company code, it may make sense to create one summarization level each for company codes 0002, 0003 and 0004.
Example (Creating a Suitable Summarization Level)

A form with two axes has the following general data selection: Periods 001/1997 through
13
14
If you display characteristics as attributes in the value columns, the system determines these via characteristic derivation instead of reading them from the summarization level. However, these characteristics should still occur in the summarization level, as you will see in section . See also the section Defining Summarization Levels in the Extended Help for the maintenance transaction (transaction KEDV).
Date: 30.01.2003 08:30:00 vorm.
Page 7 of 40
SAP AG
012/1997, Record type F. The form has two columns: Actual data is to be compared with plan version 001. It also contains several rows displaying individual products. The detail screen looks something like this:
Actual revenues Dr. Miller's Spot-Be-Gone 0.2L Wishy Washy Sponge small Hair-o-fix Hair Restoring Powder 200g Fixolan Fast-Drying Glue 5g 9,968,745.00 6,622,343.00 2,097,509.00 2,588,045.00 Plan revenues (version 001) 10,000,000.00 7,000,000.00 2,000,000.00 2,500,000.00
We now want to create a report based on this form. We want to make the following settings: Characteristics screen: Customer district, Customer group Characteristic Values screen: local variable ($1) for the customer group, nothing for the customer district Variables screen: fixed value 01 for the customer group A summarization level can only be used for this report if it contains the characteristics Period Record type Plan/actual indicator Plan version Product Customer group Customer district (from the general data selection in the form) (from the general data selection in the form) (from the definition of the columns in the form) (from the definition of the second column in the form) (from the definition of the rows in the form) (from the selection criteria for the report) (as a drill-down characteristic in the report)
The characteristics Record type and Customer group can be specified with either an asterisk (*) or the fixed values F and 01.15
Choosing the Summarization Level

Based on the characteristics required, the system uses the following strategy for determining which summarization level to read:16 First, the system finds all the summarization levels that contain the necessary data (see ). If none are found, it reads the data from the segment level. Of these summarization levels, the system then finds the one that contains the fewest superfluous characteristics (characteristics that are not needed for the report, etc.). If this does not reduce the choice to one summarization level, the system then chooses the remaining summarization level that contains the fewest records in its summary table. If there are still more than one level, the system takes the most recent one. If there are still more than one, the system chooses one of them at random.
15 16
As stated earlier, this is not generally recommended. This strategy for choosing the summarization level is not a released R/3 interface. It can be changed in a later R/3 release without further notice.
Date: 30.01.2003 08:30:00 vorm.
Page 8 of 40
SAP AG
This strategy was defined in accordance with the basic rule for customizing summarization levels that When you include a characteristic in a summarization level, you should also include all the characteristics that can be derived by this one!17 This will not increase the size of the level. Example: If a summarization level contains the characteristic Customer, it should also contain all the characteristics that were taken from the customer master records for your operating concern.18
Example (The Wrong Summarization Level)

You have a summarization level 000001 that contains the characteristics Customer and Product (without the characteristics that are derived from them). You also have a second summarization level , 000002, which contains Product and several other characteristics that are derived from it. Summarization level 000001 contains almost a complete copy of the operating concern with several hundred thousand entries in the key table. In contrast, the key table for summarization level 000002 contains the number of sellable materials (normally only a few thousand records). If you now execute a report by specifying a single customer number with no further drill-down requirements, the system will choose summarization level 000001 according to the above strategy, and the system will read too many records. Note: A summarization level like 0001 above does not make much sense anyway, since it goes against the rule stated above.
Building Summarization Levels

Once you have defined the summarization levels19 and after executing realignments, you need
17
18
19
There are other dependencies between characteristics apart from derivation, such as the relationship between levels of the product hierarchy MARA-PRDAH in Profitability Analysis in Release R/3 3.0/3.1. Here the characteristics (WWPH1, WWPH2, WWPH3) are read from the field MARA-PRDHA using the derivation table technique: WWPH1 = MARA-PRDHA+0(5) WWPH2 = MARA-PRDHA+0(10) WWPH3 = MARA-PRDHA+0(18). In such an instance, if a summarization level contains the characteristic WWPH2, it should also contain WWPH1, even if the later is not technically derived from WWPH2. If the summarization level contains characteristics from the SD table KNVV of the customer master, the level should also contain the fields that make up the sales area (fields VKORG, VTWEG and SPART) in all practical instances. Once defined, each summarization level has the status Active, without data. The next thing you have to do is fill this summarization level with data, or build the summarization level! Only then can this level be updated. This also is true if you defined the summarization level before going live with your system and want to clear the data in Profitability Analysis when you go live (delete the contents of the segment
Date: 30.01.2003 08:30:00 vorm.
Page 9 of 40
SAP AG
to build the summarization levels. The system builds summarization levels the same way it selects data from the data basis (CE3xxxx, CE4xxxx) for reports, namely using a nested select (see section ) and then summarizing the selected data according to the definition of the summarization level. The time required for reading the data can be estimated using the formula in section . Unlike with reports, however, for summarization levels the system also has to insert the data read in the tables for the summarization level. The additional time required to insert and update the data in the database thus also needs to be included in the total time required.
Building a Summarization Level

First let us look at how a single summarization level is built. From Release 3.0D20 onward, the system uses a outgoing buffer to build or update summarization level. The data read is summarized in main memory as much as possible. When the main memory available for buffering data is full,21 the buffer contents are written to the database. The buffer is then cleared and the system continues reading and summarizing data. This process is repeated until all the read data has been summarized. If the summarization level is smaller22 than the available buffer (which we will refer to as a small level), the system only needs to perform one insert operation in the database for each record in the summarization level, since the complete data volume can be summarized in the buffer (green part of the curve, bottom left). If, on the other hand, the summarization level is much larger than the buffer (large), no summarization or very little summarization can take place each time the buffer is filled. You therefore can expect the system to perform one insert or update for every record read (red part of the curve, top right). The area between these two extremes (black part of the curve) is continuous. The following graphic compares the number of database operations needed to build a summarization level (# of updates) with the size of the summarization level (size of SL):
20
21
22
table, segment level and line item tables). In Release 3.0C an incoming buffer is used, which imports a few thousand data records, summarizes them for all summarization levels and then writes them to the database. The default setting allows 20 MB of space for the outgoing buffer. If you use the expert mode (program RKETRERV, also accessible from transaction KEDW from R/3 Release 4.0 onward), you can also specify a different size. in the structure of the key and summary tables.
Date: 30.01.2003 08:30:00 vorm.
Page 10 of 40
SAP AG
# of Updates
size of CE3xxxx
size of buffer
size of SL
These results for summarization levels that are larger than the available buffer yield the following rule: Create as few summarization levels as possible. A summarization level should be regarded as large if the size of the key and summary tables together exceeds 20 MB.23
Building Several Summarization Levels

When you build more than one summarization level at the same time, the system divides the available buffer space dynamically among the levels. When the buffer is full, the data for those levels that take up the most space in the buffer is written to the database and deleted. The following strategy has proven useful for building summarization levels:
23
Calculate the number of records in the key table record length in key table + number of records in summary table record length in summary table. If you use the expert mode RKETRERV, this limit can be raised considerably. Please keep in mind the total amount of memory in your application server, especially if you want to run multiple instances the program in parallel.
Date: 30.01.2003 08:30:00 vorm.
Page 11 of 40
SAP AG
1. Build all the small summarization levels together in the first run. 2. Then build the large summarization levels individually, one after the other (or simultaneously on different application servers). 3. Once all the summarization levels have been built, update them again in one final run. This procedure has the following advantages: Small summarization levels that are summarized to a high degree are immediately available for online use. If the long jobs for large summarization level abend due to database problems (database is full, snapshot too old in ORACLE 7.2, etc.), you can still run reports that display summarized data. The detail reports can be run later. If the data is distributed favorably across the available hard drives24, you can run the jobs for large summarization levels simultaneously. When you update all the levels together at the end, you achieve the same currentness in all levels, so that any two reports always have consistent data even when they read it from different levels.
Update Times
Since summarization levels are updated in a similar fashion to the way they are initially build, the time required for performing inserts is also similar. In the graphic above (), the text for the horizontal asymptote should simply be replaced with number of line items to be processed (new line items not already contained in the level). The update is similar to the update of summarization data in the so-called delta read method available in R/3 Release 2.2.25 Thus the same restriction applies: When building and updating summarization levels, you should always allow a safety period of 30 minutes between the build or updated and any jobs that post mass data to Profitability Analysis.26 Otherwise some of the new line items may not make it into the summarization level, meaning that the level does not have the state that should be expected after the update. In most practical situations, it makes sense to update the summarization levels on a daily basis.
24 25 26
For example, using striping techniques. For more information, see OSS note 35288. See also section 4.3 and chapter 9 in note 21773 in OSS. Especially monthly billing runs, external data transfers, mass postings in FI, and order settlement. Problems may also occur with long-running updates if manual postings are also constantly being made (such as when orders are posted).
Date: 30.01.2003 08:30:00 vorm.
Page 12 of 40
SAP AG
Interaction of Several Summarization Levels (I)

In chapter we dealt with a single summarization level and its structure and uses, and calculated how efficient one could expect it to be. In most cases, however, there will be more than one summarization level. The methods described in chapter 4 tell you how a number of summarization levels can be generated systematically. A few visible examples can best explain how different summarization levels interact with one another: A summarization level 000001 is contained in another summarization level 000002 when level 000002 contains (at least) all the characteristics in level 000001. (If level 000002 contains a fixed value for a characteristic, level 000001 must also contain the same fixed value.) Example: Summarization level 000001 contains the characteristics Customer group and Product group (in addition to the ones that are contain in all levels: fiscal year, period, plan/actual indicator, version, and record type). Summarization level 000002 contains in addition the characteristic Customer. In this case, level 000001 is contained in 000002. When level 000001 is contained in level 000002, the key table and summary table of level 000002 must be at least as large as those tables of level 000001. From this we can conclude that nested summarization levels line up according to the size of their key table. In such a case, we will say that a smaller summarization level is contained in a larger one. A series of summarization levels 000001, 000002, 000003... form a stack when for two of these levels X and Y the following holds true: X is contained in Y or Y is contained in X. These summarization levels can then be sorted according to their size. In such a case, we will say that the smaller summarization levels are higher up in the stack and that the larger ones are lower in the stack. Example: Let us look at an operating concern C001 that contains three user-defined characteristics (Assortment, Brand and Product group) to represent the three levels of the product hierarchy. We will now create a series of summarization levels for this operating concern: Summarization level 000001 contains only the fixed characteristics (fiscal year, period plan/actual indicator, version, record type). Summarization level 000002 also contains the characteristic Assortment. Summarization level 000003 contains all these plus the characteristic Brand. Summarization level 000004 contains all these plus the characteristic Product group.
Levels 000001 through 000004 form a stack, with 000001 being at the top and 000004 at the bottom. We can represent this stack in a graphic as follows:
Page 13 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
Summarization level 000001: Plan/Actual Indicator, Fiscal Year, Period, Version, Record type Summarization level 000002: Plan/Actual Indicator, Fiscal Year, Period, Version, Record Type Assortment Summarization level 000003: Plan/Actual Indicator, Fiscal Year, Period, Version, Record Type Assortment, Brand Summarization level 000004: Plan/Actual Indicator, Fiscal Year, Period, Version, Record Type Assortment, Brand, Product Group
Summarization Levels and Reports

The system can only read one summarization level for each transaction. For planning layouts, cost center cost assessment, and so on, you have no tuning options except of creating an optimal summarization level. For reports, on the other hand, you can influence runtimes by changing your information requirements. By removing some more detailed characteristics, you may be able to read from smaller summarization levels.
The Report Triangle

The following pyramid (black) represents a report on all profitability segments27 in an operating concern, with a fixed, predefined drill-down sequence. Any report corresponds to some small, green triangle in this picture, which we will refer to as a report triangle. The top of this triangle is determined through the selection criteria (characteristics specified, general data selection, and so on). In all, the characteristics can be divided into three groups: the characteristics for which values have been specified (Selection) the characteristics that have been selected as drill-down characteristics (Drill-Down) the characteristics that do not occur in the report (i.e. the characteristics across which the system will summarize) (Summarization)
27
First we will only look at the profitability segments, i.e. table CE4xxxx. Later we will also consider the duplication caused by the segment level CE3xxxx (new key fields for period, record type, plan/actual indicator, version, or period values). The effects of occasionally adding new line items will also not be considered here.
Date: 30.01.2003 08:30:00 vorm.
Page 14 of 40
SAP AG
The report contains those records from the segment table that for the base of the triangle extended downward (light green). Internally, the report only stores the data in summarized for, without the characteristics not used in the report. This level corresponds to the base of the report triangle.
Selection report data
Selection
Drill down
Summarization
CE4 to be read
Typical Drill-Down Reports

First let us look at reports in which the market-oriented characteristics from the segment table are selected for drilled down.28 This category includes the classic contribution margin reports (forms with two axes) and sales controlling reports (forms with one axis). The following examples show the detail screen of a contribution margin report and the drill-down list of a sales statistic (exceptions shown on a gray background.
28
We also assume that characteristics included in the selection criteria (general data selection, initial screen, variables, etc.) are not selected for drilling down. Later, it will become clear why this limitation also need not play a role.
Date: 30.01.2003 08:30:00 vorm.
Page 15 of 40
SAP AG
Actual 1-3/1997 Sales quantity Revenues Discounts Cash discounts Net revenues Sales commission Goods usage Var. production costs Contribution margin I Fixed production costs Fixed material costs Contribution margin II Administrative costs Gen. marketing costs Sales costs Research & development Profit Profit / Unit sold 345,253 2,002,467.40 68,083.89 36,044.41 1,898,339.10 160,197.39 552,404.80 40,049.35 1,145,687.56 56,800.00 21,565.00 1,067,322.56 79,788.00 110,345.00 324,445.00 55,677.00 497,067.56 1.44
Plan 1-3/1997 300,000 1,740,000.00 60,900.00 34,800.00 1,644,300.00 174,000.00 450,000.00 31,320.00 988,980.00 60,000.00 20,000.00 908,980.00 80,000.00 120,000.00 300,000.00 60,000.00 348,980.00 1.16
Var. % 15.1% 15.1% 11.8% 3.6% 15.4% -7.9% 22.8% 27.9% 15.8% -5.3% 7.8% 17.4% -0.3% -8.0% 8.1% -7.2% 42.4%
Charact. RVL1 RVL2 RVL3 RVL4 RVL5
Previous periods Current period Sales Plan Met Prev.yr Sales Plan Met Prev.yr 1000 l 1000 l % % 1000 l 1000 l % % 10,034 10,000 100.4 105.7 5,340 5,000 106.8 111.3 15,134 15,000 100.9 110.5 4,356 7,500 58.1 65.4 12,024 13,000 92.5 100.3 5,003 6,500 77.0 93.5 12,890 13,000 99.2 92.5 6,934 6,500 106.7 101.0 17,375 14,000 124.1 130.7 6,083 7,000 86.9 91.4
Exercise
Create a number of summarization levels for any report (green in the graphic in section ) a series of summarization levels for the structure shown in . It should be acceptable for a user to run this report online. Hint: Split the report into two or more stages (yellow) that are linked using the report/report interface (red). Create suitable summarization levels (blue) for each of the stages.
Page 16 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
Stack
S1
Stages Summarization Levels
R1=S2
R2
Note: Every report created is based on the same form. The function Split report splits a report into two new reports: a sender report and a receiver report. If you want to create a stack with several stages, you should proceed from top to bottom. Your flexibility in drilling down through the report is somewhat reduced when you split the report. Consequently, performance optimization often conflicts to a degree with the users requirements. In many cases, however, tenable compromises can be achieved. A summarization level can be considered optimal for a report if it contains exactly those characteristics that the report needs as selection criteria or drill-down characteristics (and, of course, those characteristics that are derived from those). Compare this approach with the representation in section !
Sorting the Characteristics

You first need to sort the characteristics of the report in a fixed order. The order of the drill-down characteristics is of primary importance here. Proceed according to the following: First specify values for those characteristics that are not used in the report, i.e. that are summarized in the entire report stack. We will call the sum of these characteristics AGG Page 17 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
(because all the values of these characteristics are aggregated). Then specify those characteristics that are used as selection criteria for the first sender report (the initial report). We will refer to these characteristics as SEL. The other characteristics are drill-down characteristics and are referred to as DRI. Now sort the characteristics DRI into the desired order. We will number these characteristics according to the sort order: M1, M2, M3, M4, ...
Determining the Initial Report

We will now look at how many data records need to be read in order to obtain all the report data necessary for the first drill-down levels (see section ) if an optimal summarization level exists. We will begin with one characteristic. If the initial report only contains the characteristic M1, we will probably obtain one row in the report data for every one of the N1 possible values of M1. Each row represents one detail list. Thus an optimal summarization level for the initial report would contain exactly those characteristics from SEL -- Period, Record type, Plan/actual indicator and plan version, plus the characteristic M1. To determine what figures to display, the system needs to read the period values for each of the N1 values of M1. According to the formula in section , this requires N1 Pv ( 1 + Pp ) read operations, which would last about N1 Pv ( 1 + Pp ) / 140 seconds. Since N1, Pv and Pp are usually small, this results in a very short read time. Example: If N1 = 10, the example report from would yield the following: for the contribution margin report, the system has to read two versions (one plan version plus the actual data) and 3 periods. Therefore, Pv = 2 and Pp = 12. Thus the time required comes to 10 2 ( 1 + 12 ) / 140 = 1,9 seconds. For the sales statistics, Pp = 24 periods. This yields a required read time of 10 2 ( 1 + 24 ) / 140 = 3,6 seconds. Now let us look at additional characteristics. If the initial report contains the characteristics M1 and M2, this will lead to one report row for every possible combination of M1 and M2. However, the number of possible combinations cannot be determined simply from the numbers N1 and N2 for the possible values of M1 and M2. In the extreme case, M1 may be dependent on M2, meaning that M1 is determined by M2 and consequently there are only N2 possible combinations of values. In another case, M1 and M2 may be completely independent of one another, which means that there would be N1 N2 possible combinations. In most concrete cases, the number of combinations leads somewhere between these two extremes. You therefore need to look more closely at how the values of these characteristics can be combined. It may be helpful here to build a summarization level (perhaps specifying individual characteristic values, especially the period field) and take a look at the structure of the key table. Page 18 of 40 SAP AG
Date: 30.01.2003 08:30:00 vorm.
You can now start with M1 and add characteristics from DRI to the initial report in the order specified for the drill-down sequence in until the above formula yields a read time that you consider acceptable for an online report. In summary: Starting with any report, you have sorted the drill-down characteristics (= DRI) into the desired order and then successively added characteristics to the initial report in this order until you obtain the longest acceptable read time for an online report.
Defining Jumps
A good way to divide a whole report into a stack of sender and receiver report is to use the method described in section , repeating it as often as necessary. For the report that follows the initial report, the only things that change are the available drill-down characteristics and the fixed selection criteria: The characteristic chosen for the summarization level for the first report are taken out of DRI and included in SEL. Then you can use the same method again to choose characteristics for the receiver report in the second stage. Based on the graphics in sections and , this would yield the following graphic showing how each stage is constructed:
Top Stage 2nd Stage 3rd Stage
SEL
SEL
SEL
S1
DRI
R1=S2
DRI
R2
DRI AGG
AGG
AGG
For the stages lying further down, the quantity of DRI keeps becoming smaller, as characteristics are removed from DRI and included in SEL. You now have to create a summarization level for each report in the stack. In each case, the summarization level should contain the same characteristics as in SEL and DRI.
Page 19 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
Data Currentness
When you define reports, you can choose from the following options regarded how current the displayed data should be: current data (up to the second, i.e. realtime) or last update of the summarization level In the latter case, the system reads and displays the data for the report from the most suitable29 summarization level. If you choose to display the current data, the system also has to read those line items that have been entered since the last time the summarization level was updated (delta read method, as described in note 21773, section 4.3). The runtime required for this depends on how many new line items have been entered since the last time the summarization level was updated. You should define most reports so that they do not read any line items in addition to the summarization level. The delta read method should only be used if it is absolutely necessary that you have the most up-to-the-minute data. Normally you will use the report/report interface to jump back and forth between a number of different reports, each of which has read the data from a different summarization level. In order to receive consistent data in all of these reports, you need to make sure that all the reports in the stack contain the current data or all the summarization levels from which the data is read were updated at the same time. 1. In most cases, the only simple solution is to update all summarization levels at the same time. 2. It almost always makes sense to update the summarization levels on a daily basis.30
Reports with Characteristic Values on the Detail Screen

Apart from the reports described in section , which use the market-oriented characteristics as drill-down characteristics, there are also reports in which the columns and rows of the detail screen contain different values of the same characteristics. Such reports may be used, for example, if you want to analyze a few product groups or customer groups in greater detail than others. The following figure shows a detail screen. The cells shown in bold print were chosen for the drill-down list. The drill-down characteristics are ones that group the data geographically.
29 30
See section . See section

Date: 30.01.2003 08:30:00 vorm.
Page 20 of 40
SAP AG
Revenue Product groups Hair tonic Bubble bath Moth powder Toothpaste Soap Baby powder Total Strategic products Schwipps 3000 Airosan 2,0 l Dr. Miller's Anti-moth
Customer groups Wholesale 4,533,508.00 5,453,372.00 835,482.00 343,554.00 56,578.00 2,342.00 11,224,836.00 3,944,151.96 3,653,759.24 634,966.32
Retail 5,453,412.00 5,237,866.00 246,584.00 545,432.00 74,743.00 7,653.00 11,565,690.00 5,289,809.64 2,566,554.34 192,335.52
Customer Miller 3,334,587.00 4,956,798.00 67,364.00 456,875.00 61,070.00 4,008.00 8,880,702.00 3,001,128.30 2,478,399.00 40,418.40
Share of RE 61.1% 94.6% 27.3% 83.8% 81.7% 52.4% 76.8% 56.7% 96.6% 21.0%
To obtain the data contained in the lower right-hand corner (highlighted in red), the system needs to read the data at the customer/product level. Regardless of the other selection criteria in the report and the selected drill-down characteristics, the report has to read the data at the most detailed level. Using the report/report interface and summarization levels, you can hardly improve this. for this report it makes the most sense to run the report in the background and freeze the data. Detailed characteristics in rows or columns can dominate the system runtime. Where possible, define rows and columns using only key figures and transaction-oriented characteristics, such as Period, Record type, Plan/actual indicator and Plan version. Try to use multiple reports and the report/report interface to fulfill such requirements.
Interaction Between Summarization Levels (II)

Stacks of Summarization Levels
In , we posited the rule that you should include all characteristics in a summarization level that can be derived from a characteristic already contained there. If the summarization levels were conceived using the method in chapter , this is yet another reason why this rule makes sense: derived characteristics usually serve as selection criteria for reports that should be selected from the summarization level.31
Jumping Between Two Levels

Using the method explained in sections , and , you can obtain stacks of summarization levels
31
Chapter describes a system for supporting almost any report with an appropriate stack of summarization levels so that it can be executed online.
Date: 30.01.2003 08:30:00 vorm.
Page 21 of 40
SAP AG
that are designed in such a way that the characteristic combinations are nested within one another, i.e. one of the two summarization levels is always the larger one that contains all the characteristics of the smaller one. These summarization levels are then used by reports that require data at exactly the level of detail contained in the summarization levels. The user jumps from higher (i.e. less detailed) sender reports to the more detailed receiver reports: The sender report reads from the less detailed summarization level. The user navigates through the characteristics in that report until all have a specified value, and these values then serve as selection criteria for the receiver report, which reads the data from the more detailed summarization level.
For more on this method, see section as well as the method described in section . The yellow summarization level (small pyramid) in the above graphic corresponds to summarization level 000002 in section , which primarily contains the customer group. The red summarization level (large pyramid) corresponds to summarization level 000001 from section , which contains the customer group and product group. Appendix contains a description of how you can use the Split report function to create reports easily that are linked in this manner.
Jumping Through a Stack of Levels

The method described above can easily be generalized to work for stacks of more than two summarization levels. In the graphic below, the black dots represent characteristics, which are organized into a hierarchy by the black lines. The colored ovals represent different summarization levels that Page 22 of 40 SAP AG
Date: 30.01.2003 08:30:00 vorm.
contain some of the characteristics. The transaction-oriented characteristics32 are not shown. They are contained in all the summarization levels.
Category Product Class 000001 000002 Chain 000003 Account National Account
Zone
Supervisor Brand 000004 District
Product
Customer
If we sort the characteristics into a fixed sort order (see section ) and switch to a representation using pyramids, we get the following picture:
000001
000002 000003
000004
32
Record type, period, plan/actual indicator, plan version, fiscal year

Date: 30.01.2003 08:30:00 vorm.
Page 23 of 40
SAP AG
The summarization levels are stacked according to the characteristic hierarchy. If all the characteristics in one summarization level have a specific characteristic value, you can always use these characteristic values as selection criteria for reading the next summarization level. If, on the other hand, you create summarization levels that are not sorted according to the hierarchy of characteristics, it will not be possible to jump to the next summarization level, i.e. the receiver report will not be able to read the correct level because characteristic values needed for the data selection are missing.
000006
000005
000007
000008
WRONG!
Page 24 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
000005
000006
000007
000008
Example of an Incorrect Jump

Let us look at the summarization levels 000005 through 000008 from the previous section, which are not sorted according to the hierarchy of characteristics. Report SENDER1 reports on the characteristics Chain and Zone for a specific value of Category. This report can be read from summarization level 000006 (shown in green). Once you have drilled down to the lowest level of SENDER1 and select a characteristic value in the last list, you have specified values for the characteristics Category, Chain and Zone. From here you now want to call up the report RECEIV1 to display the next level, Product class. This report requires specific values of the characteristics Category, Chain and Zone as selection criteria and has Product class as the drill-down characteristic. Unfortunately, however, none of the summarization levels 000005 to 000008 contains all of these characteristics. Thus the system has to read the data from the segment level.
Example of a Correct Jump

If you create summarization levels 000001 to 000004 in hierarchical fashion, the system can select SENDER1 from summarization level 000002 (green). Since summarization level 000003 (yellow) contains all the characteristics in report RECEIV1, the jump works, i.e. the system reads the summarization level when selecting RECEIV1 and not the segment level.
Summarization Levels That Are Close to Each Other

The method described in sections , and gives you stacks of summarization levels that are constructed so that for any two hierarchically aligned summarization levels, the lower (larger) one is just large enough that the data contained there can still be read online when values are Page 25 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
defined for all the characteristics in the higher (smaller) one.33 This is to ensure that the summarization levels for a report are not too close to one another. When two summarization levels of similar size are arranged hierarchically, you should check whether or not the smaller one is absolutely necessary. The small performance gain when you execute the reports may not be worth the extra performance required to update the smaller summarization level. In many cases, you can use the following rule of thumb: The difference in the size of the summary tables of two hierarchically arranged summarization levels should be a factor of at least 5.
Indexes for Summarization Levels

You can use secondary indexes to improve performance when the system accesses the key tables of your summarization levels. No special secondary index is necessary to update the summarization level.34 The problems discussed in section make it clear that for the summarization levels within a stack, a multi-column index on the characteristics of the preceding level optimize the level for use with the report/report interface.
Unfortunately, there are disadvantages to creating secondary indexes for summarization levels after you have used the levels. When you make the change in Customizing, the level is given the status Active, without data and therefore needs to be built again from the segment level.35 One way around this would be to create the secondary indexes directly in the database, thereby avoiding the changes in Customizing and the ABAP/4 Dictionary. In this case, you should then create the index in Customizing immediately before the next time you rebuild the level.
33
34
35
This method was developed assuming that we were only dealing with one report. As a result, the number of periods was taken into account when we developed the stack, i.e. if you only need a few periods, the distance (difference in size) between two hierarchically arranged levels will be larger than when you need a large number of periods. For the segment table of your operating concern, a suitable index is needed for updating the segment level. For more information, see OSS note 35288 (Chapter 1) or the first topic in the chapter Technical Documentation in the online documentation CO-PA Profitability Analysis. Valid at least for R/3 Releases up to 3.1H and 4.0A.
Date: 30.01.2003 08:30:00 vorm.
Page 26 of 40
SAP AG
Special Problems
Record Not Found When Reading the Segment Level
It may occur that the segment table (CE4xxxx) contains profitability segments for which there are no records in the segment level. When this happens, the system can fail to find a record when it reads the segment level. In these cases the selection may take longer than when records are actually found. Example: The sales order number is updated in the segment table (occurs frequently in sales-order-related manufacturing). The average processing time of an order is six months. The data basis in CO-PA contains data for the last three years. As a result, for any specific period approx. 5/6 of the profitability segments do not have any postings. When you run a report that selects the data for a specific company code, the system also has to read the profitability segments for those orders that were not processed during the period you want to analyze. However, the system does not realize that no values exist for these segments in that period until it reads the segment table. Example: You store your CO-PA data at the customer/product/week level. But the customers do not buy the products very frequently -- say, once per quarter. when you execute a report for a specific weeks, the system finds no values in this week for most combinations of customer and product. Example: When you assign internal orders to CO-PA (by creating a settlement profile) without specifying a quantity unit for the sales quantity, you create a profitability segment for which the characteristic ABSMG_ME (Quantity unit for sales quantity) has no characteristic value. The postings you create when you settle the order usually have a quantity unit and are therefore posted to a different (new) profitability segment. The profitability segment created by the assignment of the order never receives any postings, and thus no corresponding records exist in the segment level.36 Consequently, a report would spend about half the time required to read the segment level looking for records that do not exist. In contrast to the segment table, the key tables for summarization levels do not contain records for combinations of characteristic values that do not receive any postings. For the situation described in Example 1 above, this means that the segments for which no values exist no longer exist when the system reads the key table. This yields the conclusion: If an operating concern contains many profitability segments for which no records exist in the segment level, you should create a summarization level that contains all the characteristics. There are also a number of situations, however, where this technique does not help:
36
Still, these profitability segments cannot be regarded as superfluous, because they contain the posting information of the order. You therefore cannot simply delete them, since this would negate the integration functions of the R/3 System.
Date: 30.01.2003 08:30:00 vorm.
Page 27 of 40
SAP AG
Example: If some profitability segments rarely receive postings (or perhaps only once),37 and you have a report that only analyzes a narrow time frame, the system will only find records in the segment level for a few of the profitability segments that meet the selection criteria. Such a report would likewise spend a lot of time looking for nonexistent records in the segment level.
ORA-1555 When Building Summarization Levels

If you use ORACLE, you may often encounter the error ORA-1555 (snapshot too old) when you try to build summarization levels or select from the segment level for long-running reports. This can have a number of causes: Documents were posted while you were building the summarization level. A single posting during that time can cause the error if other write operations are taking place somewhere else in the system. The consistent read that ORACLE tries to perform38 causes the error ORA-1555. You can avoid this behavior by ensuring that no postings are made to Profitability Analysis while you are building the summarization levels. The ORACLE attributes consistent read and delayed block clean out39 interact in such a way that programs that read one table (here the segment table CE4xxxx) while updating another table (the tables of the summarization levels) can lead to the error ORA-1555 if records are added to the table being read that were not read again since the INSERT. You can avoid this problem by forcing the system to read the segment table CE4xxxx before building the summarization levels. You can force a so-called table scan40 using the following short ABAP/4 program. You simply have to enter the name of your operating concern where the four dots occur. Usually you will set up a two step batch job for building summarization levels. The first step is the table scan program. On success you will execute a second step running the actual RKETRERU or RKETRERV program. REPORT ZSCANCE4. DATA: BEGIN OF X, D TYPE D, I TYPE I, END OF X. EXEC SQL PERFORMING F. SELECT BISDAT, COUNT(*) INTO :X FROM CE4 GROUP BY BISDAT ENDEXEC.
37
38
39
40
This typically occurs in the following situations: 1. The sales order number is not deactivated from the segment-level characteristics. 2. Records in the segment level for discontinued products are not archived and deleted from the database. 3. Business transactions (customer X buys product Y) rarely recur. 4. You post your CO-PA data in very detailed time frames. I.e. the attempt to return the hit list as it was at the beginning of the selection. If a search query (open cursor) runs a long time, the database will encounter changed records. In this case, the database tries to restore the state of the data at the beginning of the selection by reading rollback segments. If this is unsuccessful, the process is terminated by error ORA-1555 (snapshot too old). ORACLE does not write changed data blocks immediately to the hard drive. The physical write only takes place the next time the data block is read. This action is controlled by a flag for each data block that is not reset until the next read step. This attribute can be deactivated from Release 7.3 onward. A table scan reads the data blocks of the table sequentially from the hard drive. This is the fastest way to achieve the desired result using ORACLE.
Date: 30.01.2003 08:30:00 vorm.
Page 28 of 40
SAP AG
FORM F. ENDFORM. On the whole, error ORA-1555 is a database trait that you can only prevent by increasing the number or the size of the rollback segments. You cannot influence the error within R/3.
Appendix
Drill-Down Reports
Data Structure in Profitability Analysis
(see Chapter 3 in note 21773 and the example found there)
Reading Using a Nested Select

(see also section 4.1 in note 21773) Using the data basis (segment table CE4xxxx and segment level CE3xxxx) as an example: When reading the data for a report, the system first accesses the segment table CE4xxxx using the characteristic values specified in the report definition. Then it accesses the segment level CE3xxxx using the profitability segment numbers (PAOBJNR) of the records found (hits) and, if available, the characteristic values for the period.41 The value fields selected using these criteria are collected together with the characteristic values from the segment table CE4xxxx to answer the search query. These hits are then passed on to the report to be displayed.
41
...and a few additional technical fields: Record type, Plan/actual indicator and Plan version.
Date: 30.01.2003 08:30:00 vorm.
Page 29 of 40
SAP AG
Query
CE4
PAOBJNR Criteria
CE3
"Join" PAOBJNR Period... Value fields
Criteria
Value fields
Hit set
In standard installations, the read performance can yield a throughput of about 200,000 data records per hour. We will use this figure for all calculations in the following section. Actual performance can be improved considerably through fine-tuning. For your own calculations, you need to determine the read performance of your system. If no characteristic values (in particular, no time frame) are specified for a report, the system has to read all the records in the segment table CE4xxxx and all the records in the segment level CE3xxxx. Thus, if you know the size of your data basis, you can determine how long it will take to run a report that reads all the data using the following formula: T read [in hours] ( PS + SL ) / 200,000
where the read time is determined by the number of profitability segments (PS) and the number of records in the segment level (SL). Otherwise, you need to estimate how many records will be read from the segment table and the segment level based on the specific data content of your installation. You can then insert these Page 30 of 40 SAP AG
Date: 30.01.2003 08:30:00 vorm.
values in the above formula in place of PS and SL.
Size of Report Data and Frozen Data

(see also section 10.4 in note 21773) Internally, a report needs to hold all the data that you can access by displaying the report, including any data that you can drill down to. The system creates an internal table to store this report data in. All the characteristics chosen for the report serve as the key. The system summarizes the report data so that every row in the table has a different key. Combinations of characteristic values for which no values have been posted are not saved. (Since the drilldown reporting tool only works with the values read from the data basis, it does not even recognize these combinations.) The report data contains figures that are to be displayed for the characteristic values that serve as the key. These figures add 8 bytes each to the length of the row. For basic reports, these are the selected key figures (value fields or elements of the report line structure). For form reports, the system essentially stores the content of the cells to be displayed on the detail screens. The texts for the characteristics are not part of the report data, since these can always be read using the keys of the characteristics whenever they are needed for the displayed report. In addition, some management information of a constant size is stored for each row of the internal table. We will ignore this information here. Example: A report should display the revenues (value field VVREV). The characteristics chosen are Regional sales director (WWV03, 5 values) and Product range (WWP04, 3 values). No values are specified for these characteristics in the report definition. In this case, the report data will contain no more than 15 rows, because the key of the rows is made up of the combination of characteristics WWV03 and WWP04. The internal table for the report data will look like this:42
42
The combination WWV03=3000, WWP04=200 is missing in the report data because no data was posted for this combination in the example.
Date: 30.01.2003 08:30:00 vorm.
Page 31 of 40
SAP AG
WWV03 1000 1000 1000 2000 2000 2000 3000 3000 4000 4000 4000 5000 5000 5000
WWP04 100 200 300 100 200 300 100 300 100 200 300 100 200 300
VVREV 101,368 115,045 30,198 131,234 150,946 41,547 79,546 19,302 110,234 159,002 11,419 198,436 251,032 51,001
To display this data in summarized form, the system selects and aggregates the values from the internal table as needed. When you freeze the report data, the entire internal table is saved in table COIX_DATA in clustered form (in blocks).43 When you later display this frozen report data, the system exports this table again. Typical read times run about 200 kB of report data per second. Similar times can be observed for WRITE operations. From Release 3.0D on, R/3 compresses the data to be written to the database for SAP cluster tables. Consequently, the amount of main memory actually required may be reduced. Factors of around 2 have been observed. The storage form described above gives us a simple formula for estimating the amount of space needed for the report data. For each row of the internal table, space is required for all the characteristics in the report and for all the value fields (or cells) that are to be displayed. We must calculate the actual length of the characteristics (according to the ABAP/4 Dictionary) and 8 bytes for the value fields. Calculating the required number of table rows is usually more difficult. If the report selects all the data and does not summarize any, the number of rows must correspond to the number of profitability segments. However, if one of these criteria does not hold, we need to use more complex assumptions for our estimate, since this requires more detailed knowledge about the content of the data. If the data is summarized to a high degree, we can normally conclude that (almost) all the possible combinations of values of the selected characteristics actually exist, and estimate the number of rows in the internal table by multiplying the number of values of these characteristics. This gives us the following formula for calculating the size of the report data: Assume that N is the number of rows in the most detailed level of the drill-down list, B is the number of cells in the form (detail list), and S is the size of the report data. Then if we take the size of the space required for the characteristics and the technical information for each report line to be about 50, we obtain the following:
43
In Release 3.0 the table is named COIX_DATA. Up to and including Release 2.2, frozen report data was stored in table COIX, which now only contains the report definitions (since Release 3.0). With release 4.0 the table is named COIX_DATA40.
Date: 30.01.2003 08:30:00 vorm.
Page 32 of 40
SAP AG
S [in bytes]
N ( 8 B + 50 )
Reading from Summarization Levels

Performance When Reading from Summarization Levels
Let us look at an example of a read access that has to read the data for N combinations of values of market-oriented characteristics from a summarization level.44 Calculating the number of read accesses is more difficult than for reading the segment level as in section , because the characteristics Period, Record type, Plan/actual indicator, and Plan version are stored separately in the key table and the summary table. The picture from thus needs to be modified:
44
For our purposes, it is irrelevant whether the summarization level being used is optimized for the report or whether the data needs to be summarized further. All that matters is the number of combinations of characteristic values that have to be read from the segment table for the characteristics (which are always stored in the key table).
Date: 30.01.2003 08:30:00 vorm.
Page 33 of 40
SAP AG
Page 34 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
First, the required combinations of market-oriented characteristics (red), plan/actual indicator, and plan version (gray) need to be read from the key table -- let us say N Pv records. For each of these combinations, the system then needs to read the corresponding records with all the necessary periods45 and record types (olive green) from the summary table46 -- let us say Pp records per record of the key table. The subscript next to P indicates whether this refers to versions (actual data counts as one version) or periods ( x record types), which increase the number of records that need to be read. The total number of records is thus N Pv ( 1 + Pp ). Example: The two example reports from show actual data and one plan version (presumably for a large record type). For these reports, the system has to read N 24 and N 48 period values, respectively. These figures were found as follows: The contribution margin report shows two versions (one plan version and actual data) for three periods. The sales statistics show the same two versions for two years (or 24 periods).47 With the number of records to be read calculated, we can now use the formula from . It makes sense to measure the read time in seconds, since we are aiming at read operations that can be performed online. In the time is measured in hours because the focus there is on very large read operations for building reports in the background. Tread [sec] = N Pv ( 1 + Pp ) 3.600 / L where the letters mean: N is the number of combinations of values of the required market-oriented characteristics from the key table. Pv is the number of plan versions being read (actual data counts as a version here). Pp is the number of combinations of period and record type (counting the whole number of periods in each fiscal year that appears in the report). L is the installation-specific rate for reading summarization levels per hour. In section , an estimate of 500,000 was given for the read speed L. You need to experiment in your own installation to calculate the read time. Notes: If a large portion of a summarization level is read, and if this level is of moderate size
45
46
47
The number of periods that needs to be read cannot be evaluated precisely. However, the selection is made by fiscal year. The actul join field in the key- and summary table is TRKEYNR, not PAOBJNR. In the picture we left the old term to indicate the correspondece to the read access to the segment level. In Release 3.0, it (unfortunately) does not matter that the plan data from the previous year is not displayed. The system still reads all the combinations of values of period, record type, plan/actual indicator, and plan version.
Date: 30.01.2003 08:30:00 vorm.
Page 35 of 40
SAP AG
(compared to the size of the buffer area of the database), this improves the read performance, since the database's buffer mechanism replaces slow hard disk access operations with faster operations for reading the main memory. In this case, performance is largely dependent on processor capabilities.48
Determining Performance By Experiment

Select a rather large summarization level from which you read a large number of records, and reduce the buffer size of the database as much as possible. A good test would be to read an entire summarization level that contains 10,000 key records and 200,000 totals table records (about 50 MB of data). For this test, the data buffer should be less than 5 MB. You can expect a runtime of approximately half an hour ( 50%) for this test.
The Report/Report Interface

This part of the appendix is taken from another document that also deals with the creation and use of summarization data and frozen report data. It is necessary to use these methods if you are not using summarization levels for drill-down reporting. The term "report data" used here refers to the data for a report as it is stored internally at the point of execution. The report may be stored as so- called "frozen report data". To calculate the size of the report data, see section . The example refers to an operating concern that contains, among others, the characteristics WW001,...,WW008. Reports that contain a large number of characteristics and drill-down levels often result in report data of considerable size. In such cases it may take a long time for the system to display the data, and the memory required can affect the overall throughput of the application server adversely. We therefore need to develop a technique for reducing the size of the report data.
Looking for the Unexpected

The basis for the method described below is the observation that users are often not interested primarily in seeing the values displayed at the various levels. On the contrary, they are looking more for so-called exceptions in the report -- values that deviate considerably from what they would normally expect. They then follow these exceptions through the hierarchy of characteristics to drill down to more detailed information. Note: For details on exception reporting, see the online documentation Drill-Down Reporting in the section Special Report Settings. These exceptions generally only make up a small part of the report data. Consequently, we can try to select and display only this part of the report.
48
With Pentium Pro 200 CPUs under Windows NT, performance of about 1.2 million records per hour (about 330 records per second) were observed in customer systems when the aforementioned prerequisites were fulfilled.
Date: 30.01.2003 08:30:00 vorm.
Page 36 of 40
SAP AG
In this graphic, the two colored triangles represent two reports with the same layout. The dots represent exceptions to which the user drills down. The red dot at the intersection of the two reports has special significance. The "upper" report is already displayed at its lowest level of detail. Thus the user has to execute the "lower" report, the first level of which is this red dot broken down to the next level (the next characteristic). Example: This situation can occur in sales analysis when the upper report contains a sales hierarchy, while the lower report shows the individual customers by salesperson.
Stacking Reports
To create this type of situation, one could proceed as follows: Define a single report layout by creating a form FORM. For this type of report, it would make sense to use a form with one axis and key figure. Global selection criteria (such as the periods to be displayed) should be specified already in the form (general data selection. Using form FORM, define a report SENDER that contains the characteristics WW001, ...., WW004. Likewise, use form FORM to create another report, RECEIVER. This report should contain the characteristics WW001, ..., WW008. For the characteristics WW001, ..., WW004, define local variables. When you execute this report, the system then displays a dialog box in which you can enter values for these variables. Now you can execute report SENDER (also in the background, using program RKEBATCH, if desired). Let us assume that you drill down to the lowest level, where you have one exception remaining. Page 37 of 40 SAP AG
Date: 30.01.2003 08:30:00 vorm.
To analyze this exception in greater detail, execute report RECEIVER. In the dialog box "Enter Variables", enter those characteristic values for WW001, ..., WW004 that led to the exception displayed in report SENDER. You can now navigate in report RECEIVER through the characteristics WW005, ..., WW008. This procedure obviously involves some unnecessary actions on the part of the user. First, you need to make a note of the characteristic values at the last level of report SENDER. Then you need to enter these for report RECEIVER. These actions obviously could be performed automatically by the system. The function "Split report" in drill-down reporting makes it easy for you to define this.
The Function "Split report"

Instead of carrying out the complicated steps described above, it would be better to proceed as follows: Define the desired report (basic report or form report) and include all the characteristics you want to analyze (WW001, ..., WW008). Call the report SENDER. Now choose the function "Information system Define report Split" from the Profitability Analysis application menu. Enter the operating concern and report SENDER. In the dialog box that appears, enter the name RECEIVER for the new report, and select the characteristics WW005, ..., WW008 for this report. Now execute report SENDER (if desired, in the background using RKEBATCH). When you reach the lowest level of report SENDER, the system now displays an additional icon in the navigation block of the report. This icon lets you execute report RECEIVER as the predefined receiver report for report SENDER. When you choose this function, the system uses the characteristic values specified in report SENDER automatically as the selection criteria for report RECEIVER. Thus the system automatically displays the right level in the drill-down sequence. This simple method also gives you a suitable report pair that lets you analyze the desired exceptions. However, in this case the drill-down reporting tool automatically replaces the variables in the receiver report, so that the person executing the report almost doesn't even see that the report has been split. Note: For more details on splitting reports and using the report/report interface, see the sections Overview: Report/Report Interface and How to Use the Report/Report Interface in the online documentation. To read about how to use the hotspots that appear on the report screen, see Hotspots in the Report List. All these sections appear in the chapter Special Report Settings in the documentation Drill-Down Reporting.
Possible Variations
Remember that section was extracted from a document not dealing with summarization levels! All read accesses to CO-PA data are therefore considered to run against the segment level. We have applied the following solution: Page 38 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
A group of characteristics "A" is used for the drill-down characteristics in a sender report. For this report, frozen data is selected and saved in the background. The other characteristics "B" are defined as drill-down characteristics in a receiver report, which can be executed online if desired. If you use the report/report interface as in the example above, you will notice the following: Sender report The time required to select the data for the sender report does not depend on the characteristics chosen for this report (since all data has to be read from the segment level). The report therefore needs to be built in the background using program RKEBATCH. Therefore you will probably make the sender report as large as possible while still making it possible to display the frozen report data in an acceptable amount of time. Size limitation: If you want to be able to display the report in no more than one minute, the report data should not be larger than about 12 MB, according to the formula we postulated earlier. Receiver report Frozen report data can pose problems for the receiver report, since the system stores one set of frozen data for each combination of characteristic values in the sender report that could be necessary for the receiver report. The critical factor for the receiver report is thus the amount of data that has to be read. Size limitation: If you also want to be able to display this report in no more than one minute, the number of sets should be limited to about 3000, according to the formula postulated earlier. By shifting characteristics between groups A and B, you can vary the size of the sender and receiver reports. If the two size limitations cannot both be met, you need to modify this solution.
Page 39 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG
(a) A
(b) A B C C B
(c) A B CD C BD D BC
B C
(d) A B C(A,B) CD C(A,B,D) C C C(A,D) C D C(A)
For example, you can use the report/report interface more than once. You then have multiple groups of characteristics (A, B, and C in the graphic) and thus have a report stack similar to the one shown in graphic (a). For report B, you thus need to create one set of frozen report data for each combination of characteristic values in A. If your business requirements make it impossible to fix the order in which you can drill down through the characteristics, you need to create multiple stacks of reports (figures (b) and (c)). As indicated in (d), the reports used (given the same selection of drill-down characteristics) differ in which characteristic values are specified.
Potential for Optimization

The techniques described above (report/report interface and frozen report data) correspond to the stage of development in R/3 Release 2.1. The time required to create the frozen report data in the sender report and the size limitations for the receiver report only allow efficient and up-to-date reporting for small quantities of data. In larger installations, it only makes sense to use the report/report interface together with presummarized data. Release 2.2 used report-specific Summarization data. The method for using this technique is explained in detail in OSS note 21773. Summarization levels, which can be used for any report as well as other areas in Profitability Analysis, have been available since Release 3.0D.
Page 40 of 40
Date: 30.01.2003 08:30:00 vorm.
SAP AG

Copa Summarization Level

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Copa Summarization Level

Uploaded by

Copyright:

Available Formats

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Strategies for Using Summarization Levels

Content and Target Group

Basic Facts About Summarization Levels

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Summarization Levels and Summarization Data

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Example (Runtime for Reading and Displaying a Report)

Date: 30.01.2003 08:30:00 vorm.

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

What Summarization Levels Are Suitable?

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Example (Creating a Suitable Summarization Level)

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Choosing the Summarization Level

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Example (The Wrong Summarization Level)

Building Summarization Levels

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Building a Summarization Level

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Building Several Summarization Levels

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Interaction of Several Summarization Levels (I)

Date: 30.01.2003 08:30:00 vorm.

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Summarization Levels and Reports

The Report Triangle

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Selection report data

Typical Drill-Down Reports

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Charact. RVL1 RVL2 RVL3 RVL4 RVL5

Date: 30.01.2003 08:30:00 vorm.

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Sorting the Characteristics

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Determining the Initial Report

Date: 30.01.2003 08:30:00 vorm.

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Date: 30.01.2003 08:30:00 vorm.