Scenarion of Delta Load problem in COPA Extraction

Please get me the solution for this particular scenario.
Let us suppose that i created the datasource some 1 year back and running the deltas successfully since then.
Let us number the requests from 1,2,3... and so on since 1st jan 2009. And let us suppose each request loads
some 1000 records everyday from ECC to BI.
Now on 10th august some change was made to ECC( such as change in the User Exit ) that caused the mismatch in number of data records ( loading only 950 records ) since the change was made on 10th August. But I identified the problem on 17th august with request number 160. Let us say those request numbers are 153(10th),154(11th),155(12th),156(13th),157(14th),158(15th),159(16th),160(17th). I fixed the program in ECC on 17th and further the requests from request number 160(17th) are fetching the correct number of data records. Now I need to delete the data in BI for request numbers 153 till 159 since they are not reconciling the data of ECC with BI. Now  we reload the deltas for such requests from ECC to BI. So how do I reload the deltas now in this scenario since ECC system keeps track of the last delta ie.. on 17th august(Req no 160). But how do I Load the deltas from req number 153 to 159 from ECC to BI.
One proposed solution to this problem was setting the timestamp of COPA to 10th august. But it is not advised to set the timestamp for COPA datasources using the KEB5 transaction in a production system.
Now in this scenario how do I load the request numbers 153 to 159 from ECC to Bi to fetch the correct data records for that period. Please propose a solution for this problem ASAP. U can also call me back whenever u need.
Thanks in advance

As stated in a previous post...
How you choose to do this can be summed up by the question: Does the target for this data have cumulative or non-cumulative Key Figures?
If you are doing an overwrite to the Key Figures, you could just execute a Full Repair InfoPackage that extracts the data for the days that you found inconsistencies instead of attempting to change the timestamp in KEB5 on the source ECC environment.
However, if you're target has cumulative Key Figures you're left with very few options (a couple of them are time-consuming):
1) Changing the timestamp in KEB5, if your plug-in is PI 2003.1 or older. Newer versions of the plug-in do not allow the changing of the timestamp as was pointed out by Ferruccio earlier.
2) Deleting the keys in the target InfoProvider for those records that you extract in a Full Repair extract.
3) Delete all data in BW for COPA and start from the beginning. This may be your best bet for cleaning up the issues in this scenario.

