Delivery Delta Records missing

Hi Friends !
We have missd the delta records for 4 days. Only way I know to run the setup table again & get all the records till date. Then schedule V3 jobs & next day onwards delta records will be pulled. Do we have any other way to get those missed records? Please advise.
With Regards
Rekha

Hi Rekha,
Please follow the below steps in R3 side
goto RSA3-->give DS name press enter
below you will get selection screen
give you delivery numbers as selections
then execute, if you get records here then definitely you should get records when you run the IP.
Hope this helps
Regards,
Venkatesh.

Similar Messages

  • Missing Delta Records for 2LIS_02_ITM & SCL

    Hi Experts,
    this is how my problem goes.
    i have done my set up table filled on 12th Dec 2010 and from that time onwards the delta were running everyday and filling the DSO and Cube.
    Accidently by some others PC in prod all my delta loads and the setup table load is being deleted except yesterday in PSA for these 2 extractors and now because of some change i have to do a full load to DSO.
    But as the PSA is emply and have only yesterday's request i have, deleted that one as well and done a Init Delta to it and i found out that only the Set up table is comming now and all the deltas in between are missing.
    i have tried a full LOAd to PSA and the result is same.
    How can i get those missing delta records from 12th Dec last year till today with out doing another set up table fill  or Do i have to have fill the set up table again till today and thats the only way? i will set the delta again after that.
    Do we have to have all the user locked for the setup table fill (for Queued Delta type) ? Lot of people says yes you have to and others says no you don't require. i got one white paper and it clearly says no user locking is required. please find the link below. what is the correct way?
    [http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d019f683-eac1-2b10-40a6-cfe48796a4ca?quicklink=index&overridelayout=true]

    Hi,
    As per my knowledge you want load particular period of data try repair request may issue solve.
    Regards
    Sivaraju

  • How to fill set up tables with out missing the delta records

    Hi,
    I would like fill set up tables in the productioon system of apllication of logistics.
    Can you please guide me how do we perform.?
    What are points to be considered?
    Because,when i start the filling  set up table by 10.AM if there are any posting at 10:05,10:06....like that
    how can collect them i.e will i miss any records in second delta run?What setps to be taken care?
    Thanks in advance
    Naresh.

    Hi.
    You can fill the set-up tables during normal operation hours ,if you load the data into ODS and the update queue is 'Queued delta' .Downtime is needed to avoid the duplicates .But if you use  'Direct delta' you miss the delta documents. Hence it is better to go for downtime approach for this case.
    Initially your delta records will be stored in the extraction queue and then when you run the collective job, records will be moved into delta queue. You can run the collective job (LBWE) anytime after the init run.If you need a daily delta ,then schedule this job before the delta loading. You can schedule this job either hrly or daily .This will move your records into delta queue. At the time of delta loading ,all your delta queue records will be moved into BW .
    Thanks.

  • How to reprocess delta records during subsequent update of data targets

    Hi,
    I have an ODS which sends in delta records to a cube above it. Now there is a data load, happening monthy from a flat file, which was successful upto the ODS, but failed in the cube due to one invalid record. How do I reprocess this data load after correction of the invalid records in the source flat file?
    The method I currently follow is to delete the failed request from the cube and then do a selective delete of records from the ODS and then reload the last data after correction.
    Is there a better way to just reprocess the last load from the flat file?
    Thanks & regards,
    Nikhil

    Hi Bhanu,
    Thanks for the response. I will explain a bit more in detail. Suppose there are 5 records coming in from the flat file - now 4 of those records are correct and one has invalid data.
    All 5 records get loaded to the ODS successfully but in the cube we have a function module which works on the data and aborts the entire data package if it finds even one invalid record. So nothing gets loaded into the cube at all.
    Now if we correct the one invalid record and then reload into the ODS - it will just send this corrected record over to the cube and we will miss out on the other 4 records which were originally correct since the ODS does not detect them as changed.
    If we delete the request from the ODS (rather than doing the selective delete) then it disables the delta in the ODS asnd we have to reinitialise everything - which we cannot afford to do in a production environment.
    Hope the problem is a bit more clear now.
    I was looking for some way to just resend all the five records - with the one corrected record to the cube without going through this selective delete process sinc eits too cumbersome and we run the risk of messing up with actual data ina  production environment.
    Thanks for the help,
    regards,
    Nikhil

  • Problem in getting Generic Delta records to BW

    Hi BW Gurus,
    I have got one issues with which I have been struggling a lot for several days . i.e
    I am extracting data from R/3 using Generic Extractor (View) from CATSCO and CATSDB. At the time of delta, I tried using Personal  No with Time Stamp giving Upper limit as 1800 seconds. I executed Infopackage in BW immediately. But it didn't work out. So plz guide me how I can get Delta Records to BW. Or should I do any  necessary factors apart from these in Generic Delta Screen (RSO2).
    It is very urgent.
    I will be thankful for solving this issue.

    Hey I am "Intros" again,,
    I am sorry man for giving the wrong T-code mistakenly in my last reply..
    To solve the proble...the whole process is same what I told u before..
    But... you got to go to T-Code :  BD87   , then execute the IDocs manually to bring them in to BW
    identify your IDocs which are missing in Monitor screen, then goto BD87 and select those IDocs and click execute... )you can search the IDoc's based on selection conditions)
    I hope this will help u...
    cheers man..
    ---Intros

  • Delivery date is missing in BW

    Hi All,
    Delivery date is missing in BW for few PO's.. I have checked all transformations and routines everything is fine.. in R/3 for same PO's delivery date exist but in BW for PO item in PO's delivery date is missing...  what  may the cause for this
    Data source: 2lis_02_itm and 2lis_02_scl
    Regards
    Sreekanth

    Did you check the data in RSA7 for the current delta and then in the PSA?
    Do you have the Delivery dates shows there?
    If yes, then there is something wrong while updating the dates in the further BW targets.
    In the other case, where in PSA itself the dates are not available, you'll have to check the R/3 side. Maybe the data source?
    Hope this helps.

  • "Error when reading ATP delta records"

    Hi,
    I have created Integration models for Location, Product, ATP Check, ATP Configuration, Stock and Sales Order.
    After creating IM's when I tried to run ATP on my Sales Order I'm getting  error " "Error when reading ATP delta records".
    Can anyone provide me why I'm facing this error.
    Thanks in Advance.
    Ram

    Dear Ram,
    For the product/locations you are checking, it appears that ATP objects in the liveCache are missing which normally are created automatically  when products and locations are created in APO.
    I would advise to recreate all needed products and locations.
    In APO, i.e. make again an initial data transfer of the master data from R/3. Previously the existing ones should be deleted to be sure that they will be created again. Then the problem should be solved. 
    If this does not help please check the the connection and LC settings to LDA and please try to restart the livecache. A potential explanation for the error would be an incorrectly maintained LDA connection to liveCache. Please check this by running transaction  /SAPAPO/OM13 and selecting the 'checks' section.                    
    The problem with the LDA connection could be e.g. very simple. If you check the table dbcon, which contains the description of the liveCache connections , if the liveCache names for LCA and LDA are different you should ensure, that the connections LCA and LDA are setup for the same liveCache (con_env in dbcon).                  
    I hope this helps.
    Regards,
    TIbor

  • Regarding Delta Record

    Hi,
    Is the delta record is capture for any field changes (Including KF, CHAR) for a particular sales/Delivery/Billing document or on changes of specific fields for sales/Delivery/Billing document.
    If delta capture for specific fields change then where (Tables) these fields are maintained and how to find out this.
    Points asssured....
    Thanks,
    Debasish

    I meant a ZFIELD added in VBRP (billing docs items) for instance... If you use a standard SD exit to populate this field, the change will be captured by the delta mechanism just before the system COMMITS the transaction (this particular billing document change)...
    Adding a ZFIELD in your extract structure will not suffice: suppose that you are adding a ZFIELD in your billing items extract structure; let's assume that your enhancement is populating this field with a simple lookup to VBRK (the header of a billing document).
    In few words you want to capture a change in you billdoc head and extract it with your billitm DSource.
    This won't work: if a user change the header of a billdoc, only 2LIS_13_VDHDR will capture a delta. 2LIS_13_VDITM won't get any delta record since no item has been changed... Note that enabling this feature would considerably "complexify"  the extraction in oddition to bring way much more records... indeed a before image reversal and an after image of the record (before and after COMMIT) would have to be extracted in order to avoid double records in BW....
    The above stuff should better be done in BW itself by staging your data with DSOs or even with modelling...
    hope this shed light...
    Olivier.

  • Mechanism to bring back delta records

    Hi,
    We have got all delta datasources, during last month-end, we found some delta records are missing. What could be the best approach to bring back those missed records. but those records are huge.
    What is the best solution? Is Re-initialization with out data transfer? or full load for those dates by undeleting the current requests after those dates?
    Thanks in Advance,
    Suman

    Hi ,
          You can delete the setup table and re-fill it , then If you know the document numbers of those records or creation date , etc , you can give those in the selection and load the repair full load for those missed records.
    If the V3 job is active then it will fill the delta queue with the recent data , so that the previous delta cannot be pulled.
    regards,
    karthik.

  • How SAP determines Delta records?

    Dear Experts,
    I have a standard extractor 2LIS_02_ITM. It works like this.
    1. when a sales order is saved, a customized program creates a new PO and updates a field in the PO using direct update, the abap 'update' command.
    2. in BI, this record created is loaded as delta.
    3. We notice that sometimes this when delta loaded, this field is blank and sometimes its not.
    A. We suspect the delta did not capture program-created PO if this field value is populated as blank by the program.
    B. If the program-created PO is opened and edited by user and then saved, SAP would generate a Delta record?
    If this delta is created and BI reloads delta, this delta would be loaded into BI and the report would show the field value.
    So, I need to check with experts here if using customized program to create a PO and update a field in it at the same time, would this be captured by the Delta mechanism?
    Normally, if manually created, the PO would, i assume, be captured in the delta queue. But what about using program?
    Please advise how delta is or can be affected by programs and how exactly is delta determined in this case. This standard extractor is set to use delta, i think using numeric field.
    So, I am not sure if its due to R/3 or BW. For BW, its a direct mapping of the updated field. So, I do not think there is an issue on BW side.
    regards
    Pascal

    Dear Debjani,
    On your reply to point 2 about the timing of LIS V3 update run, I like to seek clarification how the timing could cause the problem given that many delta records have successfully been loaded with existing way where a collection run is scheduled to run every around 15 minutes and is able to capture the delta except in some cases which is the problem? How can the field value change be missed due to this?   On your point 3 reply, the PO is created by program and it can be created by user.
    I still require some clarification . Hope you can kindly bear with me.
    1. For most of the delta records loaded into BI from R/3, there is no problem with the data. The program-created PO records can be loaded. But for some cases, even when this field is populated by program or EDI, after auto-creation of the PO. This delta is loaded into BI with this field being blank.
    2. This suggests to me, for most cases of the auto-PO creation, the BI Delta mechanism in R/3 is able to handle PO created by automated program in R/3.
    3. So, seems to me, regardless of how the PO is created : user created / by program / by EDI, the delta mechanism seems to work. So, I like to learn more how exactly can TIMING difference (asynchronous) between the creation of PO records and the LIS V3 update delta queue creation batch job have resulted in the field update from not being extracted into the delta queue ?
    Solutions (i think):
    1. Is it possible to Change the current delta queue update extraction method from periodic (every x minutes) V3 update batch run to the Direct / Unserialised V3 update  extraction method as mentioned by Arvind earlier? Would this mean every time PO is created by any means, even by program or field updated by EDI, the delta queue is immediately created to capture the change? This sounds like a solution?
    2. Have the auto-PO creation program Trigger an R/3 event to run the V3 update whenever it has completed an update or PO creation to generate the delta queue. Would this load the r/3 too much if run frequently? Or since frequent run would mean also less delta queue created which means shorter run time?
    Dear Sven,
    would it be good idea to use the program for ME22N to update the particular field After the PO is auto-created by the ME21N program? Would this mean, using these programs will assure that delta is captured?
    Best regards
    Pascal
    Edited by: Pascal Gabin on May 11, 2011 9:24 AM

  • Delta Records is not getting updated in delta queus when changes done

    Hi All,
    In Quality system , when a user makes a change to an order's ship-to address, the changes are "triggering" a delta record into the delta tables for BI to extract. This can be seen via tcode rsa3's delta tester.
    In Productionn System, when the user makes the exact same change, nothing is added to the delta table and the changes never come over to BI unless a full extract is request for the order.
    Why changes not getting updated, please give your inputs.
    Thanks & Regards,
    Venkat Vanarasi.

    Do you have your V3 update job active and running? THis job wites changes to the delta queue. Of course your datasource has to been initialized and a delta queue should be setup. You can check it in RSA7.
    Regards,
    Juergen

  • Impact of Delta Records on Key Figure Summation in DSO

    Hi experts,
    I have a key figure with aggregation type "summation" in a DSO. I would like to know the impact of delta records on the key figure.
    E.g.
    source DSO
    doc_id (key) | doc_pos | type | amount
    4711 | 1 | A | 100 USD
    4711 | 2 | B | 20 USD
    target DSO
    doc_id (key) | amount
    4711 | 120 USD
    If the first record is modified ("type" from A to C) as follows and delta-loaded to target DSO:
    4711 | 1 | C | 100 USD
    This will lead to incorrect amount:
    target DSO
    doc_id (key) | amount
    4711 | 220 USD
    How can I handle this situation?
    Thanks in advance.
    Regards,
    Meng

    Hi..
    I believe one document number and document Item will have only one type.
    Like 4711      1    should have only one type ( A / B / C).
    If the above assumption is true then just remove Doc Type from Key field of source DSO.
    Then From Source to Target Change Log table can handle this.
    Regards
    Anindya

  • Delta records not updating from DSO to CUBE in BI 7

    Hi Experts,
    Delta records not updating from DSO to CUBE
    in DSO keyfigure value showing '0' but in CUBE same record showing '-I '
    I cheked in Change log table in DSO its have 5 records
    ODSR_4LKIX7QHZX0VQB9IDR9MVQ65M -  -1
    ODSR_4LKIX7QHZX0VQB9IDR9MVQ65M -   0
    ODSR_4LIF02ZV32F1M85DXHUCSH0DL -   0
    ODSR_4LIF02ZV32F1M85DXHUCSH0DL -   1
    ODSR_4LH8CXKUJPW2JDS0LC775N4MH -   0
    but active data table have one record - 0
    how to corrcct the delta load??
    Regards,
    Jai

    Hi,
    I think initially the value was 0 (ODSR_4LH8CXKUJPW2JDS0LC775N4MH - 0, new image in changelog) and this got loaded to the cube.
    Then the value got changed to 1 (ODSR_4LIF02ZV32F1M85DXHUCSH0DL - 0, before image & ODSR_4LIF02ZV32F1M85DXHUCSH0DL - 1, after image). Now this record updates the cube with value 1. The cube has 2 records, one with 0 value and the other with 1.
    The value got changed again to 0 (ODSR_4LKIX7QHZX0VQB9IDR9MVQ65M - (-1), before image &
    ODSR_4LKIX7QHZX0VQB9IDR9MVQ65M - 0, after image). Now these records get aggregated and update the cube with (-1).
    The cube has 3 records, with 0, 1 and -1 values....the effective total is 0 which is correct.
    Is this not what you see in the cube? were the earlier req deleted from the cube?

  • Delta records are not loading from DSO to info cube

    My query is about delta loading from DSO to info cube. (Filter used in selection)
    Delta records are not loading from DSO to Info cube. I have tried all options available in DTP but no luck.
    Selected "Change log" and "Get one request only" and run the DTP, but 0 records got updated in info cube
    Selected "Change log" and "Get all new data request by request", but again 0 records got updated
    Selected "Change log" and "Only get the delta once", in that case all delta records loaded to info cube as it was in DSO and  gave error message "Lock Table Overflow" .
    When I run full load using same filter, data is loading from DSO to info cube.
    Can anyone please help me on this to get delta records from DSO to info cube?
    Thanks,
    Shamma

    Data is loading in case of full load with the same filter, so I don't think filter is an issue.
    When I follow below sequence, I get lock table overflow error;
    1. Full load with active table with or without archive
    2. Then with the same setting if I run init, the final status remains yellow and when I change the status to green manually, it gives lock table overflow error.
    When I chnage the settings of DTP to init run;
    1. Select change log and get only one request, and run the init, It is successfully completed with green status
    2. But when I run the same DTP for delta records, it does not load any data.
    Please help me to resolve this issue.

  • Delta Records not coming from sm13 to rsa7

    Hi,
    We have found that for the application 02, delta records are coming in RSA7(delta queue) even if these are coming in sm13.
    It appears that some protocol responsible for bringing the delta records from sm13 to rsa7 is failed.
    Fact is that for the data sources related to application 02 (purchasing: LO Cockpit), we did some enhancements through LBWE.
    But before transporting the relavant requests to production, we did not delete sm13 and rsa7 entries and also at the time of transpoting the requests in production, postings were made by several users and the entries for those were appearing in sm13.
    Thing to notice is that whatever fields were shifted in LBWE, those changes have successfully appeared in production after transporting ( LBWE and relavant Extract Structure in Production are containing the required changes)
    Now each time to load the data in BW, we have to delete and refill the set up tables and schedule full update which is taking a lot of time and not advisable.
    Each time when we are running job control in LBWE, it is throwing dump in ST22 with the heading CONNE_IMPORT_WRONG_STRUCTURE.
    It appears that some internal problem has occured in the structure of rsa7/sm13 for application 02.
    Also it is written in the dump that:--
    When attempting to import data, the structure of the complex object
    "MC02M_0ITM_TAB"
    was not compatible with the target object. The error occurred with
    component no. 24.
    Try to find out why the structure of the object is unsuitable.
    There are several possible reasons:
    |
    --- In the ABAP Dictionary, the structure of the imported
    |   object has changed. Make sure that the structure of the imported
    |   object matches that of the Dictionary structure.
    |
    |   If the data could not be restored from another source, this data
    |   must be read with the "old" structure, then converted and exported
    |   back with the new structure, so that future IMPORTs always work
    |   with the new structure.
    |
    --- A new program version is active, and it no longer matches the
        dataset. Try to solve the error by generating the program "SAPLMCEX" again
        as follows:
        In the SAP System, choose the transaction SE38. Enter the program
        name "SAPLMCEX". Then choose the "Activate" function.
    Now how to make the things back on track so that delta records come in rsa7 from sm13 so that we schedule delta update in info package.
    Is there any OSS Note or Standard SAP Report which we have to run for getting the solution.
    If not, please suggest the solution.
    Thanks in advance,
    Tarun Brijwani.

    Hi,
    1. Check whether your Extractor will support Early Delta Inti or not..
    See this link for  Early Delta Initia...
    http://help.sap.com/saphelp_nw04s/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/frameset.htm
    Minimize downtime for delta intia..
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5d51aa90-0201-0010-749e-d6b993c7a0d6
    Perform this activity on Weekends,
    Also see 436393 - Performance improvement for filling the setup tables
    Note 753654 - How can downtime be reduced for setup table update
    2. Obviously Background job.
    BG jobs can be monitored thru SM37 and maintain Logs thru SM21 and can be easier for administration
    Thanks

Maybe you are looking for