Objectives
The Approve & Finalize phase of the Contract Lifecycle includes:
In a typical contract workspace, there is a final approval task associated with all the documents of the contract workspace. This final approval usually dictates whether or not the owner can publish a contract.
Document approval tasks are similar in setup to negotiation tasks. They may include one or more documents and should have an initial message to the approver(s).
SAP Ariba Contracts templates may specify approvers or reviewers based on the type of contract a user is creating. The approval flows generated are intended to model the organization’s business processes, and are often dependent upon the values of the header fields of the contract workspace, such as the contract’s monetary amount, region, commodity, etc. These approval flows could include actual users or project groups as placeholders. Since this is one of the control features of the system, workspace owners can only modify these flows by adding to them. They are not allowed to delete or modify the portion of the approval flow that the system creates when a new workspace is generated from an SAP Ariba Contracts template.
The flow diagram will be updated dynamically based on conditions included in the SAP Ariba Contracts template. For example, if a contract is over a certain monetary amount, there may be a condition that adds a certain user or role to the approval flow for the entire contract.
| Approval Flow | In all task types that have a workflow, (Approval, Review, and Negotiation), the task owner can add reviewers/approvers to the flow both before and after the task is submitted. Click the arrows in the diagram in the location where you want to add a serial approver. If you click the arrow to the left of the first reviewer/approver, you have the option to add either a serial or parallel approver. When adding an approver to the flow, indicate if the approver required (approver) or not (watcher). An approver will approve or deny the task. A watcher can view the task and attach documents to the task, but cannot approve the task. |
| Parallel Approvers | For parallel approvers the system activates the approval nodes at the same time. You can only add parallel approvers from the first-level approvers (left-most approvers) in the flow. Once the approval task is submitted by the task owner, task approvers can also add additional approvers when it is their turn to approve the task. They can delete only those approvers they added. They cannot delete approvers inherited from the template or those added by the task owner. |
| Serial Approvers | Serial approvers are assigned consecutively in the order they appear in the approval flow diagram (from left to right). The system does not activate a node in a flow (assign a task to the approver in the node) until the preceding approvers have submitted approvals. |
There are two types of approvers who can be on an approval graph:
An approval node can be one of the following types:
You can view the details of the user or group by clicking it in the approval graph. A new window displays the details of that user or group.
When selected as an approver for a submitted document, a notification via email and/or a dashboard notification is received. The email notification has a link which goes directly to the task. If the approver is part of the workspace team, they receive a notification via the dashboard and will be able to view either the task or the entire project.
Once the task is opened, the Approver reviews the documents and when complete, either click the Approve or Deny button. If approved, the workflow continues to the next approver. If denied, approvers should include a message that explains what changes they require to grant approval. Approvers may include edited versions of the contract documents as well as other file attachments. Once the approver has denied, the corresponding round of the approval task is marked as denied and a new round is necessary.
The task owner receives notification after each approve/deny response. If the task is denied, the task owner goes into the task, and reads the comments of the approver on the Comments tab. Links to any edited documents are available so the owner can view the approver’s suggested changes. After reviewing the changes, the owner decides how to incorporate these changes into the contract documents. The owner opens the edited version of a document and saves it; thus updating the current version to the corresponding document in the workspace.
After making changes to the document(s) that were denied in the first round of approval, the owner submits the new round of the approval task. All required approvers will see the document(s) again with the changes made and will have the option to either approve or deny.
Eventually, the owner and the approvers reach agreement once all approvers have marked the task Approve.
Signature tasks are an add-on feature (not out of the box) for SAP Ariba Contracts. SAP Ariba Contracts provides signature tasks using the following electronic signature providers:
Signature tasks enable you to collect electronic signatures from internal and external signers for a document in an SAP Ariba Contracts workspace. An electronically-signed contract can designate a specific version as the official, agreed-upon version, understood by all parties to be the version that is in effect. After a document has been electronically signed, no one can modify the document without invalidating the electronic signature. If a signed document is modified, it must be re-signed by all required signers.
Sap Ariba Contract Management eSignature Services in partnership with Adobe EchoSign and DocuSign help customers to go INK and Paper free and close deals faster and more efficiently, increasing savings, revenue and productivity.
The electronic signature workflow is as follows:
You can edit, withdraw or start a new round of the signature task if required.
Final step, which indicates that the contract is finalized.
After publishing, the status of the Contract Workspace will change to either Published or Pending.
Optional tasks do not have to be marked as completed. Notification tasks are optional tasks that are often not completed when the contract is published. The purpose of a notification task is to notify a user to take a specific action. For example, a notification task ‘Check pricing of lumber’ can be designed so the system will send an email reminder to the project owner 1 year into a 2 year contract. This will prompt the project owner to check pricing to see if any adjustments to the contract are necessary.
Note
The documents themselves do not need to be in status Published in order to publish the workspace. A workspace can be published even if it contains documents in status Draft. Publishing documents has no impact on the functionality of the workspace. Rather, it is just a way to communicate to your team members that you are done working on the document. Documents are automatically published by the system if they are part of an approval task and the approver(s) click Approve. In addition, you can manually publish a document by clicking the document’s link and selecting Publish.| Status | Definition |
|---|---|
| Draft | Currently being worked on and not yet final |
| Pending | Approved, but the effective date is in the future |
| Published | Currently effective |
| Expired | Past the expiration date |
| On Hold | Suspended (actions are limited, expiration and overdue notifications are not sent, and any associated compliance contract is closed) |
| Closed | Manually closed by a user |
| Draft Amendment | An amendment that is currently being worked on and not yet final (can only be set on a previously published contract workspace) |
Log in to track your progress & complete quizzes