Aggregation Level
Aggregation levels are used as InfoProviders for planning: They allow you to model levels containing data that can be changed manually, using input-ready queries, or automatically, using planning functions.
An aggregation level is defined by a set of characteristics and key figures of the underlying InfoProvider. The key figures contained in the aggregation level are aggregated using the characteristics not contained in the aggregation level.
The simplest case is where an aggregation level lies on an InfoProvider, which is suitable for planning. Aggregation levels can also be created on InfoProviders that are suitable for planning, as they contain a basic InfoProvider that is suitable for planning: You can create several aggregation levels for one InfoProvider.
Simple Aggregation Level
A basic InfoProvider is based on a simple aggregation level.
Complex Aggregation Level
A complex aggregation level is based on InfoProvider containing at least one basic InfoProvider suitable for planning, but no simple aggregation level.
You want to copy current data from an actual basic InfoCube to a plan basic InfoCube with a planning function of type Copy. To do this, you use an aggregation level based on an InfoProvider that includes the plan and actual InfoProviders.
Aggregation levels cannot have a nested structure.
With a complex aggregation level, it is important to note how data records from the basic InfoProvider are embedded in this InfoProvider, which contains the basic InfoProvider, (and also embedded in the aggregation level), and how the system writes changes to the data records of the aggregation level back to the basic InfoProvider.
The following conditions apply for both aggregation level types:
The aggregation level must contain at least one key figure.
The key figures used here must have the database aggregations SUM, MIN, MAX or NO2. With MIN or MAX, key figure values can only be displayed. They cannot be changed using manual planning or planning functions.
For key figures of type date or time, only data type DEC is supported.
Referencing key figures (and therefore non-cumulative key figures or elimination of internal business volume too) are not supported in aggregation layers.
If a characteristic is compounded and used in an aggregation level, the aggregation level must also contain all compounding "parent" characteristics.
If a key figure is used in an aggregation level and does not have a fixed unit of measure or currency, the aggregation level must contain the associated characteristic for the unit.
If a key figure with exception aggregation is used in an aggregation level, the aggregation level must also contain the characteristic for exception aggregation if it occurs in the underlying InfoProvider.
The aggregation level inherits a navigation attribute from the underlying InfoProvider if it includes the basic characteristic of the navigation attribute.
A complex aggregation level cannot be created if a characteristic of a basic InfoProvider supplies two separate characteristics in the higher-level InfoProvider.
If a characteristic on the InfoProvider that serves as the basis for an aggregation level is constant, this characteristic has to be included in the aggregation level.
An aggregation level that uses a DataStore object for direct updates in planning mode or a DataStore object (advanced) with modeling property “direct update” (in either direct or indirect conjunction with a InfoProvider) must contain enough characteristics to fill the DataStore object key. If the key fields are not all directly included in the aggregation level, then characteristic relationships are required to derive the missing key fields from the characteristics included in the aggregation level.
NoteIn some cases, this condition cannot be fully checked in the aggregation level modeling, because the derivation steps are only performed at runtime. Therefore the situation might occur where the system only checks incomplete modeling at runtime and cannot change the data using planning functions (cells in queries are no longer input-ready).
In the following cases, a CompositeProvider cannot be used as the basis for an aggregation level (see 2091885
):The CompositeProvider contains a JOIN with a plannable basic InfoProvider.
The CompositeProvider contains characteristic A, which is assigned to additional characteristic B from another contained InfoProvider. Here, A does not reference B and B does not reference A.
The CompositeProvider contains a navigation attribute, which is not supplied by a plannable basic InfoProvider.
The CompositeProvider contains a plannable basic InfoProvider with the Criteria filter.
Conditions that apply to an aggregation level, which uses characteristics as key figures
Characteristics from the data part can only be exposed as key figures in a DataStore object for direct update in planning mode or a DataStore object (advanced) with modeling property “Direct Update”.
If A is a characteristic, 1KYF_A is the name of the associated key figure.
Please note that unit characteristics must always be contained in the key of the plannable DataStore object. Otherwise it is not possible to create an aggregation level on this DataStore object. This also means unit characteristics cannot be exposed as key figures.
The following rules apply for compound characteristics in the data part of a DataStore object, if you want these characteristics to be included as key figures in an aggregation level.
If characteristic C is compounded to characteristic A and 1KYF_C is to be added to the aggregation level, then either; A must be in the key of the DataStore object and A must be added to the aggregation level, or A must be in the data part of the DataStore object and then added as 1KYF_A to the aggregation level.
If characteristic is compounded to characteristic B and 1KYF_B is to be added to the aggregation level, then 1KYF_C must also be added to the aggregation level.