cancel
Showing results for 
Search instead for 
Did you mean: 

2LIS_11_VAITM not triggering delta

Former Member
0 Kudos

Hello All,

I am facing issues with extractor 2LIS_11_VAITM. It is not triggering delta when I expect it to be.

If someone goes into an existing sales order, using VA02, and changes the "First Date" (VBEP-EDATU) on Sales Order Item and click on save button(without changing anything else), changed on date in VBAP table is being updated but delta is not being triggered. As the "Changed On" date is being modified on table VBAP, I would expect a delta to be triggered.

Can anybody explain what could be wrong?

Regards,

David.

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

hi,

sorry overlooked one imp thing earlier.

The LIS extractor 2LIS_11_VAITM is based on table (header & item) VBAK,VBAP,VBKD,VBUK,VBUP.

Any changes to the schdule line item won't generate delta for this extractor.

If someone goes into an existing sales order, using VA02, and changes the "First Date" (VBEP-EDATU) on Sales Order Item and click on save button(without changing anything else),

This activity would generate delta for 2LIS_11_VASCL. VBEP is schedule line table.

Its not an issue, you are looking at the wrong extractor.

regards,

Arvind.

Edited by: Arvind Tekra on May 27, 2011 2:16 PM

Former Member
0 Kudos

Hi Arvind,

I completely agree with you that a change to VBEP-EDATU should trigger a delta for Schdule Lines extractor. However, my point is...VBAP-AEDAT is changed when someone saves the order using VA02. This means it is a change to VBAP table and AEDAT is in the standard extractor, 2LIS_11_VAITM. Should that not trigger a delta for 2LIS_11_VAITM?

Regards,

David.

Former Member
0 Kudos

hi David,

Completely agree with you, you should raise an OSS note with SAP.

regards,

Arvind.

Former Member
0 Kudos

Hi Arvind,

Thanks for the suggestion. I do feel the same. I am currently looking/searching for SAP Notes to see if there is anything relevant to the problem. Couldn't find any so far. I will keep this question open, meanwhile, incase someone else might reply who might have faced the same issue.

I would appreciate any further pointers.

Regards,

David.

Former Member
0 Kudos

Hi,

Well some pointers:

1 - Check if the BTEs are linked to BW. That is to say that in tcode BF11, the BW should be active (Check box checked).

This will ensure that the event of any sales document change triggers delta records and saves it into the extraction queue.

2 - The datasource should be active.

3 - The delta update 'queued delta' should be enabled(green) in LBWE transaction.

4 - One more point to remember - If only dates or header information is changed, the delta will be triggered for header datasource only not item. Therefore header datasource should be activated and update mode in LBWE for that transaction should be active.

Please let us know if all the points above are checked.

Debanshu

Former Member
0 Kudos

Hi Debanshu,

I am sorry but what do you mean by "If only dates or header information is changed, the delta will be triggered for header datasource only not item."

Do you mean that even though the changed on date (AEDAT) in VBAP table is changed, there would be no delta triggered on Item extractor (2LIS_11_VAITM)?

Regards,

David.

Former Member
0 Kudos

Hi David,

Iu2019m assuming that you ran v3 update job to push data to delta queue. AEDAT is a SAP given field into 2LIS_11_VAITM and once VBAP update it should work. Before opening a OSS message, you should look into CDHDR and CDPOS table to see it showing with before and after values for AEDAT.

Good luck.

Mohan

Former Member
0 Kudos

Hi Mohan,

I did check CDHDR and CDPOS tables and surprisingly there are no entries logged for VBAP-AEDAT changes for the scenario I explained above. I am baffled. I am left with no other optino but to contact SAP unless I am missing something.

Rgds,

David.

Former Member
0 Kudos

No entries in CDHDR and CDPOS indicates that delta was not invoked when the transaction committed through transaction. So you may want to include this comment in your OSS message to identify root cause.

Good luck,

Mohan

Former Member
0 Kudos

David,

Did you get any solution for this from SAP. We are facing a similar issue where VBAK-AEDAT and VBAP-AEDAT are getting changed when they populate a Z field on VBAK through standard BAPI but its not trigerring a BW delta.

Thanks,

K

Former Member
0 Kudos

Hi Kanchana,

I am not sure if you are still looking for answer but yes, we did receive a reply from SAP confirming that the change alone to the changed on date will not trigger a delta. To get the delta triggered there must be a change to other fields as well. We ended up enhancing MCVBAP to add the field and populate it through user exit. Hope it helps.

- David.

Former Member
0 Kudos

Hi David,

Sorry. Ignore this post.. Just read your last message..

Thanks,

Sathish

Edited by: Sathish K Dharmaraj on Feb 27, 2012 8:54 AM

former_member293102
Participant
0 Kudos

Hi David,

We have the same issue.

Thanks for posting your solution. One clarification required, you mentioned, "We ended up enhancing MCVBAP to add the field and populate it through user exit. ". Which field you are talking about here ? VBAP-AEDAT as ZZAEDAT in datasource ??

If my assumption is rite :

So if we enhance ZZAEDAT does it trigger delta ? will it bring other field which have changed as well ?


PS :

We also have similar case. Even if one schedule changes, it affects VBAP-AEDAT for all lines of VBAP table with that VBEP date.

Your response would be much much appreciated.

Regards,

mihir

Former Member
0 Kudos

Check if your V3 update job is active.

Do you have the records in LBWQ?

May be you can try running the program RMBWV311.

This will push the records from LBWQ to the Delta Queue.

Former Member
0 Kudos

Hi Vishal,

Issue is that there is no trigger of delta itself. I have done all the stpes mentioned by you but no use.

Regards,

David.

Former Member
0 Kudos

hi,

You can refer to SAP note 1146001.

Not sure how much relevant it might be to you. But still you can check this.

regards,

Arvind.

Former Member
0 Kudos

Hi Arvind,

Thanks for the pointer. However, it doesn't seem to be any useful.

Regards,

David.