COPA SUMMARIZATION LEVEL

(1)

Strategies for

Strategies for Using Summ

Using Summarization Levels

arization Levels

Content

Content and T

and Target

arget Group

Group

This documentation contains the answers to

This documentation contains the answers to some frequently asked questions aboutsome frequently asked questions about

summarization levels in costing-based Profitability Analysis. Where necessary, some basic summarization levels in costing-based Profitability Analysis. Where necessary, some basic inform

information about drill-down reporting is repeateation about drill-down reporting is repeated in the appendix (sectiond in the appendix (section)).. A second do

A second document will cument will be prodube produced on ced on “performance strategies”, i.e. which of the “performance strategies”, i.e. which of the availaavailableble performance-im

performance-improving tools (summarproving tools (summarization leveization levels, summls, summarization data, frozen report arization data, frozen report data,data, report/report interface) should be used and when.

report/report interface) should be used and when.

This document is written for CO-PA consultants, advanced users,

This document is written for CO-PA consultants, advanced users, and others and others who deal withwho deal with questions about optimizing performance when reading the data in Profitability Analysis. The 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 subject matter here is of a very technical nature. Consequently, it requires a certain amount of of time to familiarize oneself.

time to familiarize oneself. A few rules that should at

A few rules that should at all tall times be observed are written imes be observed are written in bold tyin bold type and surrpe and surrounded by aounded by a red frame. You should not

red frame. You should not deviate from these rules unless the situation has been analydeviate from these rules unless the situation has been analyzed inzed in detail (where necessary, with the help of SAP’s Second Level S

detail (where necessary, with the help of SAP’s Second Level Support)upport).. In addition to

In addition to reading this documentation, it is reading this documentation, it is strongstrongly recommenly recommendedded

that you work on a project that allows you to gain practical

knowledge.

Basic Facts About Summarization Levels

Please read the online documentatio Please read the online documentationn

on summarization levels under on summarization levels under Controlling

Controlling → → Profitability AnalysisProfitability Analysis→ → Tools.Tools.

In the transaction data

In the transaction data11_{in Profitability Analysis, the profitability segments are represented by a}_{in Profitability Analysis, the profitability segments are represented by a}

combination of individual values for all characteristics. A

combination of individual values for all characteristics. A Summarization level Summarization level is a copy of theis a copy of the

1

1 _{We consider the “transaction data in Profitability Analysis” to include the segment table CE4xxxx (the}_{We consider the “transaction data in Profitability Analysis” to include the segment table CE4xxxx (the} profitability segments), the

profitability segments), the segment level CE3xxxx (thsegment level CE3xxxx (the period values for the profitabilie period values for the profitability segments) and thety segments) and the two line item tables CE1xxxx (actual line items) and CE2xxxx (plan line items). In these table names, xxxx 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 stands for the name of the operating concern. In other contexts, the profitability segments have more the character of master data.

(2)

(3)

transaction da

transaction data in summarized form.ta in summarized form. Summarize Summarize means to gromeans to group thup the original profitabile original profitabilityity segments together into new “segments” that no longer contain some characteristics:

segments together into new “segments” that no longer contain some characteristics: profitabili

profitability segty segments from the original ments from the original dataset thdataset that have the same definiat have the same definition after the values of tion after the values of these characteristics are replaced by the INITIAL value are grouped together in the

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 summarization level as one “segment”. The system adds up the values in the value fields of the involved segment level records.

involved segment level records. Example:

Example: Let us look at an operating concern E001, which contains the characteristicsLet us look at an operating concern E001, which contains the characteristics “Customer” and “Produc

“Customer” and “Product” and t” and the value field “Revethe value field “Revenue”.nue”. The segment table

The segment table CE4E001 cCE4E001 contains the ontains the followifollowing profitabilitng profitability segments:y segments: (PS = profitability segment):

(PS = profitability segment): P

PS S 11 CCuussttoommeer r 11 PPrroodduucct t 11 P

PS S 44 CCuussttoommeer r 22 PPrroodduucct t 44 The segment level CE3E001 contains the

The segment level CE3E001 contains the followifollowing period values:ng period values:33

P

