Tuesday 27 March 2012

Inventory Management - Marker Update, No Marker Update

Marker Update is used to reduce the time of fetching the non-cumulative key figures while reporting. It helps to easily get the values of previous stock quantities while reporting. The marker is a point in time which marks an opening stock balance. Data up to the marker is compressed.

The No Marker Update concept arises if the target InfoCube contains a non-cumulative key figure. For example, take the Material Movements InfoCube 0IC_C03 where stock quantity is a non-cumulative key figure. The process of loading the data into the cube involves in two steps:

1) in the first step one should load the records pertaining to the opening stock balance/or the stock present at the time of implementation. At this time we will make marker to update (uncheck 'no marker update') so that the value of current stock quantity is stored in the marker. After that, when loading the historical movements (stock movements made previous to the time of implementing the cube) we must check marker update so that the marker should not be updated (because of these historical movements, only the stock balance / opening stock quantity has been updated; i.e. we have already loaded the present stock and the aggreagation of previous/historical data accumulates to the present data).

2) After every successful delta load, we should not check marker update (we should allow to update marker) so that the changes in the stock quantity should be updated in the marker value. The marker will be updated to those records which are compressed. The marker will not be updated to those uncompressed requests. Hence for every delta load request, the request should be compressed.

Check or uncheck the Marker Option:
Compress the request with stock marker => uncheck the marker update option.
Compress the loads without the stock maker => check the marker update option.

Reference information:
Note 643687 Compressing non-cumulative InfoCubes (BW-BCT-MM-BW)
Note 834829 Compression of BW InfoCubes without update of markers (BW-BEX-OT-DBIF-CON)
Note 745788 Non-cumulative mgmnt in BW: Verifying and correcting data (BW-BCT-MM-BW)
Note 586163 Composite Note on SAP R/3 Inventory Management in SAP BW (BW-BCT-MM-IM)

Marker update (or no marker update) is related to the compression process, so you should be able to find it in the Manage screen of the cube. You will find that option only if you have non cumulative KFs in the cube.

When you load historic non cummulatives you need to set the "No Marker Updating" indicator if initalization has already taken place otherwise your data will be erroneous(Data will not match with the stock on R/3 side).

Marker update is basically in the Inventory Cubes.
Inventory cube are compressed with the No Marker update flag ticked.
It is mainly used for Non cumulative Stock Hnadling.....
 
Marker is used to reduce the time of fetching the non-cummulative key figures while reporting.

This no marker update concept arrises if the cube contains a non -cuumulative key figures. say for example take the material movements cube where stock quantity is a non-cummualtive key figure. there the process of laoding the data into the cube involves in two steps.

in the first step one should load the records pertaining to the opening stock balance/or the stock present at the time of implementation. at this time we will make marker to update( uncheck no marker update) so that the value of current stock quantity is stored in the marker. After that when we r loading the historical movements (stock movements made previous to the time of implementing the cube). at this time we have to check marker update so that the marker should not be updated ( bcs of these historical movemtns only the stock balance /opening stock quantity has been updated. i.e we have already loaded the present stock and the aggreagation of previous/historical data accumulates to the present data).

Second after every successful delta loads, we should not check maker update ( we should allow to update marker) so that the chances in the stock quantity should be updated in the marker value.The marker will be updated to those records which are compressed.The marker will not be updated to those uncompressed requests. thats why for every delta load requests the requests should be compressed.
This marker is mainly used to fetch the records value for reporting. it helps easily to get the values of previous stock qunatities while reporting.
 
The Inventory mangement cube works with non cumulative key figures, so that KF are calculated as material movements inputs - outputs at query runtime, so when you report stock situation stock is calculated (for non cumulative KF) as

Initial stock + input - outputs for all dates <= your selection date.

When you init the cube you load 2LIS_03_BX, this extractor load stock situation for the day you do the extraction.

Historical movements (movements before 2LIS_03_BX) loaded as delta init though 2LIS_03_BF dont have to affect the Initial stock situation, as this movements are allready contained, so when you load and compress you have to activate the No marker Update flag in this way movements are not affecting the stock situation at query.

Material movements loaded daily (2LIS_03_BF) has to affect this stock situation (so has to affect the non cumulative KF as +input -output). This info has to be loaded and compressed without No marker Update flag.

Marker update when uploading/compressing

We will use an example to explain the procedure for a stock InfoCube
when executing a query. The scenario is as follows:
• Current date: 31.03.2002
• You have set up an opening balance of 100 units on 01.01.2002 and loaded it into the stock InfoCube.
• Historical material movements from the three previous months (October 2001:10 units; November 2001: 20 units; December 2001: 10 units) are loaded into the BW.
• Since this point, successive material movements have been transferred into the BW in the delta process. Delta requests transferred at the end of January (20 units) and February (10 units) were already compressed after successful validation, the last delta request from the end of March (10 units) is still in the InfoCube in uncompressed form.
To help explain the role of the marker (= reference point), the different upload steps are considered over time.
After uploading the opening balance, the InfoCube looks like this:

You can see that the opening stock is not assigned to the actual date, but posted to a
point in infinity (0CALDAY= 31.12.9999, for example).
After the three previous months have been uploaded and compressed, the InfoCube
content looks like this:

Note here that the marker value remains unchanged at 100 units. This can be achieved
using the No marker update indicator during compression (see section 3.2.2, step 6).
The marker is thus not changed.

After successively uploading deltas from January to March, of which only the first two are
compressed, the InfoCube content has the following appearance:

Compressing the requests for January and February executes a marker update that can
be seen by the marker now having the value 130 units. The values for March have not
been included in the marker yet.

The request in which the opening stock was loaded must always be compressed with a marker update

The request in which the historical material documents were contained must always be compressed without a marker update. This is necessary because the historical material movements are already contained in the opening stock.
Successive delta uploads must always be compressed with marker updates.

You only need to compress the request when you have loaded historical material movements. In this case, not compressing the requests for the opening balance and for the historical movements leads to false results in reporting. Compression is optional where no historical data has been transferred into the BW, though it is recommended for performance reasons.

Please consider OSS note 655798 for compression of stock InfoCubes.
 

 

4 comments:

  1. Amazing blog thanks for sharingRam

    ReplyDelete
  2. Thanks for sharing that valuable post. I really enjoy your post. I will be waiting for your another blog & Stock Audit
    Vendor Reconciliation
    | Visibility Audit

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Hi admin....it was so interesting to read & I feel thanks to you for posting such a good blog, keep updates regularly.. Continuous Monitoring
    Duplicate Payment
    Vendor Audit

    ReplyDelete