No Marker Update in InfoCube compression

Hi,
Please explain me how the No Marker Update works in InfoCube compression of inventory management.
Best Regards,
Ramesh

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.
Please go though the document:
How ToHandle Inventory Management Scenarios in BW
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328
Cheers
Pagudala

Similar Messages

Inventory Management (Advanced - Marker update)

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:
Solution A (the easy)
1. Compression on all request (with marker update)
Solution B (as suggested in the How-to-guide)
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 eitherHistorical Movements (2LIS_03_BF) or 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.

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

Inventory - No Marker update is set for delta loading, any impact ?

Dear all,
Since several days the daily delta on inventory cube is done with flag "no marker update set".
What are the possible issue ?
Do we have to reload the data or can we just set the flag as unchecked ?
Thanks for your help
Best regards
Christophe
Edited by: Christophe Courbot on Sep 15, 2011 5:04 PM

Hi,
Pl check below
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 set 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.
Relevant FAQs:
1) The marker isn't relevant when no data is transferred (e.g. during an delta init without data transfer).
2) The marker update is just like a check point (it will give the snapshot of the stock on a particular date when it is updated).
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)
Thanks and regards

Virtual Infoprovider AND No Marker Update

Hi BW Experts,
I am unable to get an idea when i am reading the following concepts.
1. NO MARKER UPDATE
2. HOW TO CREATE VIRTUAL INFOPROVIDER
Can anyone tell me with example.
I have read forums but i could not get the correct information.
Thanks in advance.
Regards
Anjali

hi anjali i am giving data on wat u asked.pls tell me where u have problem.so that i can clarify you more
InfoProvider
Use
InfoProviders that contain real-time InfoCubes provide the data basis for BI Integrated Planning. Aggregation levels are a type of virtual InfoProvider and are created on the basis of a real-time InfoCube, or a MultiProvider that contains InfoCubes of this type. Aggregation levels are specifically designed so that you can plan data manually or change it using planning functions.
For more information about the types of InfoProvider, see:
●     Real-Time InfoCubes
●     MultiProvider
Integration
In the Modeling functional area of the Data Warehousing Workbench, you create InfoProviders as the data basis for BI Integrated Planning.
For more information, see InfoProviders, Creating InfoCubes, and Creating MultiProviders.
In the Planning Modeler, you select the InfoProvider that you want to use as the data basis for BI Integrated Planning. On the Aggregation Levels tab page, you create one or more aggregation levels for this InfoProvider.
For more information, see Aggregation Levels.
Prerequisites
You have created a suitable InfoProvider as the data basis for BI Integrated Planning and filled it with data.
Features
InfoProvider Selection
You can restrict the number of InfoProviders displayed by specifying the technical name or description or by making an entry for last changed by.
You can change, check and save the selected InfoProviders.
InfoObjects
On the InfoObjects tab page, the system displays the InfoObjects that belong to the InfoProvider (see InfoObject). They are listed in the following tables:
●     Dimensions, with the characteristics assigned to them
●     Navigation Attributesfor the characteristics contained in the InfoProvider
●     Key figures
Under Settings, you can choose to display additional columns.
Characteristic Relationships and Data Slices
In change mode you can define the permitted combinations of characteristic values in the form of characteristic relationships and create data slices for the data that you want to protect for real-time-enabled InfoCubes.
For more information, see Characteristic Relationships and Data Slices.
Default Key Date for Planning
On the Settings tab page in change mode, you can set a Key Date as the default key date for planning. If time-dependent objects, such as attributes or hierarchies, are used in objects of the planning model, you can always refer to the default key date for planning. In this way, you can ensure that a uniform key date is used in the planning model. The objects in the planning model that are relevant for this are characteristic relationships, data slices and parameters of planning functions.
if we choose NO MARKER UPDATE option when compressing non cummulative cube the reference point is not updated but the requests are moved to Request 0
reward me if u felt theses are helpfull to u.
and if not reply me where u are not getting.
thanks
karthikeya

Compressions with No marker updates

