Non-Cumulative Key Figures in SAP BW4HANA

Cumulative values are key figures that are cumulated using all characteristics (therefore, also
using time). Non-cumulative values are key figures that are measured in relation to a period in
time, so they cannot be cumulated meaningfully over time. Non-cumulative values are
summarized over time using exception aggregation (in this case, average or last value).

Non-cumulative key figures are values calculated according to a particular period of time
(such as an opening or starting balance). The value is then incremented or decremented
based on an inflow or outflow. Inventory levels are a good example: inventory levels are
calculated based on a starting period opening balance, then derived from adding the net
inflows to and subtracting the outflows from that opening balance.

Non-cumulative values are special key figures that are different from other key figures
(cumulative values) in both data transfer and aggregative behavior.

For the query definition and navigation in reporting, there is no difference between the ways in
which cumulative and non-cumulative key figures are used. In a query, cumulative and noncumulative key figures can be evaluated simultaneously.

A non-cumulative key figure is modeled in SAP BW using the relevant field for the noncumulative value change of the relevant fields for inflows and outflows in the InfoObject
maintenance. You can determine the current non-cumulative value, or the non-cumulative
value at a particular time, from the current closing balance and the non-cumulative value
changes or the inflows and outflows.

Exception Aggregation: Non-Cumulative Key Figures

There are two ways to define non-cumulative key figures, as follows:

● Non-cumulative key figure with non-cumulative value change

Before you define the non-cumulative key figure, an additional cumulative key figure that
contains the non-cumulative value change must already exist as an InfoObject.

● Non-cumulative key figure with inflows and outflows

For the non-cumulative key figure, two additional cumulative key figures must exist as
InfoObjects: one for inflows and one for outflows. The cumulative key figure must have the
same technical properties as the non-cumulative key figure and the aggregation and
exception aggregation must both be SUM.

SAP recommend that you use non-cumulative key figures for areas in which non-cumulative values do not change
completely on a regular basis (for example, warehouse stock or number of employees).

● Non-cumulative key figures are mapped using a key figure for non-cumulative value
changes or two key figures for inflows and outflows.

● A non-cumulative key figure always has an exception aggregation with reference to time.

● An inventory ADSO must be defined containing the key figure for changes (or inflow and
outflow) and the time reference characteristic.

● Non-cumulative values are transferred in an initialization run and then subsequent change
runs.

● In certain cases, you may need to determine the validity of a non-cumulative value.

With reference to a time characteristic, such as calendar month, the non-cumulative key figure
Warehouse Stock has usually the exception aggregation last value (LAS).

Comparing the Modeling of Non-Cumulative Scenarios

Non-cumulative management with normal key figures (cumulative key figures):

Every data load represents a movement. Even though the model is designed for adding up the single values, it is still possible to define different aggregation methods in a BW Query.

Imagine that an ADSO contains warehouse stock key figures and you want to evaluate the
stock balance for the calendar month and the number of transport vehicles for the calendar
year. In this case, the calendar month is fine enough to derive both time reference
characteristics. The time characteristic calendar day must then be included in the ADSO so that it can function as a reference characteristic for timebased aggregation.

There can be several non-cumulative key figures and several time characteristics for each
inventory ADSO, but there can be only one time reference characteristic. When you update an
ADSO with non-cumulative key figures, you can maintain only the time reference
characteristic and the fiscal year variant. All other time characteristics are automatically
derived from the time reference characteristic. Therefore, if there are different noncumulative key figures of one inventory model, and it has to be fine enough to derive all time
reference characteristics.

● Advantages
– The fact tables are kept smaller.
– The history is not changed.
– A value can be calculated for any day within the validity period. You can also display non-cumulative values for periods for which no transaction data was loaded.

● Disadvantages
– You cannot use the ADSO together with another ADSO with non-cumulative key figures in one CompositeProvider.

Non-Cumulative Values with Non-Cumulative Key Figures Models

The current non-cumulative value or the non-cumulative value at a
particular time can be determined from the current closing balance and the non-cumulative
value changes or the inflows and outflows.
A non-cumulative InfoCube is modeled with at least one non-cumulative key figure that was
defined as such with the InfoObject maintenance.

Explain ADSOs for Inventory

The advanced DSO must have an inbound and an active data table. There are two modeling
options: If you only load additive deltas, you can choose the setting All characteristics are key
(“Cube-like”), if you need to overwrite characteristics, choose a Standard type. In addition, set
the Inventory property. Note that inventory advanced DSOs store characteristic values
instead of SIDs. Only in exceptional cases, it may be useful to store characteristic values and
SIDs for individual InfoObjects in such an advanced DSO.
SAP HANA-optimized Business Content for inventory management is available using
advanced DataStores.

1. New requests are loaded into the inbound table (ending at ‘1’).
2. Activating a request transfers the data from the inbound table to the active data table
(ending at ‘2’). Data records of the same key are condensed.
3. The change log (ending at ‘3’) is always created, and if the Standard type of aDSO is used,
it stores before and after images. If the Write Change Log property is not set, it remains
empty.
4. The validity table (ending at ‘4’) stores the time interval(s) for which non-cumulative
values have been loaded into the InfoProvider.

