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

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 Z1S_VWF_REQUEST.

Once the request is open, display the reason of the error by clicking on icon  :

Return to the request and click on the icon  . 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

Use the button to pass by all the fields:

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. 

Perform the change and continue to click Enter.

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). 

Normally, at the end, the request is in status 9 (Completely Processed). If it is not the case, you can force the creation/update in the main system by clicking in the button "Force status to completed":

In this type of situations you will need to update the data in the local system as the request will only add data to the main system.

Administration Role

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

To change the owner of a Vendor Workflow Request it is used the transaction Z1S_VWF_REQUEST.

Then, in the top left box it is inserted the words "wi_id". Press enter. This will provide you the id of the request:

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. 

Leave the transaction with the code.

Then, in the transaction SWIA or SWI1 it is entered the code:

Execute and then double click in the code.This action will provide the Workflow log. 

The last node shows an item with the description that it needs to be approved. Click one time to select and then go to the menu "Goto -> Work Item":

In the next screen, click in "Extras -> Activate Administration". Several options will appear. Choose according to the action needed:

After executed the operator can get out of the transaction.

Abort a workflow

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).

The transaction used is Z1S_ABORTRQ - Abort Customer Workflow Request (PF1_050):

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 PM or by the approver.