Question regarding 'no marker update' option of cube

[Former Member]

I have recently had to reload ALL the data in our BW production environment. Everything seems to have loaded successfully with the exception of our Material Movements cube. The problem is that when you query the cube you get wrong key figure values (for non-cumulative key figures) when specifying a calendar day. If I don't specify a particular day then I see the correct value.

I suspect it has something to do with the 'No marker update' option in the cube. I seem to remember having this problem in the past but I can't find any documentation from our previous problem. I'm not sure if I can simply check this option in the cube or if I have to also reload the cube... I'm really not sure what to do. Any suggestions?

Thanks!

-Patrick

[Former Member · Accepted solution]

Hi Patric,

For some info see the below link.. how to paper....

<b>How to... Handle inventory management scenarios in SAP BW 3.x (pdf)</b>

https://websmp108.sap-ag.de/~sapidb/011000358700002121282004

Hope this Helps

Srini

[Former Member · Accepted solution]

Ok I have read most of this... our cube does NOT have the option checked for 'No marker update'. So it is UNCHECKED. So based on this do you think simply compressing the cube will fix the problem?

[Former Member · Accepted solution]

Hi Patrick,

When u load data from 2LIS_03_BX you need not have to set "No Marker Update". But when u load 2LIS_03_BF u have to check mark that "No Marker Update" while doing compression. Only then you cld get the current stock perfectly.

Hope this helps.

Cheers!

Bhuvana.

[Former Member · Accepted solution]

Hi,

More Clarification:

1) In case of Delta initialization request 0f 2LIS_03_BX, we must do compression with 'Marker update'.(any way then onwards there will be no delta loadings from this DS)

2) In case of Delta initialization request 0f 2LIS_03_BF, we must do compression with 'No Marker update'.

3) In case of Delta Loads 0f 2LIS_03_BF, we must do compression with 'Marker update'.

With rgds,

Anil Kumar Sharma .P

[Former Member · Accepted solution]

Thank you all for your help. It turns out we did indeed need to first load 0f 2LIS_03_BX even though we could see no evidence that it had been run in the past when it was first implemented. We finally found in the monitor that it had been run years ago and so we had to recreate the transfer rules and infoPackage and it seemed to fix the problem.

[Former Member]

Patrick

Please check this thread which already discussed on this topic

Thnaks

Sat