Hi experts,
What is the purpose of compressing the request of 2lis_03_bx
with No marker update not set and compressing the request of
2lis_03_bf with No marker update set ?
Full points will be assigned.
V N.

Hi,
BX is a one time load used for initializing the stocks and BF and UM are run regularly as deltas. The marker updates are very important so as to give the correct stock values.
For more information check the thread below :
Delta for 2LIS_03_BX
Also please search the forums as these topics have been discussed in great detail.
Cheers,
Kedar

Non cumulative infocube compression

Hi All,
Presently we have a problem with Non cumulative infocube comression.
It is like: Presently Non Cumulative infocube contains 2 years of data and we are extracting data from two datasources (2LIS_03_BX AND 2LIS_03_BF) since 2years it has not been compressed.
Now we are going to do the comprresion
It is like : 2LIS_03_BX Init load compreesing with marker update (not selecting check box).
2LIS_03_BF init load copressing without marker update (selecting check box)
2LIS_03_BF delta load compressing with marker update(not selecting check box)
2LIS_03_BX delta upload compressing without marker update(selecting check box)
Here my doubt is in between delta loads there are some full uploads from 2LIS_03_BF datasource how can i copress this full uploads from 2LIS_03_BF req's?
Please help me it is quiet urget.
Thanx,
Niranjan.

Hi Nirajan,
First of all as I undestood 2LIS_03_BX is the initial upload of stocks, so there is no need of delta load for this datasource, it collects data from MARC, and MARD tables when running the stock setup in R3 and you ahve to load it just one time.
If between delta loads of 2LIS_03_BF you're loading full updates you are dupplicating material movements data, the idea of compression with marker update is that this movements affects to the stock value in the query, it's because of that when you load the delta init you do it without marker update because these movements are contained in the opening stock loaded with 2LIS_03_BX so you dont want to affect the stock calculation.
You can refer to the How to handle Inventory management scenarios in BW for more detail on the topic.
I hope this helps,
Regards,
Carlos.

Infocube Compression

Hi All,
Presently we have a problem with Non cumulative infocube comression.
It is like: Presently Non Cumulative infocube contains 2 years of data and we are extracting data from two datasources (2LIS_03_BX AND 2LIS_03_BF) since 2years it has not been compressed.
Now we are going to do the comprresion
It is like : 2LIS_03_BX Init load compreesing with marker update (not selecting check box).
2LIS_03_BF init load copressing without marker update (selecting check box)
2LIS_03_BF delta load compressing with marker update(not selecting check box)
2LIS_03_BX delta upload compressing without marker update(selecting check box)
Here my doubt is in between delta loads there are some full uploads from 2LIS_03_BF datasource how can i copress this full uploads from 2LIS_03_BF req's?
Please help me it is quiet urget.
Thanx,
Niranjan.

pamireddy,
The best way to see if it is okay is to check the aggregates... Especially since you are using non *** KF - check if rollup to aggregates is happening fine - the aggregates are automatically compressed , only thing is that there is no delta rollup for aggregates with Non *** KF.
If there are no aggregates - create one basis aggregate and roll it up and test - if it goes through fine and the query hits the aggregate and is behaving fine - then you can go ahead with compression of the base data.
Arun
Assign points if useful

Marker update or not.

hi xperts,
I am working on Inventory management Can any body give me idea which of the Following are correct
1.2lis_03_bx -- should be "No marker Update" is not set- is it right?
2.2lis_03_bf - should be "No marker Update" should be ticked- is it right?
3.2LIS_03_UM - should be "No marker Update"should be ticked- is it right?
I have to do this in the Compression screen of the manage infocube right?
Please confirm me,as i am not sure.

Hi,
1) correct
2) BF Delta init and BX is not used: then should be "No marker Update" should not be ticked.
BF Delta init and BX is used: then should be "No marker Update" should be ticked.
3) UM Delta init and BX is not used: then should be "No marker Update" should not be ticked.
UM Delta init and BX is used: then should be "No marker Update" should be ticked.
And also see :
Re: 2lis_03_bx not defined in source sys
With rgds,
Anil Kumar Sharma .P

