What determines whether a user can change an approvable that has already been Submitted?

If a user is allowed to change an approvable, the Edit button is available. Two settings can determine whether a user can change an approvable that is previously Submitted: group membership and edit rules, described as follows. Edit rules are given the highest priority.

• Group membership is the first setting that determines whether the Edit button is available to a user. For example, the Purchasing Manager group exposes the Edit button on requisitions, so members of that group can Edit requisitions. On the other hand, the Purchasing User group does not expose the Edit button, so members of that group cannot edit requisitions unless they belong to another group that permits them to make changes. Some groups that grant editing permissions also allow group members to make changes without altering the approval flow (that is, without requiring resubmission or re-approval). Edit rules can override the editing permissions granted by group membership.
  The Ariba Groups and Notifications Reference Guide has more information on groups.
• Edit rules can do two things:
  • Prevent editing under specified circumstances by hiding the Edit button. In this case, the Edit button is not available to users who would normally see it based on their group membership.
  • Determine what happens to the approval flow when a user edits an approvable. You can require the approvable to be resubmitted (in which case the approval flow is regenerated), you can require previous approvers to reapprove, or you can allow editing with no effect on the approval flow.
  Note: You cannot use edit rules to expose the Edit button to users who do not already see it based on group membership. Edit rules have conditions and actions.

You can configure different edit rules based on the user attempting to edit the approvable, the information in the approvable, and the fields being edited. Here are some examples of edit rules you can configure:

• The Purchasing Agent can make changes, but changes require re-approval.
• The Preparer is not allowed to make changes after submission.

This example illustrates how group membership and edit rules work together to determine editing rights:

• User, Arnold Davis (adavis), belongs to the Purchasing Manager group. By default, this means he can edit Submitted requisitions. The changes he makes do not affect the approval flow; neither does the approvable require re-approval, nor does it need to be resubmitted.
• Suppose you add another edit rule that dictates the following behavior: Requisitions with line items charged to department A cannot be edited by any user. Now, when user, adavis, views a requisition from department A, he cannot edit it even though he is a Purchasing Manager. No Edit button is available.

Edit rule order

The order in which the edit rules appear on the Approvable Edit Rules tab makes a difference. For any user or field being evaluated by the edit rules, the SAP Ariba Procurement solution uses the first rule that has a matching condition.

For example, suppose an approval process includes the two edit rules shown in the following table:

If a purchasing agent edits the approvable, the Ariba solution uses the purchasing agent edit rule because it is the first rule in the table that matches the situation. The approvable is resubmitted causing the approval flow to be regenerated. If a different user edits the approvable, the second rule is used.

However, suppose the order of these two rules is reversed:

In this case, when a Purchasing Agent edits the approvable, the first rule that matches the situation is Users can edit with reapproval. The newly edited approvable requires re-approval, but it does not need to be resubmitted, and the approval flow is not regenerated.

The Ariba Approval Process Management Guide has more information on edit rules.

Core Procurement > Core Administration > Approval Flows