How to find the Data causing SM13 Update Errors on GTS side!
Hi Guys,
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.
Best Regards,
Eoin
Very useful
Eoin,
Once you find the problem material and delete it from the worklist, how do you prevent it from occurring again? We have this happening over and over every day, usually for the same admin unit/vendor/material. The follow-on function is always 004 (trash can) so I can easily delete them but it keeps our basis team busy reviewing errors that should not occur.
Hi Opal,
I understand it can be quite time consuming. This issue is being looked at by development at the moment.
Can you confirm notes 2148374, 2164307, 2189635 & 2238004 are installed in your system?
Once I know the notes are installed I can give further advice if the issues reoccurs.
Best Regards,
Eoin
Thanks for the response. We have the first 3 notes but we don't have 2238004 installed. I will get that applied and let you know if it resolved our problem.
Hi Eoin,
The note 2238004 has now been installed in our production system and the errors continue to occur. Please let me know if you have any further insight into this situation.
Thanks,
Opal
Hi Opal,
Thanks for installing the note and communicating through this channel.
I believe we need to investigate further on your system.
If you open an incident and refer to this chat I will pick it up.
Thanks for your patience.
Cheers,
Eoin
The problem occurs in our GTS11.0 system after implementation of support packages 4 and 5. before this we did not have the behavour at all. So maybe this helps to find the reason for this problem.
Best regards
Susanne
Hi,
Very nice document dear.
Hi GTS Expert,
Appreciate you for providing this Document. it is very much helpful for me.
Regards,
Srinivas Yellampalli
Hi Guys,
Please see note 2314769. This provides the fix for the root cause of this recurring issue.
Best Regards,
Eoin