Similar Messages

  • Delta load issue in COPA

    Hi All
    We are using COPA datasources and daily delta loads will goingon from source system R/3 without any issues.
    last day the delta load from source system was failed due to some basis problem( non availability of WP) and we deleted that bad request in the DSO and then repeated the failed IP in the process chain,then the delta load was succesful but 0 records has been updated.
    So we are missing that delta records,I guess this is due to the time stamp set in the source system.
    In which table does this timestamp exists and what is the procedure inorder to solve this issue
    How do I need to solve this type of issues.
    Please let us know .,
    Regards
    Shankar

    Hi Shankar........
    I think u hav'nt make the QM status red.......when a delta load will fail............always make the the QM status red before repeating the load...........it will set back the QM status.........and when u will try to repeat the load.....system will ask for a repeat delta...........and a repeat delta will pick all the failed records along with the new records(if any).......
    I think u should do reinit............ie.......
    1)Delete the init flag
    2) Fill the set up table with selection.........did u know which values r missed........any selection criteria..like date.......
    3) Then do Full repair
    4) then delta....
    If u don't know the selection..............then u hav to load data for a selective range.........check ur DSO.....if the Update mode is Overwritten........then no probs.........otherwise there may be duplication of records.........then u hav to do selective deleteion........
    Hope this helps......
    Regards,
    Debjani..........

  • Delta load problem after Initialization

    Hi everyone.........................I need your inputs on the following problem that I ran into:
    I have an ODS which gets supplied by regular delta loads.
    Accidentlly, I have deleted the Initialization(Info Package->Scheduler->Initialization options for source systems). Because of this the delta loads are broken.
    I am now trying to fix this by Initializing it again(but without data transfer as I dont need all the data till this current point again). That worked successfully.
    But the deltas after this initialization are causing a problem. The first delta that I loaded failed with an error :
    "Delta Request REQU123XYZ is incorrect in the monitor.
    A repeat needs to be requested. Data target (ODS) still includes delta request REQU123XYZ. If the repeat is now loaded, then after the load there could be duplicate data in the data target.
    Request the repeat?"
    I repeat the delta load and this time around it loads correctly.
    The next delta that I load after this is again an error. The repeat of this is again a correct one.
    This problem continues.
    Can anyone throw some light on whats going wrong?
    Thanks.

    Hi Sat,
    I tried your suggestion by turning the failed request manually to green.
    However, for the next delta load, the info package just wouldnt allow me to initate a load saying that-
    "Last delta update is not yet completed             
    Therefore, no new delta update is possible.        
    You can start the request again                    
    if the last delta request is red or green in the monitor".
    Although it says not yet completed, I can see that the request has failed.
    Any more alternatives will be highly appreciated.
    Thanks.

  • Delta load problem in 2lis_04_p_comp

    Hi
    I am using data sources 2lis_04_p_comp and 2lis_04_p_matnr in my report. When I am doing full load , data is matching with R3 but  during delta load , 2lis_04_p_comp is showing incorrect data.
    WHEN I RUN THE DELTA REQUEST,FOR SAME ORDER NUMBER,WE GET MORE NUMBER OF RECORDS WITH THE EVENT VALUES PA,PB,PC,PD AND PF.
    sO AFTER RUNNING DELTA,THE OUTPUT GI QUANTITY and GI Value  FROM THE REPORT DOES NOT TALLY WITH THE R/3 DATA.
    I am using cube 0pp_c05 where these GI quantities  and GI Value add up giving wrong result
    Please help
    Regards
    Megha

    Hi All,
    For setup table filling for PP datasources having some sequence to follow. You can see in the note 585960. The workaround given by SAP is to deactivate the MATNR data source and fill the tables and then activate and fill the MATNR stuff.
    There are some local issues regarding this activation and deactivation things, because it needs lot of permissions and procedures.
    Please go as per the note procedure.
    Assign points if helful.
    Regards
    Amit

  • Delta Load problem

    Hi,
    I have one question regarding the deltas. we have one ODS it consist of materail number text and some other fields. The thing is we are doing the full loads. And the data is pulling by  the 3rd party tool from the BW by accessing directly the ODS active table. Now the question is how can we implement the deltas for this and how they can identify the new records or changed records.
    Thanks,
    Dru

    Hi Druthi,
    since ur loads are full loads, and from now u want to make it into delta loads.
    it can be possible by doing init again without data transfer.
    and if u didnt reinit ur ODS it will overwrite with ur new records, so better init again ur ODS.
    And to find whether ur records are new records or changed records, here are the steps.
    1. right click on ur ODS -> select manage
    2. select contents tab -> and in the below select "change log" button.
    3. u will find mode of ur records whether it is new or changed, and this is possible if ur using 0RECORDMODE info object in ur ODS.
    Thanks,
    Sai Chand.

  • 0BPARTNER  delta load problem

    Hi All,
    For 0BPARTNETR master data  , its a delta load and infopackage is showing red but request inside the Data Target is green with 0 added records. But some times it picks the delta figures and sometimes it will show 0 added records . Please assist me regarding this .
    Regards,
    Aditya

    When there are no changes in the master records in R/3 then 0 records will come in delta..
    if only records are created or modified then only it will pull delta..records.
    Now when request is red you can make its status red manually i.e status not okay and then run repeat delta and check if load is happening...
    in infopackage settings..we sometimes put the status preference green or yellow if its stuck for long time...you can check this out ...go to infopackage menu bar and left top corner you can see those options..
    Regards
    RK

  • Inventory delta load problem

    Hi,
         We are facing inventory data load getting below error, Main problem is they got below error in PSA level from 16th june still they changed red icon into green and loaded to incube and compressed. when running process chain they getting same error daily.
    Error:
    Caller 09 contain an error message
    Problem:
    -> Data flow PSA->IC, 20th request (it look like have 16th to 20th data)  they have changed PSA red request into green and loaded to cube and compressed.
    21th request (it look like have 16th to 21th data)  they have changed PSA red request into green and loaded to cube and compressed.
    Kindly guide me what solution we can give.
    thanks

    I suggest that you handle this with utmost care. Since it does not look like you have the DSO in the dataflow, recovering the data would be impossible if the cube data is corrupted.
    Need to understand the details to be able to give a proper solution.
    You can consider request reverse posting option which will post reverse images of the PSA requests under the scope and nullify the value from the cube. Please try this in Dev and quality system, before trying this in Production.
    Else, you can create a custom datasource based on this PSA table and reverse the values in the transformation.
    If you could identify the documents, created after this delta corruption, you could set them up in source and do a repair full upload.
    Please let me know whether it helps.

  • Delta load problem from ODS

    Hello everyone here.........,
    I have a problem loading frm ODS to another target with delta.
    Actually to ODS i am loading from two datasources. Both are full loads. Full1 and Full2. When i am trying to load from ODS to another target with delta..., it takes only Full1 data not Full2. So for loading Full2 now i am loading manually.
    so why this happend here. Please let me know how to do
    for making full2 also automatically........,
    swetha

    yes u r correct. after full1 loaded into ODS, its activating the ODS. these two can done through process chain. For full2 load we are loading manually. and doing manual activation.
    lets take small example here that for yesterdays full1 & activation has done successfully. and after that i am loading
    full2 manually & activated. and again today process chain ran, it loads full1 & activated ODS. Now what i am thinking is does this further datamart load which is run in process chain picks only full1 load and it doesn't pick full2 load which is already loaded & activated successfully.
    I think u will get what i suppose to ask you now...,
    clear my confusion here please......
    swetha

  • CRM 5.0 to R/3 BP Initial & Delta load problems

    Hi Experts,
    I am having problems trying to replicate a BP to R/3 (ECC). The BDOC status is all green and it shows 'Processed'...but my BP is not created in the OLTP side!!I have followed all the steps from the best practice document - CRM is the lead system and i have created a dedicated account grp with ext. nos range in OLTP.
    I am using BUPA_MAIN in R3AC1 as the load object with a filter setting for a single BP..In the sender i am using CRM and the receiver as OLTP...Am i missing something?? There is no error and so i do not know what to debug in the outbound scheduler...please advice (FYI - OLTP to CRM BP replication works fine)

    Hi Paul,
    If you need to work with just 1 or say a handful of BP, why dont you use synchronisation load instead of initial load.
    Goto transation R3AR2. (Define request)
    create new entry
    Give request name - say Z_BUPA_TEST
    Adapter object - BUPA_MAIN
    Click on request detail:
    Again click on new entries:
    table name - BUT000
    fieldname - PARTNER
    Incl/Ex - I
    Option - EQ
    LOW - your BP number (with leading spaces)
    Save this request.
    goto R3AR4 to execute this request.
    Enter request name(Z_BUPA_TEST) and source and destination systems. execute.
    To monitor this data transfer, goto transaction R3AR3.
    PLease let me know if this helps.
    Regards
    Kaushal

  • Delta load problem in process chain

    Hi,
    I have ODS givng data to another ODS. The init of this flow was done manually...Now i have created process chain in which further processing has variant as "execute infopackage" as the delta package made .. now when i check this process chain its giving me error ""Delete init. request
    REQU_49LKNGG0SE5966D3S7SQYYDQX before running
    init. again with same selection"" .. Actually this is not the Init req which i ran manually..this is the req which was run when i ran this process chain... what shld i do to add only delta IP in process chain so that i dnt ve to delete init
    Thanks
    Prashant

    hi,
    first load all the init loads from the ods to cube. then u have to create the delta infopack and include that in the chain.
    create the int info pack under the infosource 8<ods name>
    trigger that infopack, create the delta infopack under the 8<odsname> infosource , and you have include that in the PC.
    Please do changes in your process chain.
    Local chain 1 - start -> load to ods -> activation of ods ->further processing(remove the infopack in this process maintain variant).
    Lcoal chain 2 - start -> delete index ->load delta to cube -> create index -> roll up (if needed)
    Main chain -> start -> local chain 1 ->local chain2
    Ramesh

  • Pseudo delta load problem

    Hi all
    I have schedule a pseudo delta for HR Training, input for the package is as 01.08.2008 to 30.08.2008 but if my package does not have any record for that month then it will not delete my request for the month so I have 30 request in the cube. If I get a single record then it delete all request of that month
    So pl. guide me how I can overcome this situation , so even if there is no record for entire month it should delete my previous request.
    Thanks in advance
    Charudatta

    Hi Kotha123:
       Take a look at SAP Notes below.
    745445 - "CRM-BW: Incorrect partners extracted in the delta".
    1178613 - "CRMBW Sales: Created date differs in delta from init upload".
    987142 - "CRM BW:Incorrect data from data source 0CRM_QUOTATION_I".
    793986 - "Extractor:Status fields not filled in parallel processing".
    Regards,
    Francisco Milán.

  • Generic Extraction Delta Loads

    Hi Experts,
    I am facing problem is I want to extract the data in Generic Extraction in View, Suppose my requirement is I want to delta loads every 1 hour per day, how can i do, Generic Extraction possible are not delta records.
    Note:- LO Extraction is possible like we have update mode we can scheduled hours in everyday, But Generice Extraction possible are not.
    Please provide me solutions ASAP.
    Thanks in Advance......
    Regards,
    Bharathi.

    There are various delta method
    1.calday.
    2.time stamp.
    3.Numeric pointer.
    For youe requirement Time stamp will work.
    Please check weather you have any field related to time.
    Thanks,
    Saveen kumar

  • Delta  reocrds are not getting extracted . Problem with delta Quaue

    Hello friends .
    Could you please help me in this scenario ?
    It’s related to delta load from application 12 ,  - 2LIS_12_VCITM.
    Some how data is not getting transferred from LBWQ to RSA7 . There are more than 200000 entries in LBWQ , but the job is not able to transfer any entries to RSA7.
    For rest other application , data is going correctly .
    The job status showing is correct , like XXXXX LUW are transferred … there is no error in Job log , it technically correct .
    I have found one notes , in SAP service market place , but still it doesn’t match with my job status . My job status is NOTESID  ..where as per the notes it should WKEDPI*** ( something like this ) .
    I have taken below steps to solve this problem but still it doesn’t work .
    1.     Removed job from schedule ( the job for LBWQ to RSA7 ) and Executed the job manually .
    2.     Executed Program RMSBW12.
    3.     Deleted the Delta Q from RSA for application 12 and regenerated the same once again by running the infopackage , early delta initialization with out data transfer , . Once Delta Q is generated , run the job once again .
    I hope , I tried with all correct way ..but still I could not able to transfer the data .
    But with all above steps , still data is not transferred . Daily infopackage is running as per the schedule , and bringing only 0 record . If it still doesn’t work then I have to do Re-initilization .  and this is big cost for us . as we have to lock the sys for users and so on .
    Could you please give me some tips , that how can I transferr the data from LBWQ to delta Q ( RSA7) . If it works then definitely , I will save my lot of time .
    Please suggest me , how can I proceed . Please save me from this situation.
    Many many thanks in advance.
    Regards,

    Hi Akshay,
    Go to SMQ1 and check MCEX12 Queue. If your delta records are piling up in SMQ1 and not being transfered to RSA7, you need to check your back gound job control option once again.
    The back ground collector job will collect the recrords from SMQ1 and push to RSA7.
    Try to execute RMBWV312 program in SE38 and manully push all the recrods to RSA7. Once all the records are available in RSA7 you will find the MCEX12 queue will be cleared in SMQ1.
    Cheers
    Praveen

  • Problem in delta load with Z field

    Hello Experts,
    We have CRM 5.0 system and as per the requirement we have
    added ZFIELD to BUT000 table. This field is added to BUT000 via EEWB – Easy
    Enhancement Workbench. This field is also BW enabled.
    BW enabled means – this field is used / available to BW
    extractor for further analysis.
    We update this ZFIELD with custom program – FM BUPA_CENTRAL_CI_CHANGE.
    When full load is done – data flows to BW correctly, ZFIELD
    values are reflecting correctly. But when we are doing delta load it is not
    working.
    If we use BP t-code delta works perfectly. So issue from BW
    side is ruled out. The FM BUPA_CENTRAL_CI_CHANGE is not triggering the change
    record for this BP. But then I don’t see any other FM / BAPI to use so that
    change record is also created.
    Could you please provide any pointers or any checks to
    overcome this problem?
    Thanks in advance.

    Hi Ashtankar,
    When you are changing the attributes(say ZFIELD) and save the transaction in BP, Is this updating the CHDAT(Change date) in BUT000?
    If the change date is being applied, then Delta shouldnt be a problem - if you are using datasource 0BPARTNER_ATTR.
    In order to check if the delta is being captured or not, you could use TCODE RSA7. Also, this brings the Doubt when you say Full load works while delta doesnt, try Re-initializing the datasource from BW after Datasource replication - because there have been some changes effective in Source system which the BW system/Delta queue might take into consideration.
    Regards,
    Thejas K

  • Problem with delta load urgent!!

    Hi,
    I have a problem with delta load
    We have an IP, which loads data from R/3 system daily, its a delta load to the ODS and it updates to the cube with the selection on Company Codes and 0FISCPER
    we are in 3.5 system
    For a couple of company codes A & B, the init was done for the period 07.2010 to 12.2099 and after tht the deltas are loaded from 07.2010 till 12.2099 and there's no pblm with tht
    Now, there was some updation in R/3 system and the data was maintained for the company codes in A& B for the FISCPER 001.2010 to 006.2010, for which init wasnt maintained...
    now how shall we need to load the init in this case? dnt ask me how the postings was done in R/3, but my pblm is purely related to the loading data in BW from R/3, as its very imp for the customer to see the data from 01.2010 to 12.2010 in reports, but the data was only available in reports from 07.2010 onwards
    do i need to create another IP and maintain the init for 01.2010 to 06.2010? so tht this selection will automatically appear in the ODS delta loading infopackage
    pls throw ur inputs ASAP
    thank you

    Hi Prince,
    No need to maintain any Init for this data, It will be enough if you can load the data from jan 2010 to jun 2010 into your Info Cube.
    Follow the below steps:
    1)create full load IP for this data source.
    2) give the selection as A and B company codes and 0FISCPER as 001.2010 to 006.2010
    3) in menu bar, click on scheduler --> select full repair request
    4) In the next screen check the check box and save
    5) Now execute the IP, it will the data with out disturbing your daily delta.
    follow the same procedure to load data till to your Info Cube.
    Please revert if you have any questions
    Regards,
    Venkatesh

Maybe you are looking for