Non-Cumulative vs. Cumulative KeyFigures for Inventory Cube Implementation?

[Former Member]

A non-cumulative is a non-aggregating key figure on the level of one or more objects, which is always displayed in relation to time. Generally speaking, in SAP BI data modeling, there are two options for non-cumulative management. First option is to use non-cumulative management with non-cumulative key figures. Second option is to use non-cumulative management with normal key figures (cumulative key figures). For SAP inventory management, 0IC_C03 is a standard business content cube based upon the option of non-cumulative management with non-Cumulative key figures. Due to specific business requirements (this cube is designed primarily for detailed inventory balance reconciliation, we have to enhance 0IC_C03 to add additional characteristics such as Doc Number, Movement type and so on. The original estimated size of the cube is about 100 million records since we are extracting all history records from ECC (inception to date). We spent a lot of time to debate on if we should use non-cumulative key figures based upon the standard business content of 0IC_C03 cube. We understand that, by using Non-Cumulative key figures, the fact table will be smaller (potentially). But, there are some disadvantages such as following:

(1) We cannot use the InfoCube together with another InfoCube with non-cumulative key figures in a MultiProvider.

(2) The query runtime can be affected by the calculation of the non-cumulative.

(3) The InfoCube cannot logically partition by time characteristics (e.g. fiscal year) which makes it difficult for future archiving.

(4) It is more difficult to maintain non-cumulative InfoCube since we have added more granularity (more characteristics) into the cube.

Thus, we have decided not to use the Cumulative key figures. Instead, we are using cumulative key figures such as Receipt Stock Quantity (0RECTOTSTCK) , Issue Stock Quantity(0ISSTOTSTCK)

, Receipt Valuated Stock Value (0RECVS_VAL) and Issue Valuated Stock Value (0ISSVS_VAL). All of those four key figures are available in the InfoCube and are calculated during the update process. Based upon the study of reporting requirements, those four key figures seems to be sufficient to meet all reporting requirements.

In addition, since we have decided not to use cumulative key figures, we have removed non-cumulative key figures from the 0IC_C03 InfoCube and logically partitioned the cube by fiscal year. Furthermore, those InfoCube are fiscally partitioned by fiscal year/period as well.

To a large extent, we are going away from the standard business content cube, and we have a pretty customized cube here. We'd like to use this opportunity to seek some guidance from SAP BI experts. Specifically, we want to understand what we are losing here by not using non-cumulative key figures as provided by original 0IC_C03 business content cube. Your honest suggestions and comment are greatly appreciated!

[Former Member]

The standard infocube is ready for work in the way its defined you cannot change the cumulative or non cumulative settting of the key figures....if you use the standard you must use the configuration by default..

regards

[former_member93896]

Hi Dongxin,

which scenario is best depends on the reporting requirements (how frequently do you run queries and at what level of detail) and on the number of movements you are having in your transaction data.

There's also a third option: in addition to the standard non-cum. InfoCube and pre-calculating the inventory in transformations, you can take snapshots of the data. Please see the how-to guide for more details:

https://www.sdn.sap.com/irj/sdn/howtoguides > NW 2004 BI > How to Handle Inventory Management Scenarios

Regards,

Marc

SAP NetWeaver RIG

[Former Member]

Hello Marc,

Thanks for the reply.

I work for Dongxin, and would like to add couple of points to the original question...

Based on the requirements, we decided to add Doc Number and Movement type along few other characteristics into the InfoCube (Custom InfoCube - article movements) as once we added these characteristics the Non Cumulative keyfigures even when the marker was properly set were not handling the stock values (balance) and the movements the right way causing data inconsistency issues.

So, we are just using the Cumulative keyfigures and have decided to do the logical partitioning on fiscal year (as posting period is used to derive the time characteristics and compared to MC.1 makes more sense for comparison between ECC and BI.

Also, I have gone through the How to manual for Inventory and in either case the reporting requirement is Inception to date (not just weekly or monthly snapshot).

We would like to confirm if there would be any long term issues doing so.

To optimize the performance we are planning to create aggregates at plant level.

Couple of other points we took into consideration for using cumulative keyfigures are:

1. Parallel processes possible if non-cumulative keyfigures are not used.

2. Aggregates on fixed Plant possible if non-cumulative keyfigures are not used. (This being as all plants are not active and some of them are not reported).

So, since we are not using the stock keyfigures (non cumulative) is it ok not to use 2LIS_03_BX as this is only to bring in the stock opening balance....

We would like to know if there would be any issue only using BF and UM and using the InfoCube as the one to capture article movements along with cumulative keyfigures.

Once again, thanks for your input on this issue.

Thanks

Dharma.

[Former Member]

Hi Dongxin Luo, Welcome to SDN.

Using Non-cumulative or cumulative is purely based on requirement.

As you are adding document no and moment type, Non-cumulative keyfigures creates very bad query performance.

What level of reporting you are looking for...? Day or week or year...? If its a week level, then use normal keyfigures and implement snap shot approach(weekly or monthly).

I suggest, instead of changing standard cube this extent, its better to create a new one by copy and use. Any content upgrade easy to handle.

If you are not using document no and moment type for reporting, i suggest not to maintain at cube level. Create one ODS/DSO below cube and maintain same. and can be used same ODS for snap shot building.

Apply restriction/derivation logic between ODS to CUBE and aggregate maximum.

This way, you can achive a flexible architecture for better performance and easy maintanance.

Hope it helps

Srini

[Dont forget to close the call by assigning poings.... - Food for Points: Make a Difference through Community Contribution!|https://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/007928c5-c4ef-2a10-d9a3-8109ae621a82]

[Former Member]

Hello Srinivas,

Thanks for the reply.

I would like to know more details about the performance issues when using non cumulative keyfigures with document number and movement type.

Is it even possible with document number and movement type in the InfoCube.

When we enhanced the InfoCube with these fields the stock values were being handled incorrectly even after the marker was updated correctly.

I even checked for the InfoCube definition with the program for consistency and there were no issues for the InfoCube.

Can you please provide more information on if the non cumulative keyfigures actually work once the InfoCube is enhanced with Document Number and movement type.

If possible, I would like to arrange a conference call.

I work for Dongxin.

Thanks

Dharma.

[Former Member]

Its been a while since worked in Inventory management so bear with me.

Just a quick question. How are you actually deriving total stocks etc if not using Snap Shot scenario? Are these KPIs not required since the non cum model will derive these at run time. The concern here is how does your derivation model work and potentially impact performance

Volume seems manageable

[Former Member]

Hi Dharma,

So, since we are not using the stock keyfigures (non cumulative) is it ok not to use 2LIS_03_BX as this is only to bring in the stock opening balance....

--> Yes, If all data available in source system(no archiving), then you can pull BF(all moments) and UM and compress with Marker Update if you are using Non-Cumulative Keyfigures.

If you are maintaining, Moment type and document no at CUBE level, Non-Cumulatives key figures creates performance issues a lot.

Its better to avoid this level of detail at reporting level, For details create another target and use Jump Queries.

Its better to go for Snap Shot(Monthly) for better performance and partion cube based on Month.

Hope it Helps

Srini

[Dont forget to close the call by assigning poings.... - Food for Points: Make a Difference through Community Contribution!|https://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/007928c5-c4ef-2a10-d9a3-8109ae621a82]