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:
| 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:
- Load the Organisational data from file YAWLOrgDataExport.ybkp using the control centre.
- Load the specification ProcureToPay.yawl using the control centre.
- Load all other yawl-files as worklets using the YAWL editor.
- 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”.