Table of contents
Scope
ERP
References
Attachments
5. Add the link to attachments (to be stored in AODocs or GDrive) or external links
Objective and Scope
The purpose of this document is to explain how to act when encountering situations of Workflow (WF) requests in error in SAP system PF1_050 (PRS). Depending on the type of error, there is a different possible solution to overcome it and resume the normal flow of WF requests.
This operating procedure (OP) applies to all Workflow requests originating from PRS (PF1_050) which are in error or have a status which requires an action to resume its flow towards its (re)solution.
- Definitions
WF – Workflow
VWF – Vendor Workflow
PRS – PF1_050
- Support Team
Paulo Del Bel, Kunal Panchal, Gergana Nikolova
Procedure
The contents and responsibilities are described in the steps below:
Search Requests in Error
In order to detect possible workflow cases to be handled within the scope of this procedure, it is necessary to run the following transaction:
- Z1S_VWF_REQS_LIST (List of vendors workflow requests)
These are to be done using the parameters below:
Creation date: date of the day - 1 month
Status: D E
Afterwards, click on Execute (F8): 
Once inside, the list of all the WF requests to be handled is presented:
In here, it is possible to gather the following information concerning the Workflow requests with this status:
- Workflow Request Number;
- Requester's ID Number;
- Last Modification;
- Vendor Number;
- Vendor Name;
- City;
- Country;
Take note of the workflow numbers which appear in the list, as these need to be processed via transaction SBWP (to be described ahead in this document).
2.2 Process Requests
The contents and responsabilities are described in the steps below:
Once the request is open, display the reason of the error by clicking on:
SBWP
After gathering the WF numbers concerning the requests in error, enter in transaction SBWP.
It is possible to crosscheck in the 'Preview' screen the existing Workflow requests which concern Requests in Error. It can be distinguished in the line concerning 'Request Status'
Double click on the request.
Once the request is open, display the reason of the error by clicking on:
- the icon
for vendors
Example for customers:
Example for vendors:
| Most frequent errors will be documented in the point ‘Attachments’ on this document. Nevertheless, not all the errors will ever be registered, as it is not feasible (due to the high amount of possible points). |
If the screen displayed does not contain invalid data, or error message, click on enter to go to Processing
Return to the request and click on the icon 
For Vendors , the mode of processing is asked by the system:
The Display Mode to be selected should be ' A ' ( Display all screens )
Then, the system performs the standard SAP transactions corresponding to the request:
- Vendor creation: XK01
- Vendor modification: XK02
- Vendor unblock: XK05
- Vendor undelete: XK06
During these transactions, the user is able to change data in order to correct the error
If the screen displayed does not contain invalid data, or error message, click on enter to go to next screen.
The status "error" in the workflow can be caused by a warning:
Or by a blocking error:
In case of warning, click on "enter" until the transaction restarts.
In case of blocking error, the transaction is blocked, and it is not possible to continue without correcting invalid data (according to data maintenance rules).
If it is not possible to correct, leave the request.
Example: Error in field "Next internal review", which is blank.
The procedure states that "by default", this date must be the current date + 1 year.
Then, restart the transaction by clicking on "Enter".
When several vendors have the same VAT number, the system displays the list of vendors with the same VAT number. In that case, click on the "Return" icon, the screen below is displayed.
We always assume that the data controller has already checked that they are not duplicates, so, always click on 'Yes'.
Continue the transaction until the request is displayed again.
Normally, at the end, the request is in status 9 (Completely Processed).
If it is not the case, contact the Support Team.
2.3 Check Results
The contents and responsabilities are described in the steps below:
It may occur that this process does not update correctly all the data (especially the target system indicators).
So, it is always necessary to check if the customer or the vendor has been correctly created or modified.
For this, check the following transaction(s):
- XK03 for Vendors;
3. Administration Role
3.1 Complete Wait, Forward or Execute Agent Rules
(Action: Pass the request from the Vendor to D&A Business Workplace, from a Panel Manager to other Panel Manager or from an interspace to D&A Business Workplace).
1. Go the request in display mode via transaction Z1S_VWF_REQUEST and enter the words "wi_id" in the top left corner transaction box and press enter.
2. In the next screen, copy the workflow id.
PS: if the system for example gives an error that the DUNS code is missing, go into change and add something in this field so the system does not complain anymore (do NOT save !). Then type in the "wi_id" again in the top left corner and press enter. Alternatively you can go to transaction SE16 with table Z1S_CWF_REQUESTS and fill in the requestnumber in the first field, execute (F8) and the workflowid can be found in the field 'WI_ID'.
3. Go to transaction SWIA or SWI1 and enter the workflowid in the field below and press execute or use the F8 key.
In the next screen doubleclick on the line that shows in the first field of that line.
4. Go to the very last node and put the cursor on it. This item must have the description that is needs to be approved. Then go to the menu "Goto -> Work Item"
PS: The little white 3D box means that the workitem is free, so nodbody has entered the workitem yet. If it is half-white then it means somebody has already entered the workitem (and thus it is in process). When that person takes and action the box will become totally blue. If that person leave the workitem without taking any action, then the box becomes totally white again.
5. In this screen, go to "Extras -> Activate Administration"
4. Abort
Abort requests at any moment in time. A request can be aborted by the creator of the request when it has not yet been submitted, but there are cases whereby the request is asked to be deleted on other times during the lifecycle of the VWF. For example a request is at the vendor with status V (Waiting for vendor to fill in the webform). In this status normally we would have to wait 10 days before any action can be taken (by PtP).
Goto transaction SE38 and execute program Z1S_CWF_ABORTRQ
You can use or not use the field status to select requests. Usually it is asked to abort 1 known request, so fill in the request number. Decheck of course the test run flag. Don't forget after this step to complete the workflow via SWIA transaction, otherwise it will remain open forever and this is an unnecessary load for the system
5. VWF rules
- Segment code: cannot be changed during a VWF for modification (the request needs to be erased, the PUR team needs to correct the segment, then a new VWF needs to be created);
- Segment code: can be changed during a VWF for creation;
- Abort (trash): available only by the requester
- Rejected (cross): can be used by the requester, the PM or by the approver