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. Those could be buyers, tax managers, charge managers etc.
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. 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 built the same way and with the same logic as for Approval Rules. purchase requisition, after it has been submitted, meaning they are applicable for documents with status ‘’Submitted’’. They determine whether users can modify (“edit”) an approvable, e.g. 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. Changes apply for documents in Ordered status. “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. For Ariba, “edit” describes changes done to the document while being already in the approval process in status Submitted. 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. This post intends to supplement the previous Approval Rules one, focusing now on the settings outside the primary approval flow explained there.
0 kommentar(er)
