Tuesday, January 22, 2013

SAP ECC6.0 : Consignment Issue Custom Schedule Dates Auto Update

Six months ago, I had the task to do a custom implementation on the consignment issue document that it could automatically update the line item's schedule dates. Schedule dates like Goods Issue Date, Loading Date, Material Available Date and Transportation Plan Date. All these dates by requirement is to be updated according to Line Item's Delivery Date. The Delivery Date will determine all the Schedule Dates according to the Route's Transit Days. So to speak, we need to ensure that this change is only for consignment issue and no other document will be affected. 

Let's identified all those Schedule Dates that we need to modify or automatically update : 
  • VBEP-WADAT (Goods Issue Date)
  • VBEP-LDDAT  (Loading Date)
  • VBEP-MBDAT (Material Availability Date)
  • VBEP-TDDAT  (Transportation Date) 
Now, here's the challenge, how do I make sure the change takes place and it shows on Shipping Screen. There are two places of Shipping Screen that need to display the updated values. So, I identified two screens :
  • SAPMV45A - SCREEN 4552 (Line Item - Schedule Lines - Shipping Tab)
  • SAPMV45A - SCREEN 4921 (First Screen - Shipping Tab)
Modification for above screens requires 2 enhancement points and 1 user exit. 

1. SAPMV45A - SCREEN 4552 (Schedule Line - Shipping)
There will be one enhancement point here just to ensure the automatic calculation of those schedule dates are display at the screen. The enhancement point will be right after MODULE VBEP-EDATU_AUSGEBEN. That will be where the screen start to fill the schedule dates.

Inside the enhancement point, you should take into consideration of WORK DAYS and NON-WORK DAYS. The day, after Delivery Date minus Transit Days, falls on NON-WORK DAYS, then it should push back one day until it is a WORK DAY. 

In order to get the Transit Days, you need to query TVRO (SAP Table). The field that shows number of days is TRAZTD. This value is in hours and you will need to convert it to days. The function to do the conversion is 'CONVERSION_EXIT_TSTRG_OUTPUT'. 

After you have determine the number of Transit Days and WORK DAY/NON-WORK DAY, you will use the new date as your schedule dates. These schedule dates will be updated to XVBEP. 

2. SAPMV45A - SCREEN 4921 (Overview - TC - Shipping Default)
There is no modification here. The result is a result of calculation in MV45AFZZ. 

3. MV45AFZZ (User Exit)
The logic in SAPMV45A - SCREEN 4552 is applied here too. Same logic.

williamwilstroth... consignment issue, mv45afzz, tvro, traztd, route.

Tuesday, January 8, 2013

SAP ECC6.0 : VEPVG and Delivery Not Created - Part 3

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   

Monday, January 7, 2013

SAP ECC6.0 : VEPVG and Delivery Not Created - Part 2

In my previous entry, I wrote about VEPVG table not being maintained correctly whenever an Order's line item's was change, particularly the delivery date. In a bid to find out why VEPVG was not maintained, I had ST05 switch on so I can do a trace on VEPVG and see where it is updating the table. Needless to say, locating the VEPVG was easy and not a monumental task. So, as a result, you will get below result if you do the same too.

Now back, the my own issue, VEPVG was not showing an Order's line item for Delivery creation when Delivery Date was changed. Here's what ST05 found for me:



** INSERT THE VEPVG
18:12:15.013       332 SAPLV05I   VEPVG      REEXEC 
18:12:15.013       142 SAPLV05I   VEPVG      REEXEC
18:12:15.014         24 SAPLV05I   VEPVG      DECLARE
18:12:15.014       276 SAPLV05I   VEPVG      PREPARE
18:12:15.014    2,380 SAPLV05I   VEPVG      EXECSTM
18:12:15.016       228 SAPLV05I   VEPVG      REEXEC
18:12:17.940           8 / /DBVE       VEPVG      REOPEN
18:12:17.940       584 / /DBVE       VEPVG      FETCH  
18:12:17.941           4 SAPLSETB  D020S       OPEN   
18:12:17.942           6 SAPLSVIX  TDDAT       READ SI
18:12:17.943           3 CL_ABAP   TRDIR         OPEN 
  

** DELETE THE VEPVG
18:18:20.772       282 SAPLV05I VEPVG     REEXEC  <<- b="b" deleted="deleted" here="here" ot="ot">
18:18:27.811         12 / /DBVE      VEPVG     REOPEN 
18:18:27.811       498 / /DBVE      VEPVG     FETCH    
18:18:27.812          6 SAPLSVIX  TDDAT      READ SI 

No wonder, I could not see my expected line in VEPVG, ST05 is telling me that SAP is inserting a record then removing it. But WHY?! ST05 only shows WHAT the program is doing. So, you need to understand the logic in order to understand WHY it is doing this. 


When I double click the DELETE statement, I notice the condition to it is "IF ARRAY_DELETE = ' '". Why would the ARRAY_DELETE be blank and resulting missing record in VEPVG? 

Well, ARRAY_DELETE is used in several SAP Index update Program. This programs manages all the indexes for Orders, Deliveries, Billing and Invoices. All of it which will be use in creating subsequent documents in the background. It is damaging if the index table especially VEPVG is not maintained correctly because you will be face a group of angry customers/users asking you why my delivery/billing not created since yesterday? The automation not working? 

Here's the list of Index Programs:
- RV_BILLING_INDEX_UPDATE
- RV_DELIVERY_INDEX_SAVE
- RV_INVOICE_LIST_INDEX_UPDATE
- RV_SALES_DOCUMENT_INDEX_UPDAT

Now, we know what is not updating and where it is not updating but do we know why?? The reason all point to how you maintain your user exit especially how you manage your X and Y tables for VBEP i.e. YVBEP and XVBEP. 

williamwilstroth... VEPVG, INDEX