Where can i find the option "no marker Update"

Hi ,
i want to know where this No marker update option is?
Thanks in advance
Ravi

hi ravi..
In the context menu of cube >Manage>Compression tab, u will find this check box.
It holds the non-cumulative value(like stock balance).
If you choose this option when compressing Non cumulative cube; the reference point is not updated but the request are moved to Request 0(usual compression); you must do this for compressing historical data; for example use this option to compress data before Jan 2005.
Marker updates do not summarize the data. In inventory management scenarios, we have to calculate opening stock and closing stock on a daily basis. In order to facilitate this, we set a marker which will add and subtract the values for each record.
In the absence of marker update, the data will be added up and will not provide the correct values.
Compression makes the stock calculation(updation) as on the last date for which the records uploaded.So it is nothing but doing calculation inadvance rather the making system to do this calculation at the time of query execution.
The same explained in the how to handle inventory in BIW in better way with example.
If we donot do this compression of delta loads, the result does not be wrong but system takes more than time to do forward and then backward calculation.
For non-cumulative InfoCubes, you can ensure that the non-cumulative marker is not updated by setting the indicator No Marker Updating. You have to use this option if you are loading historic non-cumulative value changes into an InfoCube after an initialization has already taken place with the current non-cumulative. Otherwise the results produced in the query will not be correct. For performance reasons, you should compress subsequent delta requests.
See:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/documents/a1-8-4/how%20to%20handle%20inventory%20management%20scenarios.pdf
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.
chk this thread too..
No marker update
hope it helps...

No Marker Updates

Hello,
Can any one plz tell me what is the correct sequence while dealing in Inventory Cube 0ic_c03
1. Load init request to Cube --> untick 'no marker update' check box fo BF & reverse for BX & UM --> Compress
'or'
2. Untick 'no marker update' check box fo BF & reverse for BX & UM -->Load init request to Cube --> Compress

Hi,
My 0IC_C03 is working fine but due to some requirement i have to create z infocube.
Now i have to load data from PSA to the zcube.
Yes you can do it, I also Copied ZCube from 0IC_C03. and created Update Rules exactly like 0IC_C03, I just copied.
Plz tell me what is the correct sequence to load & Compress data from PSA to Cube.
I will be loading data from PSA to zcube via scheduler
I don't think this is good solution, it is better to load for the both cubes from Init.
The sequence is BX,BF and UM only. Y
Thanks
Reddy

Ncum InfoCub compression very slow

subj
2lis_03_bx has loaded and compressed (30000 rows, with marker update) without any problems
2lis_03_bf/um has loaded, but compression (11 mln rows, without marker update) not ended (take very long time)
But some time, compression (bf/bx), is processed ok (after delete all data from infocube, and loading again (bx/bf/um)) (but not always)
ver. BW - 3.5 17 patchlevel
please help mi!

Hi,
Are you having large amount of records for compression ie data volume is huge in your cube.
Try to delete index,load data, compress infoocube and generate index for them.
Try to refresh stsatistics of cube once a week atleast.
Follow compression of data at regular intervals like weekly or daily.
If you go for a month large amount of data combined during which you can try compression of 5 to 10 . Sometimes comprressing larger number of request may result in dump due to temporary space unavailable
Hope this helps for you.
Thanks,
Arun
Edited by: Arunkumar Ramasamy on Oct 27, 2009 12:50 AM

Drawbacks of Infocube compression

Hi Experts,
is there any drawbacks of infocube compression??
Thanks
DV