PS S 11 PPeerriiood d 000011//11999977 RReevveennuue e UUSSD D 110000..0000 P

PS S 44 PPeerriiood d 000022//11999977 RReevveennuue e UUSSD D 111100..0000

If this dataset is summarized across the characteristic “Product” (i.e. if the product If this dataset is summarized across the characteristic “Product” (i.e. if the product is ignored), we

is ignored), we obtain the obtain the followifollowing summaring summarized “segments”:zed “segments”:44

P

PS S 55 CCuussttoommeer r 11 PPrroodduucct t IINNIITTIIAALL P

PS S 66 CCuussttoommeer r 22 PPrroodduucct t IINNIITTIIAALL and the periods

and the periods P

PS S 66 PPeerriiood d 000022//11999977 RReevveennuue e UUSSD D 111100..0000

Summa

Summarization Levels

rization Levels and Summarization Data

and Summarization Data

Since Releas

Since Release 3.0C, e 3.0C, you can use you can use summarsummarization levelization levels to s to store store presummaripresummarized datasets zed datasets inin costing-based Profitability Analysis for use in different areas of CO-PA.

costing-based Profitability Analysis for use in different areas of CO-PA.55_{Summarization levels}_{Summarization levels}

that are active and contain data are automatically used for the functions: that are active and contain data are automatically used for the functions: •

• _{online planning}_{online planning} •

• _{complete planning}_{complete planning} •

• _{transfer to SOP}_{transfer to SOP}

2

2 _{The terms “aggregate” and “aggregation” also appear frequently in the literature.}_{The terms “aggregate” and “aggregation” also appear frequently in the literature.} 3

