From previous entry, we know when AND where the VEPVG table got inserted and then deleted. But the big question is "Why the record got deleted?". Well, I am going to tell you here that I finally found the cause of it, underlying cause to be put in here correctly.
In order to understand how does VA02 (Change Order) screen goes to that point of DELETE a record from VEPVG, I will let you see the traces of coding which I pinpoint below. You should take into consideration of analyzing how the SAP core code flowing through VA02 (PAI) after you click the "SAVE" button.
1. When you click "SAVE", it goes thru the following :
Line 1. SAPLV45U -> LV45UFOR -> RV_SALES_DOCUMENT_UPD -> RV_SALES_DOCUMENT_INDEX_UPDAT.
Line 2. SAPLV05I -> LV05IFIX -> INDICES_SCHREIBEN -> INDICES_AUFBAUEN
Line 3. SAPLV05I -> LV05IFEP -> EP_01 -> LV05IF0V -> INDEX_VEPVG_AUFBAUEN
Line 4. SAPLV05I -> LV05IFIX -> INDICES_SCHREIBEN -> INDEX_VEPVG_SCHREIBEN
2. What does each of line of traces means to you :
The first three lines indicates your primary entry to getting your code prepare to update Indices. Yes, there are many other indices tables like VAKMA, VAPMA, VEPVG and others. VEPVG is one of the important ones related to this issue (my entry).
Pay particular attention to line 2 and 3,
- SAPLV05I -> LV05IFIX -> INDICES_SCHREIBEN -> INDICES_AUFBAUEN
This line interprets how the system will fill YVEPVG and XVEPVG to be use in the following includes.
- SAPLV05I
-> LV05IFEP -> EP_01
-> LV05IF0V -> INDEX_VEPVG_AUFBAUEN
This section of ABAP coding tells you how the Schedule dates will be determine for VEPVG.
Then, let's focus on line 4.
Line 4. SAPLV05I -> LV05IFIX -> INDICES_SCHREIBEN -> INDEX_VEPVG_SCHREIBEN
This line tells you and me, how the table VEPVG gets maintained.
So now, you know the moment when we press "SAVE" button to trigger SICH command, SAP actually flows through these following processes AND I AM TELLING YOU, there are no problem and no errors here in this coding.
So, for god sake, where and why it is saving the VEPVG correctly?!?!?!
The answer is - you, I meant myself, did not maintain my enhancement points or user exits correctly for Y and X tables. Simple huh? Yes it is that simple. But, the complexity lies in trying to find out WHICH user exit or enhancement points that is CAUSING this problem!
In my case, I had to spent 3 days long, okay, i had a week Christmas break. But that thought during the whole holiday is challenging enough for you to go back to office and do a deep dig on all the user exits; just to find out the cause why VEPVG is not saving a particular record.
The cause of my case was an enhancement point which I'd created it for the EDI team back in August 2012.
Back in August, I had an IDOC Order Response Enhancement project for the EDI team, and this enhancement was a fix to mend back some missing multiple schedule lines. As a result of this fix, VEPVG was affected. Therefore, the dig i can tell you, is deep dig. I had to go to MV45AFZZ before going to SE19 (you should know what this TCODE do) and display a whole list of Z-enhanced fix.
In this case, I dive straight in to the enhancement point to correct the YVBEP table. Yes, the moment you make some change to YVBEP table, it wil indirectly change it's behavior. So do be very careful when you are changing any of X and Y internal tables. You may not know what future scenarios you are changing.
So, it's an all well end's well. I hope in this 3 part you've gain some insight on why your X and Y internal tables is so important. Yes, i know X and Y tables exist in all user exits but you and I know we can't help it because we are all happily using it to solve our daily ABAP assignments, mini projects and big projects. Good luck!
References :
415716 - User Exits in Delivery Processing
128947 - Correction of SD Document Indexes With RVV05IVB
178328 - Problems due to Incorrect User Exits in SD
williamwilstroth... SAPLV05I, LV05IFIX, INDEX_VEPVG_SHCREIBEN
