Recently we had a couple of customer incidents stemming from SM13 update errors on GTS side.
In this blog I wanted to show how to easily find the data the system could not update.
In most cases these will be internal table entries transferred from the feeder system.
1. In GTS go to SM13
2. Select the relevant SM13 error
3. Double click the entry
In this example Purchase Orders failed to update to the preference LTVD worklist on GTS side after being transferred from ECC.
4. Double click the entry
5. Press the ABAP Editor button
In this case we can see that the system was trying to update table /SAPSLL/PREVDWLI with entries from IT_UPD.
So to solve this issue we need to know what was in internal table IT_UPD during runtime.
6. To do this we need to press the green back button once and close the “Status of Update Module” pop up until we are back at this screen…
7. From here press the “Display Update Data” button
8. This should bring you to a screen where the local memory data at the time of attempted update has been captured
9. Double click the “IT_UPD” parameter and you should have the entries that will be crucial to any further investigation
From here we were able to copy the GUID_PR into /SAPSLL/PNTPR and find the materials associated with this failed update.
With these materials we were then able to pinpoint the problem Purchase Orders for that date in ERP table EKPO.
This method is not only relevant for preference LTVD worklist update problems. It can be used for most SM13 errors in GTS.
So please keep this method in mind for your own investigations and follow it before you raise an SAP incident. This will greatly speed up time to resolution at SAP and may even help you solve the problem yourself.
Please note that certain sensitive data has been blocked out in the above screenshots to protect the integrity and security of our internal GTS systems.