Inventory Management (Advanced - Marker update)

[Former Member]

I have been following your discussion regarding Inventory Management and the use of 2LIS_03_BX and 2LIS_03_BF extractors, and I have also been studying the How to guide on Inventory Management.

I am currently only using 2LIS_03_BF with no data restriction in the setup-run or in the initialization. The stock balance is correctly even though I am not using 2LIS_03_BX (because the sum of all historical movements equals the current balance).

But I am facing performance problems because I am not using compression. I am considering 2 solutions:

<b>Solution A (the easy)</b>

1. Compression on all request (with marker update)

<b>Solution B (as suggested in the How-to-guide)</b>

1. Delete InfoCube data

2. Generate new balance with 2LIS_03_BX

3. Compression of 2LIS_03_BX (with marker update)

4. Reconstruct old 2LIS_03_BF requests from PSA

5. Compression of old 2LIS_03_BF requests (No maker update - because all these will new be considered historical in relation with the newly generated stock balance).

6. Future deltaloads from 2LIS_03_BF and compression (with marker update).

As I see both solutions will solve the problem but A is by far the easiest. I would like your opinion!

When you do the marker update during compression does it matter wether you do it as described in the how-to-guide I can you do it as follows instead:

1. Compression of Historical Movements (2LIS_03_BF) (with marker update)

2. Compression of Stock balance (2LIS_03_BX) (No marker update)

3. Compression of Future Movements (2LIS_03_BF) (with marker update)

As I see the only important thing is that you do the marker update with <i>either</i>Historical Movements (2LIS_03_BF) <i>or </i>Stock balance (2LIS_03_BX), but not both of them or none of them. I am not 100% sure but please give me your opinion.

[Former Member]

Hello Thomas,

I have never tried doing the marker update other way around (through BF instead of BX), but I don't see any reason why it will not work. You are right that marker update should be done either with snapshot or material movement as both datasources bring same data at different granularity level. Solution A seems to be simpler and straightforward, but I am not sure if there will be any impact on performance if we update the marker intially with lot of requests from BF instead of a single BX request.

Regards,

Praveen

[Former Member]

Hi Praveen

I do not think that query performance depends on the chosen solution, because I think the different solutions will result in exactly the same amount of marker values (same as characteristic combinations) and their values should also be the same. But if you think of performance in terms of processing-time during compression, then you are probably right, because the BF-compression will have a lot of movements from which the marker must be calculated.

/Thomas