0IC_C03 related Inventory Process - Logical Partitioning (Vs) Physical Part

[Former Member]

Hello Everyone,

After going through multiple postings throughout the form and documentation from SAP, it states that the 0IC_C03 InfoCube when used with Non Cumulative keyfigures is not recommended to be partitioned logically by physical year/calendar year as the query will read all the data sets due to the stock marker logic.

In our specific scenario,

1. After the InfoCube (0IC_C03) was enhanced with additional characterisitcs such as Doc Number, Movement type and so on due to business requirements I was not able to actually use the Non Cumulative Keyfigures as they were not populated within the report.

2. So, we decided not to use the Non Cumulative keyfigures but rather create two cumulative keyfigures (Issue Stock Quantity - Receipt Stock Quantity) and (Issue Valuated Stock Value - Receipt Valuated Stock Value) and both of these are available in the InfoCube and are calculated during the update process.

These two keyfigures are cumulative with exception aggregation of LAST based on 0CALDAY.

The question is,

Since we are not using the actual Non Cumulative Keyfigures (even though we are not using these, we still have the stock marker updated and data compressed based on this along with Validity table defined) can we do logical partitioning on the InfoCube based on Calendar year.

Thanks....

[Former Member · Accepted solution]

Since the Non-Cumulative KF is still present in the cube and must be getting used to calculate the KF which you have defined, The cube still can not be partitioned. It will have the same impact on query result.

Thanks...

Shambhu

[Former Member · Accepted solution]

Hello,

Even though the Non Cumulative keyfigures are available in the InfoCube, we are not using them to calculate the other keyfigures in the InfoCube used for reporting.

That is the reason why I am starting to look into options of doing the breakdown by calendar year for logical partitioning...

Please let me know if there is any other issue you could foresee...

Thanks

Dharma.

[Former Member · Accepted solution]

Good to know that you have realized you have not made yourself clear

You are combining many things and complicating the problem. Logical and technical partitioning are done to improve reporting and administrative performance. So keep that separate.

Functionally are you analyzing stock or article movements? Both of them are modeled via two different cubes. You can, if you dont bother about performance, add document number and movement type in the article movement cube. But you cannot do that in the stock cube!

You can partition the article movement cube both technically and logically. Where as you can only technically partition the stock cube.

Cheers...Elango

[Former Member · Accepted solution]

Hello Elango,

Appreciate your response.

First of..I do understand the difference between logical and physical partitioning and the question is not about joining them together.

I am sorry, if others cannot understand the detailed issue posted. My apologies was a part of polite gesture, and please do respond back with proper precise answer if you think you did actually understand the question....

The question here is about how I can leverage the performance and administrative performance by logically breakingdown the data.

The issues due to which I am trying to look into different aspects of logical partitioning are:

1. If I do logical partitioning by Plant due to the stock marker logic then I cannot do archiving as a Plant and its related data cannot be archived by time characteristic as the partitioning is not done by time characteristic.

2. The reason I would have to have document number and movement type in the InfoCube is due to the kind of reporting users perform.

We have a third party system whose data needs to be reconciled to the data in the plants and storage locations.

And in order to do so, the first step users would be running the report is plant, storage location and sku. From here on for the storage locations which have balance they would like to drill down on to the document number and movement type to see what the actual activity is.

So, to support this requirement I would have to have the above characterisitcs in the InfoCube.

The question again is,.....what is the exact list of issues I would be having doing the logical partitioning by time characteristic.

Once again, even though the non cumulative keyfigures are available in the InfoCube we are not using them for any reporting purpose....so please keep that in consideration while replying back.

Thanks

Dharma.

[Former Member]

Thanks everyone.

Dharma.

[Former Member]

1) Two similar infocubes (say one with year 2007 and another with year 2008) with non cumulative kf cannot be combined using the concept of multiproviders. Hence concept of logical partitioning would not work. Refer Note: 690475.

2) Why do you include document numbers in the infocube? I would suggest create a DSO with Article doc num and movement type! The two characteristics should not be included in the infocube as opening stocks via DS: 2LIS_03_BX does not contain them. Thus will end up in a wrong model!

3) Without using non cumulative key figures in this cube how will you calculate current stock? I can't imagine any way to do that!

The concept of this infocube is to load data for opening stocks (2LIS_03_BX) once during the start, then continue to load data for article movements (2LIS_03_BF) daily.

[Former Member]

Hello,

I guess I have not made myself clear.

Even though we are having the non cumulative keyfigures in the InfoCube we are not using them.

I am only using the receipt and issue cumulative keyfigures which are available by default in the standard content.

The reason why we have the Document Number and Movement type in the InfoCube is because the users want to use the same report to drill down to more details and do not want to use the report to report functionality.

Also, since the scenarion we are trying to implement is not snapshot scenario we are planning of a DSO....

Even though the initial load BX does not support the document number and movement type fields the amounts would still be aggregated when reporting at Plant, Storage Location, Material level.

So, please let me know if I am not using the Non Cumulative keyfigures in reporting...can I go ahead and do the logical partitioning by calendar year...

Response would be really appreciated.

Thanks

Dharma.