COPA SUMMARIZATION LEVEL

Profitability Analysis CO-PA

Strategies for Using Summarization Summarization Levels

Strategies for Using Summarization Summarization Levels Content

Content and Target 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 information about drill-down reporting is repeated repeate d in the appendix (section) (section ). A second document do cument will be produced produ ced on “performance strategies”, i.e. which of the available available  performance-improving  performance-improving tools (summarization (summarization levels, levels, summarization 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 times be observed are written in bold type type and surrounded surr ounded by a red frame. You should not deviate from these rules unless the situation has been analyzed analyzed in detail (where necessary, with the help of SAP’s Second Level Support) Support).. In addition to reading this documentation, it is strong strongly ly recommended recommended that you work on a project that allows you to gain practical knowledge.

Basic Facts About Summarization Levels  Please read the online documentation 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 (th e period values for the profitabili ty 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.

Page 1 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Summarization Levels

transaction data da ta in summarized form. Summarize2 means to group gro up the th e original profitability profitability segments together into new “segments” that no longer contain some characteristics:  profitability  profitability segments segments from the original dataset that th at have the same definition 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” “Produc t” and the value field “Revenue”. “Revenue”. The segment table CE4E001 contains c ontains the following following profitability 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 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 following summarized 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 Summarization Levels and Summarization Data Since Release Release 3.0C, you can use summarization summarization levels levels to store presummarized 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

4

5

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.

Page 2 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Summarization Levels

•

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 drill-down reporting repor ting

 by activating activating the “Information system” system” button in Customizing6 when defining the summarization levels. If this flag is active (“Use summarization levels in reports”), the system reads summarization summarization levels when you execute reports. repo rts. If the flag is not active (“Use summarization summarization data (as in Release 2.2)”), the summarization summarization levels levels are not used for reports. rep orts. 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 2 1773..  Note that tha t the decision to use summa s ummarization rization levels levels in in reports only o nly can can be made once for each operating concern, whereas you can decide separately for each report whether or not you want to use summarization summarization data (provided (p rovided that the flag “Information “Information system” is set to “Use summarization summarization data (as in Release 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 opera ting concerns created in Release Release 3.0C or higher, the “Information system” system” Note: For operating flag is set to “Use summarization summarization levels levels in reports” by default. For operating opera ting concerns from Release 3.0B or earlier, ea rlier, the default setting is “Use summarization summarization data (as in Release Release 2.2)” even after an upgrade up grade to Release 3.0C or higher. In many of these operating ope rating 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 summarization levels” levels” at any point in time. It is also possible to “switch back” to t o using summarization summarization data at any time. If you want to do this, see OSS note 70339.

Data Structure 9 Every summarization summarization level consists of two tables (similar (similar to the data dat a basis itself  ): 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, 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

Page 3 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Summarization Levels

that were selected for the summarization summarization level, level, plus the plan/actual indicator indicator and plan version. version. The summary table contains the transaction-specific characteristics “Period”, “Fiscal “Fiscal year” 11 and “Record type”, plus the value fields and quantity unit fields fields. Example: Let us look at operating concern E001 again. If we define a summarization summarization level 0001 that contains the characteristic “Customer”, but not no t “Product”, “Product” , the key table will 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 summarization levels levels the same way it reads the data basis (see section) 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. installation.12 The following following formula yields yields the time needed needed to read a report from a summarization level: Tread [sec] = N × Pv × ( 1 + P p ) / R  The letters in this formula mean the following: •

combinations of values of the required market-oriented characteristics in N is the number of combinations the key table.

•

being read (actual data counts as one version in this Pv is the number of plan versions being context).

•

r ecord types (including (including the full number number of  Pp is the number of combinations of periods and record  periods for each fiscal year in the report). report ).

The appendix (section ) contains a detailed description of how the system accesses the data,

11

12

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.

Page 4 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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:  Actual sales Planned sales Var. Act.s ales PY Var. Customer grp 001-005/1997 001-005/1997 001-005/1996 CG01 354,321 370,000 0.96 346,236 1.02 CG02 34,534 60,000 0.58 63,576 0.54 CG03 536,231 600,000 0.89 598,546 0.90 CG04 265,625 270,000 0.98 267,007 0.99 CG05 721,366 710,000 1.02 714,724 1.01 CG06 365,747 370,000 0.99 364,795 1.00 CG07 362,563 370,000 0.98 368,054 0.99 CG08 45,767 100,000 0.46 98,678 0.46 CG09 457,342 500,000 0.91 486,543 0.94 EX10 67,620 70,000 0.97 69,889 0.97 Result 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

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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 user’s 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

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

−

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 o ther 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).

Page 7 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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 deter mining 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

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.

16

Page 8 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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

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.

18

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.

19

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

Page 9 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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 smaller 22 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”):

table, segment level and line item tables). 20

21

22

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.

Page 10 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

# 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.

Page 11 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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).

Page 12 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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 “Pro duct 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

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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.

Page 14 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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 Selection report data 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.

Page 15 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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

Charact. RVL1 RVL2 RVL3 RVL4 RVL5

Previous Sales 1000 l 10,034 15,134 12,024 12,890 17,375

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

Var. %

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

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%

periods Current period Plan Met Prev.yr Sales Plan Met Prev.yr   1000 l % % 1000 l 1000 l % % 10,000 100.4 105.7 5,340 5,000 106.8 111.3 15,000 100.9 110.5 4,356 7,500 58.1 65.4 13,000 92.5 100.3 5,003 6,500 77.0 93.5 13,000 99.2 92.5 6,934 6,500 106.7 101.0 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

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Stack

S1

Stages R1=S2

Summarization Levels

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 user’s 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 characteristicsAGG

Page 17 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

(because all the values of these characteristics are aggregat ed). •

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 + P p ) read operations, which would last about  N1 × Pv × ( 1 + P p ) / 140 seconds. Since N1, P v and P p 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 P p = 12. Thus the time required comes to 10 × 2 × ( 1 + 12 ) / 140 = 1,9 seconds. For the sales statistics, P p = 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

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

You can now start with M 1 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

SEL

SEL

3rd Stage

SEL

S1

DRI R1=S2

DRI DRI

R2

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

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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

See section .

30

See section

Page 20 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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

Retail

Customer Miller

Share of RE

4,533,508.00 5,453,372.00 835,482.00 343,554.00 56,578.00 2,342.00 11,224,836.00

5,453,412.00 5,237,866.00 246,584.00 545,432.00 74,743.00 7,653.00 11,565,690.00

3,334,587.00 4,956,798.00 67,364.00 456,875.00 61,070.00 4,008.00 8,880,702.00

61.1% 94.6% 27.3% 83.8% 81.7% 52.4% 76.8%

3,944,151.96 3,653,759.24 634,966.32

5,289,809.64 2,566,554.34 192,335.52

3,001,128.30 2,478,399.00 40,418.40

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.

Page 21 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

contain some of the characteristics. The transaction-oriented characteristics32 are not shown. They are contained in all the summarization levels. Category

National  Account

 Account

Product Class

Zone 000001 000002 Chain 000003

Supervisor  Brand

District

000004

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 

Page 23 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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.

Page 26 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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 record s 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.

Page 27 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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 out”39 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 scan”40 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

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.

38

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.

39

40

Page 28 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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.

Page 29 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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.

Page 31 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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.

Page 32 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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).

Page 33 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

Page 34 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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 P p 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 + P p ). 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).

•

P p 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

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.

46

47

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.

Page 35 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

(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.

Page 36 of 40

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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 r eport, 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

Date: 30.01.2003 08:30:00 vorm.

SAP AG

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

•

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 to ol 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

Profitability Analysis CO-PA

Strategies for Using Summarization Levels

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