3 _{The characteristics “Plan/actual indicator”, “Record type” and “Plan version” are also included in the}_{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 segment level. However, this information is irrelevant to helping you understand the subject matter and was therefore excluded.

therefore excluded. 4

4 _{These could also be the profitability segments in operating concern E001 if “Product” had not been}_{These could also be the profitability segments in operating concern E001 if “Product” had not been} included as a segment-level characteristic.

included as a segment-level characteristic. 5

5 _{See the chapter under Tools}_{See the chapter under Tools} _→_→_{Summarization levels in the online documentation and in Customizing.}_{Summarization levels in the online documentation and in Customizing.} The terms that are explained there will be used in this document without further explanation.

(4)

•

• _{assessment of cost center costs to CO-PA (for the purpose of determining the tracing factor}_{assessment of cost center costs to CO-PA (for the purpose of determining the tracing factor} based on variable

based on variable shares)shares)

You could also use summarization levels in You could also use summarization levels in •

• _drill-_{drill-down repor}_{down reporting}_ting by activati

by activating the “Information syng the “Information system” button in Customizingstem” button in Customizing66_{when defining the}_{when defining the}

summarization levels. If this flag is active (“Use summarization levels in reports”), the system summarization levels. If this flag is active (“Use summarization levels in reports”), the system reads summarizat

reads summarization levels ion levels when you execute repowhen you execute reports. rts. If the flag is not active (“UseIf the flag is not active (“Use summar

summarization data (as in Release 2.2)”), the ization data (as in Release 2.2)”), the summarsummarization levelization levels are not s are not used for repused for reports.orts. Instead, the system reads the summarization stored separately for each report, a technique that Instead, the system reads the summarization stored separately for each report, a technique that was already available

was already available in Release 2.2 and is in Release 2.2 and is explained explained in detail in in detail in OSS note 2OSS note 217731773.. Note tha

Note that the decision to use st the decision to use summaummarization leverization levels ils in reports on reports only cnly can be made once for eachan be made once for each operating concern, whereas you can decide separately for each report whether or not you want operating concern, whereas you can decide separately for each report whether or not you want to

to use summarizuse summarization data (pation data (provided that rovided that the flag “Informatthe flag “Information system” is set to “Useion system” is set to “Use summar

summarization data (as ization data (as in Releain Release 2.2)”).se 2.2)”).

This means that you cannot store summarization

This means that you cannot store summarization datadatafor anyfor any

individual reports once you have set the flag to “Use summarization

levels in reports”.

levels in reports”.77

This does not affect the option to freeze report data. This does not affect the option to freeze report data.88

Note:

Note: For operaFor operating concerns created ting concerns created in Releain Release 3.0C or se 3.0C or higher, the “Information syhigher, the “Information system”stem” flag is set to

flag is set to “Use summ“Use summarization levelarization levels in reports” s in reports” by default. For operaby default. For operatingting concerns from Release 3.0B or ea

concerns from Release 3.0B or earlier, the default setting is “Userlier, the default setting is “Use summar

summarization data (as ization data (as in Relin Release 2.2)” even after an upease 2.2)” even after an upgrade to grade to Release 3.0CRelease 3.0C or

or higher. In many higher. In many of these opeof these operating concerns, the rating concerns, the customers have optimizedcustomers have optimized their reports for the use of summarization data. This presetting was chosen so their reports for the use of summarization data. This presetting was chosen so that

that the customer the customer can easily can easily continue using the system as before after thecontinue using the system as before after the upgrade.

upgrade. You can You can switch to switch to “Use summar“Use summarization levelsization levels” at any point ” at any point in time. Itin time. It is also possible to “switch back” t

is also possible to “switch back” to o using summusing summarization data at arization data at any time. If youany time. If you want to do this, see OSS note 70339.

want to do this, see OSS note 70339.

Data Structure

Every summar

Every summarization level consists of two ization level consists of two tables (simitables (similar to lar to the datthe data basis itself a basis itself 99_{): the}_{): the}_key_key

table

table corresponds to the segment table and contains those “corresponds to the segment table and contains those “market-orientedmarket-oriented” characteristics” characteristics1010

6

6 _{Transaction KEDV}_{Transaction KEDV} 7

7 _{In some customer projects both summarization levels and summarization data are being used}_{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 simultaneously with the support of the SAP development team. For more information, see note 82468 (not released for customers).

released for customers). 8

8 _{See the online documentation or note 21773.}_{See the online documentation or note 21773.} 9

9 _See_{See note 21773 in O}_{note 21773 in OSS,}_{SS, section 3.}_{section 3.} 10

10 _““_{Market-oriented}_{Market-oriented}_{” characteristics in this documentation are those characteristics that are stored in}_{” 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 the segment table CE4xxxx. This includes the characteristics to which values can be assigned. In addition to

(5)

that were selected for

that were selected for the summarithe summarization levelzation level, plus the plan/actual i, plus the plan/actual indicator ndicator and plan versioand plan version.n. The

Thesummary tablesummary table contains the contains the transaction-specific characteristics “Period”, transaction-specific characteristics “Period”, “Fisc“Fiscal year”al year” and “Record type”,

and “Record type”, plus the value fields and quantity unit fielplus the value fields and quantity unit fieldsds..1111

Example:

Example: Let us look at operating concern E001 again.Let us look at operating concern E001 again. If we define a summariz

If we define a summarization level 0001 that ation level 0001 that contains the characteristiccontains the characteristic “Customer”, but no

“Customer”, but not “Product”t “Product”, the , the key table wilkey table will look like this:l look like this: K

Keey y nnoo. . 11 CCuussttoommeer r 11 PPrroodduucct t IINNIITTIIAALL K

Keey y nnoo. . 22 CCuussttoommeer r 22 PPrroodduucct t IINNIITTIIAALL and the summary table will look like this:

and the summary table will look like this: K

Keey y nnoo. . 11 PPeerriiood d 000011//11999977 RReevveennuue e UUSSD D 110000..0000 K

Keey y nnoo. . 11 PPeerriiood d 000022//11999977 RReevveennuue e UUSSD D 224400..0000 K

Keey y nnoo. . 22 PPeerriiood d 000022//11999977 RReevveennuue e UUSSD D 111100..0000

Read Access

A Formula for Measuring Reading Speed

The system reads the

The system reads the summarsummarization levelization levels the same way it reads s the same way it reads the data the data basis (see sectionbasis (see section)).. Take

Take R R to to be the reading performance in records per be the reading performance in records per second. This value is a constant whichsecond. This value is a constant which also depends on the

also depends on the hardware one is using. This value needs to be redetermined for eachhardware one is using. This value needs to be redetermined for each installation

installation..1212 _{The followin}_{The following formula y}_{g formula yields the time n}_{ields the time needed to}_{eeded to read a}_{read a report}_{report from a}_{from a}

summarization level: summarization level:

T

Treadread [sec] = N[sec] = N×× PPvv×× ( 1 + P( 1 + P p p) ) / / R R

The letters in this formula mean the following: The letters in this formula mean the following: •

• _N_N _{is the number of combina}_{is the number of combinations of values of the required market-oriented}_{tions of values of the required market-oriented characteristics in}_{characteristics in} the key table.

the key table. •

• _P_P_v_v_{is the number of plan versions be}_{is the number of plan versions being read (actual data}_{ing read (actual data counts as}_{counts as one version in this}_{one version in this} context).

context). •

• _P_P_p_p _{is the number of combinations of periods and r}_{is the number of combinations of periods and record}_{ecord types (includin}_{types (including the full numb}_{g the full number of}_{er of} periods for each fiscal

periods for each fiscal year in year in the reportthe report).). The appendix (section

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

the market-oriented characteristics, there are also “

the market-oriented characteristics, there are also “transaction-specifictransaction-specific” ones -” ones -- “Record type”,- “Record type”, “Plan/actual indicator”, “Plan version” and “Period” that are stored in the segment level CE3xxxx. “Plan/actual indicator”, “Plan version” and “Period” that are stored in the segment level CE3xxxx. Furthermore, there are

Furthermore, there are technicaltechnicalcharacteristics that are only updated in the CO-PA line item (“Costcharacteristics 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. object”, “WBS element”, and so on) but are not included in the segment table or the segment level. 11

11 _{Using the settings in Customizing (transaction KEDV), you can only influence the structure of the key}_{Using the settings in Customizing (transaction KEDV), you can only influence the structure of the key} table.

table. 12

12 _{As an initial estimate for reading performance, you can expect approx. 500.000 records per hour}_{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 (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 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 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 structures contain fewer fields and are designed more for the purpose of allowing efficient access than for business functionality.

(6)

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. ThusN = number of customer groups× _{number of product groups = 1000. Furthermore, it is clear that}_P_v_{= 2 (one for the} actual data plus the plan version) andPp = 24 (2 years× 12 periods and only one record type).

The read time required for this report is:

(7)

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

(8)

− _{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 columns}13

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) isverylarge 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 _{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 .

14 _{See also the section “Defining Summarization Levels” in the Extended Help for the maintenance} transaction (transaction KEDV).

(9)

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 Plan revenues (version 001) Dr. Miller's Spot-Be-Gone 0.2L 9,968,745.00 10,000,000.00 Wishy Washy Sponge small 6,622,343.00 7,000,000.00 Hair-o-fix Hair Restoring Powder 200g 2,097,509.00 2,000,000.00 Fixolan Fast-Drying Glue 5g 2,588,045.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 _{(from the general data selection in the form)}

• _{Record type} _{(from the general data selection in the form)} • _{Plan/actual indicator} _{(from the definition of the columns in the form)}

• _{Plan version} _{(from the definition of the second column in the form)} • _Product _{(from the definition of the rows in the form)}

• _{Customer group} _{(from the selection criteria for the report)} • _{Customer district} _{(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.}

16 _{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.

(10)

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

(11)

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 performone 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 performone 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 _{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.

21 _{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.

(12)

# of Updates

size of SL size of buffer

size of CE3xxxx

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.

(13)

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 drives}24_{, 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 _{For example, using striping techniques. For more information, see OSS note 35288.} 25 _{See also section 4.3 and chapter 9 in note 21773 in OSS.}

26 _{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).

(14)

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 000001is 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 containsin 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 asmaller summarization level is contained in a larger one.

A series of summarization levels 000001, 000002, 000003... form astack 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 arehigher up in the stack and that the larger ones arelower 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:

(15)

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

(16)

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 Drill down CE4 Summarization to be read report data Selection

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.

(17)

Actual Plan Var. 1-3/1997 1-3/1997 % Sales quantity 345,253 300,000 15.1% Revenues 2,002,467.40 1,740,000.00 15.1% Discounts 68,083.89 60,900.00 11.8% Cash discounts 36,044.41 34,800.00 3.6% Net revenues 1,898,339.10 1,644,300.00 15.4% Sales commission 160,197.39 174,000.00 -7.9% Goods usage 552,404.80 450,000.00 22.8%

Var. production costs 40,049.35 31,320.00 27.9% Contribution margin I 1,145,687.56 988,980.00 15.8% Fixed production costs 56,800.00 60,000.00 -5.3% Fixed material costs 21,565.00 20,000.00 7.8% Contribution margin II 1,067,322.56 908,980.00 17.4%

Administrative costs 79,788.00 80,000.00 -0.3%

Gen. marketing costs 110,345.00 120,000.00 -8.0%

Sales costs 324,445.00 300,000.00 8.1%

Research & development 55,677.00 60,000.00 -7.2%

Profit 497,067.56 348,980.00 42.4%

Profit / Unit sold 1.44 1.16

Previous periods Current period

Charact. Sales Plan Met Prev.yr Sales Plan Met Prev.yr 1000 l 1000 l % % 1000 l 1000 l % % RVL1 10,034 10,000 100.4 105.7 5,340 5,000 106.8 111.3 RVL2 15,134 15,000 100.9 110.5 4,356 7,500 58.1 65.4 RVL3 12,024 13,000 92.5 100.3 5,003 6,500 77.0 93.5 RVL4 12,890 13,000 99.2 92.5 6,934 6,500 106.7 101.0 RVL5 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).

(18)

R₁=S₂ R₂ S₁ Summarization Levels Stages Stack 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

(19)

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

• _{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 N1possible values of M1. Each row represents one detail list.

Thus an optimal summarization level for the initial report would contain exactly those

characteristics fromSEL _{-- 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 N1values 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, Pvand P pare 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× ₂ × _{( 1 + 12 ) / 140 = 1,9 seconds. For the sales statistics, P}_p_{= 24} periods. This yields a required read time of 10× ₂ × _{( 1 + 24 ) / 140 = 3,6}

seconds.

Now let us look at additional characteristics.

If the initial report contains the characteristics M1and M2, this will lead to one report row for

every possible combination of M1and M2. However, the number of possible combinations

cannot be determined simply from the numbers N1and N2for the possible values of M1and M2.

In the extreme case, M1may be dependent on M2, meaning that M1is determined by M2 and

consequently there are only N2possible combinations of values.

In another case, M1and M2may be completely independent of one another, which means that

there would be N1 × N2possible 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.

(20)

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:

R₁=S₂ R₂ S₁ SEL DRI AGG Top Stage SEL DRI AGG 3rd Stage SEL AGG 2nd Stage DRI

For the stages lying further down, the quantity of DRI _{keeps becoming smaller, as}

characteristics are removed fromDRI _{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 inSEL _andDRI_.

(21)

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}

(22)

Revenue Customer groups Customer Share

Wholesale Retail Miller of RE

Product groups Hair tonic 4,533,508.00 5,453,412.00 3,334,587.00 61.1% Bubble bath 5,453,372.00 5,237,866.00 4,956,798.00 94.6% Moth powder 835,482.00 246,584.00 67,364.00 27.3% Toothpaste 343,554.00 545,432.00 456,875.00 83.8% Soap 56,578.00 74,743.00 61,070.00 81.7% Baby powder 2,342.00 7,653.00 4,008.00 52.4% Total 11,224,836.00 11,565,690.00 8,880,702.00 76.8% Strategic products Schwipps 3000 3,944,151.96 5,289,809.64 3,001,128.30 56.7% Airosan 2,0 l 3,653,759.24 2,566,554.34 2,478,399.00 96.6% Dr. Miller's Anti-moth 634,966.32 192,335.52 40,418.40 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.

(23)

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

(24)

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

Customer Product Product Class Category Brand District Zone Supervisor Chain Account National Account 000001 000002 000003 000004

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

(25)

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.

000005 000006

000007

000008

(26)

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

(27)

defined for all the characteristics in the higher (smaller) one. 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 _{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.

34 _{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”.

(28)

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_/

6of 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