Hi DV
During the upload of data, a full request will always be inserted into the F-fact table. Each request gets
its own request ID and partition (DB dependent), which is contained in the 'package' dimension. This
feature enables you, for example, to delete a request from the F-fact table after the upload. However,
this may result in several entries in the fact table with the same values for all characteristics except the
Best Practice: Periodic Jobs and Tasks in SAP BW
request ID. This will increase the size of the fact table and number of partitions (DB dependent)
unnecessarily and consequently decrease the performance of your queries. During compression,
these records are summarized to one entry with the request ID '0'.
Once the data has been
compressed, some functions are no longer available for this data (for example, it is not possible to
delete the data for a specific request ID).
Transactional InfoCubes in a BPS environment
You should compress your InfoCubes regularly, especially the transactional InfoCubes.
During compression, query has an impact if it hits its respective aggregate. As every time you finish compressing the aggregates are re-built.
With non-cumulative InfoCubes, compression has an additional effect on query performance. Also, the marker for non-cumulatives in non-cumulative InfoCubes is updated. This means that, on the whole, less data is read for a non-cumulative query, and the reply time is therefore reduced.
"If you are using an Oracle database as your BW database, you can also carry out a report using the relevant InfoCube in reporting while the compression is running. With other manufacturers databases, you will see a warning if you try to execute a query on an InfoCube while the compression is running. In this case you can execute the query once the compression has finished executing."
Hope this may help you
GTR

No Marker Update - 2LIS_03_BF

Hi
I have been having some issues with the Inventory management cube( using 2LIS_03_BF). The data in bw does not reconcile with SAP.
What I have realised is the following:
I have a process chain that loads the data every 3 hours and there is a step to compress the load with the field No Update Marker unchecked.
However the cube has the No Update Marker checked.
So which one would it use?
Could this be the cause of the issue?
Do I compress the delta loads ?
Thanks Again for your help.
Fahed

Dear Fahed,
It is suggested to compress the delta loads here as the incentory cube (0IC_C03) first calcultes forward (to marker then) comes back to the month where report is filtered.
You should check data period wise for locating point of incorrect keyfigure values.
Here are few points:
a) The request in which the opening stock was loaded must always be
compressed with a marker update
b) The request in which the historical material documents were contained
must always be compressed without a marker update and
c) Successive delta uploads must always be compressed with marker
updates.
For better understanding have a look at this document:
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328
Also see the OSS note 655798 for compression of stock's cube.

Use of Marker & No marker Update

Hi All,
I am going through the Inventory Management I want to know the use of Marker update and No marker update.
and also please let me know the below details.
1. First time when we will load the data we will compress the request with marker update and while loading BF&UM we will comopress with No marker Update.Could please brief me explain why we need to do and how it will
effects the data with marker and no marker.
Thanks & Regards
Ajay
"Points will be assigned"

Hi Ajay,
As you asked, Data Mismatch willn't be happened if you compress the cube with "No marker update".
to avoid mismath only we compress "no marker update"
Why mismacth?
Suppose you are taking the opening balance on 01 jan 2008 by using BX datasource.
You have business running for 1 year in R3(2007). There would be some movements happened in all storage locations.
Ex : Storage 1
Material M1 --> Received - 100 ; Issued 60; again Received 30
NOw the current stock available in storage 1 = 100-60+30 =70
When you load BX data source it takes value 70 for storage location 1. Then you compress the cube with "Marker update". SO marker sets a reference point to this 70.
Later when you load BF datasource for the past movements, you get these 3 transactions , i.e 100, 60 and 30. If you compress the cube with these movements againg one more 70 will go and add to the reference point. Because initial 70 has come by calculating these historical movements only.
But that is the wrong value. So to avoid this, we compress the cube with "No marker update".
Since these no marker compressed values are not added to reference point, So your Non Cumulative KF will take the result from that reference point.
Later you can delta movements, i.e from Jan 1 2008 to Feb 1 2008, those will be compressed with "Marker update", because these are new and should be added to reference point.
This is my longest thread ever written Ajay.
Thanks
Sreekanth.

With marker update.

hi gurus,
Can anybody give me a simple answer for this question?
I loaded the Historical Movements data with posting date Selection ,Now i want to compress the Data.(2LIS_03_BF)
Should i tick the "NO MARKER UPDATE" OR NOT ?.
THANKS IN ADVANCE.

Solved

No Marker Update in InfoCube compression

Similar Messages

Maybe you are looking for