Motivation

If you want to explain the essence of a procure to pay workflow you might want to use a diagram like this one:

It shows the "sunshine path" of a process where a request is created by a requisitioner (red), the request is approved by a manager (orange), a purchase order is created by a buyer (yellow), and the goods are selected, shipped and invoiced by a supplier (blue). The requisioner receives the goods and the buyer receives the invoice. Finally, the invoice is payed by accounts payable (blue).

It may happen of course that the request is not approved, that goods are not available or that there are complaints after the reception of the goods or the invoice. If we add this behaviour to the diagram above we get something like this:

 

Although the control flow is depicted here in a very direct way, we lose some of the simplicity and clearness of the original approach. In this tutorial, we will show how the original diagram can be directly used for an implementation that accounts for all the special cases. This can be done by using worklets and exlets.

Developing the solution step by step

The first thing we will add now is a differentiation of the task “Approve request” according to the Max_price:

 

Rules for task Approve Request
Condition Action Worklet
Max_price < 500 No approval ApproveAutomatically
500 <= Max_price < 10.000 Approval by manager -
10.000 <= Max_price < 100.000 Approval by senior manager ApproveSenior
Max_price >= 100.000 Approval by a manager and a senior manager (four-eyes principle) ApproveTwo

In order to do this we have to write and upload the worklets and then create an RDR-tree like this:

Next we want to notify the requester if the request has not been approved and then cancel the case. Since the compensating action is done in a worklet, we cannot use the retain familiar facility of the editor. We must store the userid in a variable and pass it to the worklet. This can be done with a codelet called “TaskCompleterInfo” that comes with the YAWL distrubution.

We will first create a worklet called “CreateRequestWorklet” that will always be used. It serves for hiding the technical task “Store completer of WI”.

Once we have this done we can crete a Workitem post-constraint violation rule. The actions suspend case, compensate by “NoteRejection” and cancel case are executed if the request has not been approved.

We do the same thing for tasks “Create purchase order” and “Select goods”, i. e. notify the requester in case something is not available and cancel the case.

If the goods received are not ok we want to return them and notify the supplier of this fact. For this purpose, a worklet “Return goods” is created that does this.

Furthermore, the SupplierID must be stored as well. This requires another worklet “Select goods worklet”.

 

Overview of the results

The next table shows an overview of all worklets and how they are linked to the specifications. The information is persisted in the files ProcureToPay.xrs and Return_goods.xrs.

 

Specification

Task

Rule type

Worklet

ProcureToPay

Create request

Selection

CreateRequestWorklet

 

Approve request

Selection

ApproveAutomatically

 

 

 

ApproveSenior

 

 

 

ApproveTwo

 

 

WI post-constraint

NoteRejection

 

Create purchase order

WI post-constraint

NoteRejection

 

Select goods

Selection

Select_goods_worklet

 

 

WI post-constraint

NoteRejection

 

Receive goods

WI post-constraint

Return_goods

 

Receive invoice

WI post-constraint

Note_complaint

Return_goods

Return goods

WI post-constraint

Note_complaint

 

Installation

All necessary files are attached here in a zip file. In order to install everything follow these steps:

  1. Load the Organisational data from file YAWLOrgDataExport.ybkp using the control centre.

  2. Load the specification ProcureToPay.yawl using the control centre.

  3. Load all other yawl-files as worklets using the YAWL editor.

  4. Load the rule files ProcureToPay.xrs and Return_goods.xrs using the YAWL editor.

 

Running the workflow

The workitems of the workflow are distributed to the following users:

 

User-ID

First name

Last name

Roles

req

Rudi

Quarz

Requisitioner

man1

Miro

Nantz

Manager, Requisitioner

man2

Marthe

Nox

Manager, Requisitioner

sman

Sean

Nibble

Senior Manager, Manager, Requisitioner

buyer

Berta

Ruddington

Buyer, Requisitioner

supp1

Serge

Partre

Supplier

supp2

Samantha

Picks

Supplier

ap

Amanda

Proffs

Accounts Payable, Requisitioner

All users have the password "pass".