Pick list taking 45 minutes to process at VL01n Creation

[Former Member]

Hello All;

I am hoping someone might be able to guide me on where to look for the below problem.

At the end of month/quarter we try to ship out as much as we can. One of our issues during this time is the time it takes to generate a pick list. We are using ECC 6.0 and are utilizing WM. The problem seems to be with the material being made on a production order.

Requirement is when the picklist is generated it prints with the Bin Loc for the enduser to go to and pick. This is done through a code that was developed by a person that is not on the premises any longer. We have this for serialized material and also for non serialized material. When the material is on a sales order and the end user creates the delviery for the picklist to be generated (VL01N) it is taking about 45 minutes for it to process...the sales order may have like 8 items on it. We think part of this issue is when the end user receives the material; it is rec'd in MIGO and after the posting of the GR the system autimatcially will take them to LT06 for TO. If the end user has two different receipts and same material number. The first one shows the Bin and the second one does not in the LQUA table. The only way to get the second one to show the bin loc you have to take it from storage then put it back in storage for the bin loc to show. This also goes through the TO process.

We are really confused where all this is located in the system. We have found code in the picklist smartform but also believe there may be something else somewhere that we are overlooking. We made some changes with the smartform and it has corrected the timing a little...but because the second material rec'd is not getting a bin loc without the remove from storage and place in storage process the system does not have a bin loc for the pick list to generate one so the system will look though all the material documents to try and find it. You can imagine the stress this has on trying to get items goods issued during crunch time [end of month]. Any guidance on this would be greatly appreciated. I hope I was detailed enough...I am in desparate need of advise....

[Former Member]

I am guessing, only guessing, that there may some tables being accessed that at the time of development were quite small, and over time have become quite large. This is a common thing when developing for a new installation, because it is hard to test for a fully loaded database.

There are two tools you might try, ST05 and SE30. ST05 will trace the database access during the process, and let you know if there are very lengthy access to any particular table during the process. You can then look at how the access is done (the "where" clause, and compare this to available indexes, etc.

SE30 will trace both the database and the code, letting you know what parts of the code and database are causing the most issues from a time perspective. You can also see all of the pieces of code getting executed, and possibly figure out if there are other modules or user exits in play.

I would suggest you run these against a small order, to minimize the data collected, so it is simpler to analyze.

hope i have helped.

dave

[Former Member]

Thank you for your response will try and revert back findings.