SRM workflow troubleshooting
In SAP consulting I have always faced issues with Workflow which may sometimes be sporadic and really don’t have an answer as to why they occurred . The only easy solution is to get the workflow restarted for me this has worked most of the times . I am not considering the issues where there is a code logic in the workflow which obviously needs to be fixed .
I created another blog sometime back where I explained in details some technical concepts and how we could get a report generated for the workflow items
List of objects to read approval data in SRM , create approval ageing report
I also added some ways on how you could handle the erroneous work items but here I mostly focussed on logically deleting them .
Different methods for handling Work items –in error / to restart/ to delete
In this blog I shall be focusing more on some more of such workflow errors which I came across and some ways one of which might work to help you get rid of the workflow error
Most of these errors are sporadic which means it is not due to a code error or due to some master data issues . They just happen (not sure why) and if you re-trigger the workflow it goes away
Error 1 : Workflow shows steps executed successfully see the word ‘Approved’ but header status does not update it stays ‘Awaiting approval’ . Also notice ‘Workflow current status’ as ‘Error’ .Check below screenshot
The way around for this would be check if this is a change version . if yes then delete the change version and create a new one and repeat the steps . Generally this error is sporadic and would go away
Error 2 ; Error message which says ‘Action not possible status update is still in progress ’
When I click on Edit for a PO which is awaiting approval as requestor or try to approve as an approver
I get the below dialog box . Now the PO is practically dead neither it can be edited nor approved
I had raised a SAP note and since I could not replicate the issue even once although we had 3-4 such cases every week I had to close the OSS. I closely noticed that these PO’s had Received on date missing in the PO . Hence they were never sent to the approver and since they were on thier way it wasnt even editable by the requestor . Even after refreshing multiple times the Pos stayed in the same status
However I found a OSS note which had a custom report that helped to re-trigger the workflow and get the PO to the approver so they could approve it again . Below are some of the other solutions along with that which I tried for these cases and similar ones
Proposed solutions:
- Implement some notes and custom reports in your system
1864873 – You want to complete a workflow that has failed to start, got stuck, or in error.
1575495 – Restart of WF processes — This one did not work very well in my system
1458380 – Restart process controlled workflow by ADMIN – This one was implemented and helped to resolve the issue
- SWI2_DIAG
This Tcode lists down all the workitems which are stuck in approval but even after restarting the workflow remains stuck. But ideally you need to enter the work item ID in this one . Just enter the date and it will bring all workflows which have error status. I generally prefer to use this for monitoring
After you get this work item in error status the report in point 1 can be executed . I have created a batch job which picks this up and processes it automatically.
- SWPR restart workflow after approver
It does not show up the workitem here I tried using the Workitem ID of the dialog task as well as that of the subtask which went into error However somehow this one does not work fine in the current system I am using to restart the workflow
- The more easier way is to use SW01 to completely approve it from the backend this has an Audit issue. Below are some steps to use SWO1
Run SWO1 with Object type and GUID like PO or SC or Contract GUID. Now scroll down and find the SETRELEASED method to approve the PO from backed
After the method gets executed it asks for INITIATOR but it accepts any value or can be left as blank as well. Now execute again and find the below screen
Now my PO which was stuck shows status as ‘Ordered’ . Make a note that there is no ‘Processed on’ date. Also check the Line item status which says OPEN and the Current status as Active
Now compare this with a correctly approved PO
Processed on Date – Filled
Current status – Finished
Line item Status – Approved
Header status – Ordered
Hence it has got some big audit issues as there is no record in any of the tables as to who approved the PO and at what time it got approved.
I do use it extensively in the Test and dev environment
- If you issue requires you to debug this is when you know that workflow every time gets into error and you are able to successfully replicate it . Then use Tcode SWUS_WITH_REFERENCE and enable debugging of the workflow.
6. The other way is to To cancel the workflow and create a new workflow. Use FM SWW_WI_ADMIN_CANCEL. There is no difference that you would see from the portal side and this may again cause ambiguity as to what date the approval item was received .
After I executed this it logically deletes the workflow approval and creates a new one in READY status.
I hope you find this article . Do leave a comment or any other ways in which you tackle the work item and I would include that as well.
Regards
Vinita
Hi Vinita,
Appreciate your effort for this useful document. I would suggest you to keep update this page with more workflow errors and solution.
Thanks & Regards,
SR
Good day Vinita Kasliwal and everyone.
I have a same kind of problem, I would like any help I can get.
A Purchase order was created from a shopping cart and it was approved by PO approver. The issue I have is that on Approval, Header there is no ‘Received on and Processed on’ time and date. Which messes our report in terms of performance.
PO
Your assist will be highly appreciated
Hey Xoli
I dont know why that issue happens and for me those approval tasks were never sent to the approver
so what i did was to implement this custom workflow which triggered the workflow from start and the next time it worked fine.
If you can manage to successfully replicate raise it with SAP if not then this is the workaround
if you have a report which identifies these affected cases then you could probably run this custom program as a batch job for the affected cases
Have a look at the 3rd one from the below list that is the one I implemented
let me know if it helps to solve
Regards
Vinita