Breaking New Ground: NCUM Data Modeling in SAP Datasphere vs. BW/4HANA – Part 2: NCUM in SAP BW/4HANA

In Part 1, we introduced the basics of inventory reporting with Non-Cumulative (NCUM) Key Figures and highlighted how record types help ensure accurate time-based aggregation.

In Part 2, we focus on SAP BW/4HANA, exploring the technical setup for NCUM reporting. Using a practical example, we’ll look at how inventory-enabled aDSOs handle data and how the system processes and activates stock movements.

To enable this functionality in practice, BW/4HANA relies on specific configurations within its data models. Let’s take a closer look at how this is achieved using an Advanced DataStore Object (aDSO).

For the SAP BW/4HANA system to process NCUM reporting correctly, an aDSO must be configured with specific settings:

• The special property “Inventory-Enabled” must be activated.
• This enables an additional „Inventory“ tab, allowing further configuration of the provider.
• The OLAP processor requires a time reference characteristic to calculate stock levels at any given point in time.
  

Additionally, the provider must contain a non-cumulative key figure, which can be configured as follows:

1. Define a Non-Cumulative Key Figure

• Mark the key figure as “Non-Cumulative” under “Properties”.
• The exception aggregation in SAP will automatically change to “Last Value”.

2. Configure the Non-Cumulative Tab

• Add either a cumulative dimension (which tracks stock changes with positive and negative values),
• Or use separate Inflow/Outflow key figures for tracking increases and decreases.
• Both key figures must be part of the non-cumulative provider.

Example Scenario: NCUM Processing in BW/4HANA

Let’s consider a scenario:

• At the end of the year, shelves have been emptied, and the stock value for TG12 was 0 on New Year’s Eve.
• The Reference Table reflects this with a record type of 1.
• On January 9th, goods receipt movements for TG12 are loaded into BI.
• These records are assigned a record type of 0, representing delta movements (future changes relative to the last reference point).
• On the same day, maintenance chains execute and activate the records in the stock aDSO.
• During activation:
  1. Inbound table records are deleted (as per usual behavior).
  2. Records move to the active table and are assigned record type 2, indicating historical movements.
  3. Reference table updates with the last available date and aggregated value.

To see how the process evolves over time, let’s assume the following sequence of events:

• Since January 9th, the Inbound Table has been accumulating new delta records representing stock movements.
• On January 16th, activation is triggered, moving the relevant records to the Active Table.
• When checking the system on January 28th, we observe:
  • All records up to January 16th have been transferred to the Active Table, where they are assigned Record Type 2 (historical movements).
  • The Reference Table has been updated with the latest aggregated stock value.
  • New stock movements since January 16th have continued accumulating in the Inbound Table.

Considering these updates, the data across tables would now look like this:

Once processed, this data can be viewed in its combination through the technical view created for reporting (/BIC/AaDSO7).

The yellow line is showing the reference point in time (Record Type 1). The arrow upwards means the calculation back in time (as the OLAP processor would do). The arrow downwards means the calculation into the future. Even though the last movement was on the 24th, the correct stock level will be reported on the 28th.

Summary

In Part 2, we examined the requirements and configuration in SAP BW/4HANA for handling non-cumulative (NCUM) key figures. This involved enabling inventory functionality within an aDSO, setting up time references, and defining appropriate exception aggregations.

We then explored a technical example that demonstrated how the system uses record types (0 for future deltas, 1 for reference points, and 2 for historical deltas) to manage and calculate accurate stock levels over time. The example showed how stock movements are processed, activated, and transitioned through the system’s inbound, active, and reference tables.

Outlook for Part 3

Part 3 takes the example from BW/4HANA and implements it in SAP Datasphere (DSP). It shows how to configure similar NCUM logic in a cloud-native environment—starting with importing data, defining record types, and setting up a fact model—culminating in the creation of an analytic model that supports non-cumulative measures.

Related Blogs