The validity characteristics form the key of the validity table. You maintain them in the
modeling UI of the advanced DSO. The validity table automatically contains the most
granular time characteristic; further characteristics are optional and should only be added
with care!

5. The reference point table (ending at ‘5’) contains reference points for non-cumulative key
figures. Unlike for InfoCubes, reference points are stored in a separate table for advanced
DSOs.

Note:
Check out these interesting notes on Inventory: 360249 Non-cumulative: No or unintelligible data found in queries. 1548125 Interesting facts about Inventory Cubes.

To load the initial stock balance, we create a DTP for DataSource with update mode Generate Initial Status . We also create a DTP from DataSource  into the advanced DataStore with extraction mode Initial Non-Cumulative for Non-Cumulative Values.

Non-cumulative advanced DSOs use the technical field RECORDTP (Record Type) to differentiate between the following:

● The reference points with RECORDTP=’1′

● Records that are not yet (semantically) contained in the reference points with RECORDTP=’0′

● Records that are already (semantically) contained in the reference points with RECORDTP=’2

While writing the initial stock balances into the inbound table, SAP BW/4HANA filled the technical field RECORDTP (Record Type) with value ‘1’.

For advanced DSOs, reference points (RECORD_TP=’1′) contain the initialization records.

Unlike for InfoCubes, they are not stored for the fixed date 9999-12-31 (infinity) but for the date as provided in the data record.

Reference points are updated whenever a request with delta movements is activated i.e. reference points are the stock values of the initialization plus or minus those of all activated requests with delta movements.

After loading the initial stock balances, we activate that request. The activation of a request
with initial stock balances transfers the data from the inbound table to the reference points
table. The record type is still ‘1’ and the values of the most granular time characteristic
CALDAY remain as originally loaded.

In the next step, we load delta movements, that is, those stock changes that occurred after
the initialization on 2015-02-22. To do so, we create a simple DTP from DataSource into the advanced DataStore  with a filter on CALDAY> ‘2015-02-22’ and run it.

As explained previously, delta movements are loaded for record type ‘0’. Consequently, we
see new records in the inbound table with RECORDTP=’0′ after loading the delta movements.
Please note that transaction SE16 shows an empty string for RECORDTP instead of the typerelated initial value (here: 0) that is stored on the database.

After loading the delta movements, we activate that request. The activation of a request with
delta movements transfers the data from the inbound table to the active data table (see the
figure, Compressing the Movement Data). We also note that all records in the active data
table now refer to RECORDTP = ‘2’ that is, record type is switched from ‘0’ in the inbound
table to ‘2’ in the active data table. Furthermore, the request information is gone, which is the
expected behavior when activating a request in an advanced DSO with modeling properties.

On top of that, the system updated the records in the reference point table while activating
the delta movements. Let’s verify that for material A100 in plant S400:

● 100 reference point before activating the delta movements
● -70 goods issue on 2015-02-25

● +150 goods receipt on 2015-02-26
● 180 new reference point value after activating the delta movements

Now, we load historical movements, that is, those stock changes that occurred before the
initialization on 2015-02-22. To do so, we create a DTP from DataSource  into
advanced DataStore  with a filter on CALDAY < ‘2015-02-22’ and update option
Historical Transactions . This option is only available for movements but as historical
transactions that were already semantically contained in the initial stock balances. It is crucial
to check this flag when loading historical transactions. Otherwise, queries on the InfoCube will
show unexpected data. SAP HANA-optimized InfoCubes and advanced DSOs. It allows SAP
BW/4HANA to detect that the request must not be handled as normal delta.

historical movements are loaded for record type ‘2’ in case the InfoProvider is an advanced DSO (or an SAP HANAoptimized InfoCube). So, we see new records in the inbound table with RECORDTP=’2′ after
loading the historical movements.

It is not mandatory to activate the request with historical transactions.

You can verify the historical movements via BW Query before collapsing the request. If you have detected errors, you are able to delete and reload the request. If you are sure that all values are stored correctly, activate the request.

Please note that the reference points are still the same.

the reference point table is not updated when activating a request with historical movements.

However, a new record with initial key figure values is created if the reference point table does not yet contain a record for the given combination of characteristic values.

The activation of a request with historical movements transfers the data from the inbound table to the active data table. The record type is still ‘2’ and the request information is gone.

Inventory InfoProviders require a non-cumulative key figure. After the Non-Cumulative setting
is made, the associated tab appears. There, the Inflow and Outflow key figures can be added.
The Inflow and Outflow key figures have Summation as their Exception Aggregation setting.

0CalMonth is set as the reference time characteristic in this example. Plant is the Validity
Characteristic.

The validity table stores the time intervals for which non-cumulative values have been loaded
into the InfoProvider. The validity characteristics form the key of the validity table. You
maintain them in the modeling UI of the advanced DSO. The validity table automatically
contains the most granular time characteristic; further characteristics are optional and should
only be added with care.