How SAP determines Delta records?

[Former Member]

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

[sven_mader2 · Accepted solution]

Hi,

> updates a field in the PO using direct update, the abap 'update' command.

Don't use INSERT or UPDATE in your Z programs. So, you don't get a delta for your BW.

When you use a LO datasource, then

-> a SAP program is included in the SAP transaction to create the delta.

-> You have to use the SAP transation (ME22N?) for changing the PO.

Sven

[dielom]

Hi Pascal,

Logistic extractors work in a different way from the rest. The data is first loaded into an ERP delta queue (table). This queue can be populated at the time of saving a document (PO in your case), or by scheduling a job to run every x number of minutes. If you check transaction LBWE, you will be able to see which method is your company using.

If you were using direct delta (queue populated at the time of saving), then you will have a problem with the method you are updating this field. At the moment of saving, the field will be blank. then you do a direct update to the DB table (not really reccommended), this update DOES NOT trigger a delta, since it's not using the SAP events to trigger a delta. That is why if you then update the PO, even if its' another field, you do get your field populated. The reason why you sometimes may get it and sometimes not is because there might be a timing difference every time, since both processes (update delta queue and update PO with custom program) are triggered asynchronously after posting PO so one would finish before the other.

So, in my opinion, is nothing to do with BW, is an ERP issue. But it's difficult to be sure without being able to see the system.

Hope this makes sense.

Cheers,

Diego

[Former Member]

Dear Diego,

May i know what method of delta would be recommended for this situation? I am not sure what delta options are possible.

When the SO is saved, it calls a program to create PO. I think there is a commit to database before the same program does a direct update to the db table to update the field. So, the PO could have some value in the field at 1st creation by the program. Immediately next, the program uses update command to update the field based on a certain business rule.

I am thinking of this solution but does not have enough experience to say if it will work:

1. continue the same update methods.

2. In BI, when there is a delta load for this data, trigger an SAP R/3 event (using RFC call from BI to R/3?) to run the LIS batch job to generate the Delta. But when this delta is generated, would it accurately reflect the delta? Currently the delta batch job in R/3 is running every 30 minutes.

3. Another option i can think of is to trigger SAP event to run the same batch job in R/3 everytime such a SO is created or when the PO creation program is run.

Thanks for your comments. Its been very helpful.

regards

Pascal

[Former Member]

hi,

in your ECC system different extraction methods are used by Standard extractors in LBWE and the extraction method determines which data to be sent to BW as delta.

For Standard extractors in LBWE there are three possible methods of extraction:

Direct method: In this method as soon as the documents are posted the extraction data is sent to BW delta queue (RSA7) , in this method you may miss some data as explained above.

Queued delta : When documents are posted it saves the data in extraction queue and from extraction queue (LBWQ) it is extracted to BW delta queue (RSA7) using the collection run.

Unserialized V3 update: When documents are posted it writes to update table and from there it is processed to delta queue using collection run.

you can check which update type is being used by your standard extractor and can try to use queued delta for delta management.

regards,

Arvind.

[Former Member]

Hi Pascal,

Datasource : 2LIS_02_ITM is a standard datasource and in this case the Delta Process is ABR.....i.e. After, before and reverse all the three images will be sed to the BW side.....

But since it is a standard datasource there should not be any problem with the Delta peocess....

You have mentioned here that the PO number is getting updated throuf=gh a program....

So I think the problem is with the timing....

Check the Start time and the End time of the Job which is generating the PO number in the R/3 side....

This Job should get completed before you starting of the Batch Job....This datasource is using Queued delta method.....

The extraction data from the concerned application is collected in an Extraction Queue.

Then the data will be transferred to Delta queue, in a similar manner to the V3 update, with an update

collection run. .....

So before the V3 update the Job which is updating the PO number should get completed....

You can prepond the timing.....I think then your issue will get resolved..

Regards,

Debjani......

[Former Member]

Dear Sven, if not using the 2 commands in the program, what command may you recommended? And yes , you are spot-on, its using ME22N in the program.

Hello Debjani, yes you are right. Its using ABR delta process.

I think I am beginning to see the problem and answer.

Please bear with me by confirming the following:

1. after the program creates the PO and updated the field, any subsequent ways of updating the field , eg. user changes it manually or someone runs a program to update the field directly, the standard extractor delta mechanism will be able to handle all these changes.

2. So, the way to solve this is timing of the LIS* batch job run to coincide with the BI load?

3. Kindly could you elaborate on your last statement?

Wish you a very nice day.

sincerely

Pascal

[Former Member]

Hi Pascal,

Kindly find the answers below :

1. after the program creates the PO and updated the field, any subsequent ways of updating the field , eg. user changes it manually or someone runs a program to update the field directly, the standard extractor delta mechanism will be able to handle all these changes.

Yes, whether user doing it manually or the PO number is getting generated through a program....in both the cases the R/3 table is getting updated.....delta will work if and only if the updation in R/3 table is done before the xecution of the V3 job..

2. So, the way to solve this is timing of the LIS* batch job run to coincide with the BI load?

Yes.

3. Kindly could you elaborate on your last statement?

Once all the required business data have been filled (including the PO number) and Save button is clicked , success message will be displayed at the status bar on successful creation of PO.

Simultaneously a new record is written for an application (02) in the Extraction queue.

On successful completion (Save), the successful Save message in the status bar, the document posting in application table as well as a record in extraction queue is written at the same time.

Once u201CV3 Collective run jobu201D runs for an application02, all the records for the application 02 will be moved from the Extraction queue to the Delta queue.

So the fact is that, after updation of the Application table (R/3 table) and Ectraction queue (both will be done simultaneously).......the V3 job should get executed to updated the properr record in the delta queue...

Regards,

Debjani..

[Former Member]

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