Building Ariba documents approval flows with focus on purchase requisitions – do...

This post intends to supplement the previous Approval Rules one, focusing now on the settings outside the primary approval flow explained there. To understand the problematic and Ariba documentation better it is very useful to understand the distinction between “edit” and “change” of approvable document the way Ariba does. For Ariba, “edit” describes changes done to the document while being already in the approval process in status Submitted. “Change” on the other hand, describes a situation where the PR was created and approved, PO was generated, but to make some additional changes the original requisition has to be “changed” and a new version of the PR needs to be generated. Changes apply for documents in Ordered status.

APPROVABLE EDIT RULES

Very often Ariba admins get confused about what is the difference between “Filter Rules” and “Approvable Edit Rules”, but in reality the distinction is pretty simple: Approvable Edit rules influence how the approvals will behave when certain conditions are met. They determine whether users can modify (“edit”) an approvable, e.g. purchase requisition, after it has been submitted, meaning they are applicable for documents with status ‘’Submitted’’. The conditions can be built the same way and with the same logic as for Approval Rules. One of the possible sub conditions could check if someone in the approval process changed some predefined fields in the PR. The conditions can be combined so another sub condition could specify that only authorized users with a specific user group assigned are allowed to change the fields without retriggering the approval. Those could be buyers, tax managers, charge managers etc. You can then define corresponding action to be triggered if the conditions are met: should this edit have no effects, should the PR be resubmitted , reapproved or should the edit be forbidden altogether.

• Edit with resubmit – approval engine starts entire approval again from the beginning
• Edit requires reapprovals – will cause that a re-approval will be needed on the approval node that is in the flow after the node where the change was made.

E.g. screenshot below – Budget Approver approves and Audit Buyer approves afterwards. Budget approver realize only later that there is a need to change something and edits the PR. The engine will then go back to Audit Buyer to reapprove. In other words this action can invalidate of some approvals which were already done.

If the user making the edit is not in the approval flow at all, this would then take the approval back to the first approval node almost like in the edit with resubmit.

• No edit possible – edit button is not visible.

You can also notice buttons “Move Up” and “Move Down”(Do not forget to be in edit mode). This allows you to change order of individual Edit rules. Similarly as for the approver lookup tables, Ariba prefers and applies first the rules which are higher than the others. In practice when you decipher behavior of certain approvable approval process, you need to start looking at the rules placed higher to see if they are applicable and only then proceed to the next Rule. This Rules hierarchy is important f.ex. in case that an approver would have roles/groups assigned in multiple rules – that is when the hierarchy of the rules would be applied.

FILTER RULES

You can use Filter rules to filter the approval requests generated by the approval process. Same as for edit rules, the order of filter rules is important. Only first valid will be taken into consideration. For example, you can add a filter rule to remove duplicate occurrences of the same approver or remove requestor himself. You can also Remove approvers and auto-approve the changed requisition if the quantity or amount on individual line items has not increased and there were no changes to additional fields you could have specified in the rules. In case user or group appears in the flow multiple times, you can decide to keep only the first or only the last occurrence. See the example below: Budget User is twice I the flow without additional filter rule:

If you decide to Retain First Approver – this will keep the user or group only in the first node where they appear:

If you decide to Retain Last Approver – this will keep user or group only in the last node where they appear:

TIP: What if you want to skip requisition approval altogether, for example when PR changed, version 2 of the requisition was generated as a consequence of this, but you would like to keep the approval in place only for requisitions changed more than certain threshold? Technically speaking the question would be how to skip certain approval nodes. Business often asks for this in connection to price changes. Apart from creating approval node conditions as usual, you can add the condition saying that the original conditions are valid only for the first version of the requisition. There is predefined field available to do that. You can then create another set of conditions for this approval node which will be relevant for V2 and following versions of requisitions by adding the corresponding field to conditions defining that version value should be 2 and higher. After that you can add to those new versions conditions a condition demanding that total cost change in percentage needs to be higher than let’s say 10% for the approval node to be triggered. Similarly, you can create condition, working in tandem with the percentage one, specifying that the difference between current and previous version amount in absolute values needs to be above certain threshold. Unfortunately, similar fields comparing two versions of purchase requisition to be used in Conditions to set this up have to be, at least at this point in time, created by Ariba support, so you will have to reach out to them.

Hope that this helps you to understand the approvals settings and the complexity behind better.

Cheers!