Incomplete DataMarts in non-cumulative InfoCubes during extraction proccess

We want to transfer the stock's information from one infocube to other, we followed the OSS 375098 but we are still having some problems, we have 2 registries by plant,date,material as the result of the reference point in the source cube, now we're triying to transfer that information to the final cube, but when we transfer the data to the destination cube, some registries are not being transfered.
We dont known how to fix that problem, can u help us?

Check if you have any selection in the info packages for registry.
If you are in 3.5 , you have the option of copying the dtaa as a whole to another cube. Let me know if you need help.
Ravi Thothadri

Similar Messages

  • 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.

  • Incorrect results after compressing a non-cumulative InfoCube

    Hi Gurus,
    In BI 7.0 After compressing the non cumulative InfoCube its showing the incorrect reference points .leis_03_bf (pintail stock moments)  showing as the reference points(opening Balance) after compressing  as no marker update. Due to this its showing in correct result in reporting.please suggest me .
    Thanks
    Naveen

    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.

  • Unable to create Archiving for non-cumulative InfoCube

    Dear Gurus,
    I'm working with BI in SAP Nw 2004s with SAPKW70016 (Support Package 16) and need to create archiving on a non-cumulative Infocube (copy of 0RT_C36) but can't use tx RSDAP. Although I found note 1056294, which says that upon SP14 it can't be done the following message is sent:
    Cannot create data archiving process for ZRT_C36
    Message no. RSDA109
    Diagnosis
    You can only create a data archiving process for standard DataStore objects and standard InfoCubes. You cannot create a data archiving process for other InfoProviders such as VirtualProviders.
    In particular, non-cumulative InfoCubes and write-optimized DataStore objects are not currently supported.
    Please let me know what is wrong or how can I do this archiving in 2004s. I also read some documentation about RSDV transaction but couldn't find how to implement it using tx. RSDAP.
    Thanks in advanced.
    Best regards,
    Pilar Infantas.

    Please, any feedback about this issue???

  • BIA - Non-Cumulative InfoCubes

    Anyone have experience with the BIA and non-cumulative InfoCubes ? Is the validity table (L-table) of the InfoCube indexed making it more feasible to add more validity-determining characteristics to the cube ?

    Hi,
    BI accelerator ( BIA ) allows you to improve the performance of BI queries when data is read from only possible with InfoCubes that have cumulative key figures...
    Note provided by Marc is really nice............Anyways check this.....
    http://help.sap.com/saphelp_nw04s/helpdata/en/a8/48c0417951d117e10000000a155106/frameset.htm
    https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/11c4b71d-0a01-0010-5ca0-aadc2415b137#top
    Regards,
    Debjani.....

  • About non-cumulative InfoCubes

    Hello Gurus,
        what is non-cumulative InfoCubes?
    Many thanks.

    Hi,
    0IC_C03 is used for inventory cube(also called as inventory cube)
    normally inventory means both the stock inflow and outflow will be there that means some stock will come to the stock point the same day some stock move out from the godown that fro same object inflow outflow should maintain by using some code in updaterules(by using some indicators we will write the code).
    for example: in one stock point one material is there today s its quantiy is 20kg and today itself 100 kg purchasing and 50 kg selling that means the now avilable quantity is old quanti20 + newpurchase100 -selling50kg means finally 70kg balance.
    like that the non cumulative(it is not cumulating the all values)so it is working as non cumulative.
    like that one more example
    no of employs in ur copmany for the year 0f 2009
    if it is cumulative keyfigure
    if the employs are as below 2007--100no
    2008---150
    2009---75
    if u r using that directly no of employs u can get all(10015075=325) if u not restricting the year with number of employs.
    but in case of non cumulative it gives only 75 so it is correct.here we r using the year as ref in non cumulative keyfigure directly we r getting 75.
    Thanks & Regarda
    sathish
    Thank

  • Non-cumulative infocube in Infoset: Inventory

    Hi Experts,
    I have a requirement to combine a infocube and DSO under Infoset. But the Infocube is non cumulative and is not allowing to add in infoset.
    Any solutions for this?
    My Infocube is customised and have 3 datasources: 2LIS_03_BF, 2LIS_03_BX and 2LIS_03_UM
    And my DSO contains the alternate UOM with a single datasource: 0MAT_UNIT_ATTR
    My Ultimate aim is to bring the alternate UOM.
    Please post your suggestions.
    Thanks,
    Guru

    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.

  • Error when adding Non-Cumulative InfoCube to a Multi-Providers

    I want to include an InfoCube using non-cumulative key figures (0IC_C03) to a MultiProvider that includes other basic cubes.  Is this possible?  I thought I read that you could include one non-cumulative cube in a MultiProvider.  When I added 0IC_C03 to the MultiProvider I get the following error when activating: "Define the characteristics of the validity table for non-cumulatives."  The validity table is defined for 0IC_C03, do I need to do anything special in the multiprovider?  Any ideas on what I need to do?
    Thanks,
    Chris
    Edited by: Chris Robertson on Nov 18, 2008 4:52 PM

    Hi Chris,
    I am having the same issue. Did you manage to fix this?
    Thanks,
    Milind

  • Archiving and reload possible for non-cumulative infocube 0IC_C03 ?

    Hello,
        Can the cube 0IC_C03 be archived and reloaded into another cube so that the data can be accessed via a multiprovider ? I read in help (http://help.sap.com/saphelp_nw04/helpdata/en/8f/da1640dc88e769e10000000a155106/content.htm) that 'You cannot use the InfoCube together with another InfoCube with non-cumulative key figures in a MultiProvider'..
        While archiving seems doable, I have doubts on the reload. How do we report the data once it is archived from this cube.. Any ideas ?
    Thanks

    hi
    please check the below link.
    http://help.sap.com/saphelp_nw04s/helpdata/en/42/ead8d7b55e1bd2e10000000a11466f/frameset.htm
    Regards,
    madhu

  • Unable to compress non-cumulative infocube with 0DOC_NUM

    Hi Gurus!
    I'm working on a retail project. I've created an infocube based on 0RT_C01 to keep the stock movements. It is a non-cumulative cube.
    After the load of the initialization data (2lis_03_bx) ,historical movements, the initialization of 2lis_03_bf, the daily delta loads take about 10-11 hours to complete.This is because the cube has not been compressed due to the existence of infoobject 0DOC_NUM. 0DOC_NUM is of the lowest granularity and so compressing on 0DOC_NUM will not yield any performance benefits. But this has impacted the performance of daily delta loads. Also,the report that uses this cube take about 3-4 hours to open initially.Sometimes a timeout occurs.I've checked in ST22, ST21 and no errors or dumps appear.
    Is there anything I can check to speed up the process?
    Thanks!
    Lucia

    Hi,
    Compressing the request containing the opening stock that was uploaded. Make sure the "No marker update" indicator is not set. Please consider note 643687 ,before you carry out the compression of requests in stock Info Cubes!
    After successfully uploading the historical material movements, the associated request has to be compressed. You must make sure the "No marker update" indicator is set. This is necessary because the historical material movements are
    already contained in the opening stock.
    Regards,
    Suman

  • Aggregates on Non-cumulative InfoCubes, stock key figures, stock, stocks,

    Hi..Guru's
    Please let me know if  anybody has created aggregates on Non-Cumulative Cubes or key figure (i.e. 0IC_C03 Inventory Management.)
    I am facing the problem of performance related at the time of execution of query in 0IC_C03.( runtime dump )
    I have tried lot on to create aggregate by using proposal from query and other options. But its not working or using that aggr by query.
    Can somebody tell me about any sample aggr. which they are using on 0ic_c03.
    Or any tool to get better performance to execute query of the said cube.
    One more clarification req that what is Move the Marker pointer for stock calculation. I have compressed only two inital data loading req. should I compress the all req in cube (Regularly)
    If so there would be any option to get req compress automatically after successfully load in data target.
    We are using all three data sources 2lis_03_bx,bf & um for the same.
    Regards,
    Navin

    Hi,
    Definately the compression has lot of effect on the quey execution time for Inventory cubes <b>than</b> other cumulated cubes.
    So Do compression reqularly, once you feel that the deletion of request is not needed any more.
    And ,If the query do not has calday characterstic and need only month characterstic ,use Snap shot Info cube(which is mentioned and procedure is given in How to paper) and divert the month wise(and higher granularity on time characterstic ,like quarter & year) queries to this cube.
    And, the percentage of improvement in qury execution time in case of aggregates is less for non cumulated cubes when compared to other normal(cumulated) cubes. But still there is improvement in using aggregates.
    With rgds,
    Anil Kumar Sharma .P
    Message was edited by: Anil Kumar Sharma

  • Non cumulative infocube without BX

    Hi Experts,
    I need to compress and create aggregates for the inventory cube (Has Non cumulative in/out flow KFs)
    We do not use BX as all of the initial stock levels are defined using movements.  Does this change anything?
    Which way is it as I have seen both answers posted in this forum?
    BF-init: Compression without marker update
    BF-delta: Compression WITH marker update
    OR
    BF-init: Compression without marker update
    BF-delta: Compression WITHOUT marker update
    Thanks,
    Chris

    If you are not bringing BX, all BF should be compressed with marker update.

  • Non-Cumulative Infocube

    Hi All,
    What is non-cumulative cube,how it works and how it is differs from a normal cube?
    Thanks
    Regards
    Dheepa

    Hi,
    Please gothrough this link.
    Non-Cumulative keyfigure example
    Thanks & Regards
    Venkat

  • Non-Cumulative vs. Cumulative KeyFigures for Inventory Cube Implementation?

    A non-cumulative is a non-aggregating key figure on the level of one or more objects, which is always displayed in relation to time. Generally speaking, in SAP BI data modeling, there are two options for non-cumulative management. First option is to use non-cumulative management with non-cumulative key figures. Second option is to use non-cumulative management with normal key figures (cumulative key figures). For SAP inventory management, 0IC_C03 is a standard business content cube based upon the option of non-cumulative management with non-Cumulative key figures. Due to specific business requirements (this cube is designed primarily for detailed inventory balance reconciliation, we have to enhance 0IC_C03 to add additional characteristics such as Doc Number, Movement type and so on. The original estimated size of the cube is about 100 million records since we are extracting all history records from ECC (inception to date). We spent a lot of time to debate on if we should use non-cumulative key figures based upon the  standard business content of 0IC_C03 cube. We understand that, by using Non-Cumulative key figures, the fact table will be smaller (potentially). But, there are some disadvantages such as following:
    (1) We cannot use the InfoCube together with another InfoCube with non-cumulative key figures in a MultiProvider.
    (2) The query runtime can be affected by the calculation of the non-cumulative.
    (3) The InfoCube cannot logically partition by time characteristics (e.g. fiscal year) which makes it difficult for future archiving.
    (4) It is more difficult to maintain non-cumulative InfoCube since we have added more granularity (more characteristics) into the cube.
    Thus, we have decided not to use the Cumulative key figures. Instead, we are using cumulative key figures such as Receipt Stock Quantity (0RECTOTSTCK) ,  Issue Stock Quantity(0ISSTOTSTCK)
    , Receipt Valuated Stock Value (0RECVS_VAL) and Issue Valuated Stock Value (0ISSVS_VAL). All of those four key figures are available in the InfoCube and are calculated during the update process. Based upon the study of reporting requirements, those four key figures seems to be sufficient to meet all reporting requirements.
    In addition, since we have decided not to use cumulative key figures, we have removed non-cumulative key figures from the 0IC_C03 InfoCube and logically partitioned the cube by fiscal year. Furthermore, those InfoCube are fiscally partitioned by fiscal year/period as well.
    To a large extent, we are going away from the standard business content cube, and we have a pretty customized cube here. We'd like to use this opportunity to seek some guidance from SAP BI experts. Specifically, we want to understand what we are losing here by not using non-cumulative key figures as provided by original 0IC_C03  business content cube. Your honest suggestions and comment are greatly appreciated!

    Hello Marc,
    Thanks for the reply.
    I work for Dongxin, and would like to add couple of points to the original question...
    Based on the requirements, we decided to add Doc Number and Movement type along few other characteristics into the InfoCube (Custom InfoCube - article movements) as once we added these characteristics the Non Cumulative keyfigures even when the marker was properly set were not handling the stock values (balance) and the movements the right way causing data inconsistency issues.
    So, we are just using the Cumulative keyfigures and have decided to do the logical partitioning on fiscal year (as posting period is used to derive the time characteristics and compared to MC.1 makes more sense for comparison between ECC and BI.
    Also, I have gone through the How to manual for Inventory and in either case the reporting requirement is Inception to date (not just weekly or monthly snapshot).
    We would like to confirm if there would be any long term issues doing so.
    To optimize the performance we are planning to create aggregates at plant level.
    Couple of other points we took into consideration for using cumulative keyfigures are:
    1. Parallel processes possible if non-cumulative keyfigures are not used.
    2. Aggregates on fixed Plant possible if non-cumulative keyfigures are not used. (This being as all plants are not active and some of them are not reported).
    So, since we are not using the stock keyfigures (non cumulative) is it ok not to use 2LIS_03_BX as this is only to bring in the stock opening balance....
    We would like to know if there would be any issue only using BF and UM and using the InfoCube as the one to capture article movements along with cumulative keyfigures.
    Once again, thanks for your input on this issue.
    Thanks
    Dharma.

  • More than Non-cumulative cubes in one MultiProvider

    Hi There,
    I have got two non cumulative cubes and want to build a MultiProvider on them.
    Got information at couple of places on help.sap.com at one place it says MultiProvider can have more than one non-cumulative cubes at other place it says it can't. What is the right suggestion?
    Thanks
    Vikash

    Hi,
    From the performance perspective you should not use more than one Non Cumulative Infocube in a Multi Provider. If you user more than one the query will not execute parallel and execute in sequential which leads to delay in query run time.
    This is a recommendation from SAP not to use morethan one Non Cumulative Cubes in a MP.
    Cheers

Maybe you are looking for