Purchase orders can be routed for approval to approvers defined in a position hierarchy or supervisor hierarchy.
See: Using Approval Hierarchies
However, in a typical business environment, purchasing organizations require:
Documents to be reviewed before approval to comply with the organization's review policy. For example, computer or server purchases must be reviewed by the IT manager before approval.
Flexible approval hierarchy to get approval from individuals or group of individuals along with people listed in the standard hierarchy. For example, purchase of hazardous material requires approval from Manager Safety and purchase order approval hierarchy.
Multiple signatories to sign purchasing documents. For example, based on item or total purchase amount, document requires e-signatures of business unit head and director.
Oracle Purchasing provides the flexibility to add any individual or a group of individuals to the approval hierarchy (position or supervisor) so that purchase orders can be routed for review, approval, and multiple e-signature. To setup and use this feature, Oracle Purchasing provides the Purchase Order Approval AME transaction type and PO AME Approval Top Process, a workflow process. To use the feature, the following values must be set in the Document Styles page:
PO Approval in the Approval Workflow field.
PO AME Approval Top Process in the Workflow Startup Process field.
Purchase Order Approval in the AME Transaction Type.
Depending on business requirements, purchasing administrators can setup either parallel or serial process in AME for purchase order review, approval, and multiple e-signatures. Voting method can be First responder wins, Consensus, or Serial. Enterprises can use the predefined AME transaction type and PO workflow process or they can create custom transaction type and workflow process based on the supplied components.
This feature provides the PO Approval Notification Region (POApprvNotifRN ) configurable region to enable enterprises to personalize the notification page according to their business requirements. This region is available in the notification body. You can personalize this region to add or remove columns according to business needs. For example, you can configure this region to control what approvers can view or cannot view in the notification.
For information about AME, refer to the Oracle Approvals Management Implementation Guide
For information on how to setup this feature in Oracle Purchasing, see:
Note:
Oracle Purchasing supports this functionality for purchase orders in both OAF pages and in Forms. Purchase orders created in both Buyer Work Center (OAF pages) and Forms can be routed for review, approval, and multiple e-signatures.
To use the AME functionality in Forms, you must enable AME for Standard Style.
The following restrictions apply to the use of this functionality in Oracle Purchasing:
The Current/Pending Approvers information in Action History is not supported in Forms. This information is available in the Buyer Worker Center Action History only. You cannot add adhoc approvers in Forms and also cannot view the list of approvers.
AME cannot be used for planned purchase orders and purchase order releases.
AME cannot be used for local blanket purchase agreements. If you want to use the AME feature, then use global blanket purchase agreements.
For information on setting up AME, see: Setting Up AME for Purchase Order Review, Approval, and Multiple E-Signatures
If you enable the AME feature, then in Buyer Work Center:
The Approval Options page for orders and agreements displays the AME Approval region. Depending on the AME setup, the Approvers region includes persons who are approvers, reviewers, and signers. In the Add Adhoc Approver region, buyers can select additional approvers and specify their position in the approval chain using insertion point. To add a person for e-signature, buyer can select an existing signer and must add that person before or after the existing signer. However, buyers cannot add adhoc reviewers
The Action History page shows AME Sequence No, Person name and Approver Type of current/pending approvers.
See: Entering Purchase Order Information
See: Create and Update Agreements
If you use AME for purchase order review, approval, and multiple E-Signatures, then the following business rules apply:
Business rules that apply during the purchase order review:
Reviewers have view only access to the document when they receive notifications for review.
Buyers cannot update the purchase order if the order is in the In Process or Pre-Approved status.
Reviewers cannot update documents when reviewing purchase orders.
Buyers cannot manually add reviewers in the Add Adhoc Approver region of the Approval Options page. They can add approvers and e-signers only.
Business rules that apply during the purchase order approval:
Buyers have the flexibility to send purchase order documents to approvers, reviewers, or e-signers based on the AME setup.
Approvers can edit purchase orders when they receive the approval notification.
If the e-signature feature is not enabled, then the purchase order status is set to Approved after all approvals are in. Approvers can approve, approve and forward, reject, or reassign the purchase order notification. They can add their comments to the notification page.
Business rules that apply if the E-signature functionality is used:
Notifiers who receive the notification for e-signature have view only access to the document.
Multiple E-signatures can be provided during the post approval phase only. During the post approval process, approvers cannot be added and document cannot be sent for approval. Esigners have to provide their login credentials to provide their e-signature.
If the purchase order is rejected during the approval, review, or e-signature stage, then the status of the purchase order changes to Rejected. Buyers can update and resubmit such rejected purchase orders.
The following example describes the business flow if AME is setup for purchase order review, approval, and multiple e-signatures.
The following sections describe the diagram in detail:
Purchasing routes the document for review:
Buyer creates and submits the PO for approval. If review is required, then based on AME rule, Purchasing routes the document to reviewer for review. If review is not required, then the application sends the PO directly to approvers based on AME rule.
What happens during review, approval, and multiple e-signatures:
If e-signature is enabled for the purchase order document, after approval it goes to supplier for E-Sign and then based on AME rule, Purchasing routes the document to signers for e-signature. If e-signature is not enabled and approvers approve the purchase order document, then the application sets the document status to Approved.
If supplier signature is enabled and there are esigners as well, then after approvers have approved, Purchasing sets the document status to the Pre-Approved status and sends the document to the supplier. After supplier signature, the document is routed to esigners. Once all esigners have signed, the document will be set in Approved status.
If the purchase order is in the In Process or Preapproved status, then the buyer cannot update the document. In any case, if the document is rejected during review, approve, or e-signature stage, the status is set to 'Incomplete' and user can update and resubmit the document.
Use the Purchase Order transaction type for purchase order review, approval, and multiple e-signatures. This transaction type is triggered based on the PO AME Approval Top Process (PO_AME_APPRV_TOP) set at the document style level.
See:
This topic describe the predefined configuration variables, attributes, and production rule supplied with the transaction type. The topic also provides information about the rules that you must select to identify reviewers and signers.
The following configuration variable are supplied with the transaction type.
Allow All Approver Types = Yes
Allow All Item Class Rules = Yes
Allow For Your Information Notifications = Yes
Production Functionality = Yes
Rule Priority Modes > Production = Absolute 1
The following attributes are supplied with the transaction type.
The following table lists the mandatory attributes supplied with the transaction type.
Attribute | Description |
---|---|
ALLOW_DELETING_RULE_GENERATED_APPROVERS | Whether to let the calling application (or its end users) delete approvers generated by the rules |
ALLOW_REQUESTOR_APPROVAL | Whether to allow requestors to approve their own transactions (when the rules do so) |
AT_LEAST_ONE_RULE_MUST_APPLY | Whether to require that at least one rule apply to each transaction |
EFFECTIVE_RULE_DATE | The date that determines which rules are active |
EVALUATE_PRIORITIES_PER_ITEM | Whether to evaluate rule priorities per item under strict item evaluation |
REJECTION_RESPONSE | How AME responds to a rejection |
REPEAT_SUBSTITUTIONS | Should AME apply Substitution rules on Surrogates and ad-hoc Insertees |
USE_RESTRICTIVE_ITEM_EVALUATION | Whether to require that the same item satisfy all item conditions in a given rule |
USE_WORKFLOW | Whether AME should log exceptions to the Workflow context stack |
WORKFLOW_ITEM_KEY | The transaction's Workflow item key |
WORKFLOW_ITEM_TYPE | The transaction's Workflow item type |
The following table lists the required attributes supplied with the transaction type.
Attribute | Description |
---|---|
ALLOW_EMPTY_APPROVAL_GROUPS | whether to allow approval groups to have no members |
INCLUDE_ALL_JOB_LEVEL_APPROVERS | Whether to include all approvers at a given job leve |
JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID | Person ID of non-default first approver for job-level authority approval types |
NON_DEFAULT_POSITION_STRUCTURE_ID | Structure ID of the non default HR position hierarchy, if any |
NON_DEFAULT_STARTING_POINT_POSITION_ID | Position ID of non-default first approver for authority approval types based on HR positions |
SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID | person ID of non-default supervisor approver for the supervisory-level approval type |
TOP_POSITION_ID | Position ID of the top position in the HR position hierarchy |
TOP_SUPERVISOR_PERSON_ID | person ID of the top person in the HR supervisory hierarchy |
TRANSACTION_REQUESTOR_PERSON_ID | Person ID of person initiating transaction, if any |
TRANSACTION_REQUESTOR_POSITION_ID | HR position ID of position initiating the transaction, if any |
The following table lists the header level attributes supplied with the transaction type.
Attribute | Description |
---|---|
DOCUMENT_TOTAL | Total amount of the document |
TRANSACTION_DATE | Date transaction occurred |
TRANSACTION_GROUP_ID | Business-group ID in which transaction occurred |
TRANSACTION_ORG_ID | Organization ID in which transaction occurred |
TRANSACTION_REQUESTOR_GROUP_ID | Transaction Requestor Sales Group ID ( only used for JTF Resource Hierarchy) |
TRANSACTION_REQUESTOR_USER_ID | user ID of user initiating transaction, if any |
TRANSACTION_SET_OF_BOOKS_ID | Ledger ID in which transaction occurred |
DOCUMENT_TYPE | Document type |
DOCUMENT_STYLE | Document Style used on the PO |
REVISION_NUM | Revision Number of the PO |
CONTRACT_TERMS_EXIST | Determine whether contract terms exist on the PO. |
FUNCTIONAL_CURRENCY | Functional Currency |
CURRENCY_ON_PO | Currency Code on the PO |
DOCUMENT_CREATION_METHOD | Document Creation Method |
The following table lists the line level attributes supplied with the transaction type.
Attribute | Description |
---|---|
ITEM_CATEGORY | Item Category |
ITEM_NUMBER | Item Number |
COMMODITY | Commodity |
The following table lists the distribution level attributes supplied with the transaction type.
Attribute | Description |
---|---|
PUR COST CENTER | Cost Center |
PUR NATURAL ACCOUNT | Natural Account |
PROJECT_NUMBER | Project Number associated with each distribution. |
PROJECT_TASK | Project Task associated with each distribution. |
DELIVER_TO_LOCATION_CODE | Deliver To Location code of each distribution |
PO_WIP_ENTITY_TYPE | WIP Entity type associated with each distribution |
SHIP_TO_LOCATION_CODE | Ship To Location code for each shipment |
Rule to identify reviewers
A reviewer is identified through the Production Rule. For Reviewer use the production rule with REVIEWER/YES as the Action. All the approvers associated with this rule are considered as reviewers.
Rule to identify signers
Post Approvers are signers. While creating a rule for signers, select the rule type : Post List Approver Group. All the approvers associated with this rule are considered as signers.
This topic lists the setup steps to use Oracle Approvals Management (AME) for purchase order review, approval, and multiple e-signatures.
For information about the functionality, see: Using AME for Purchase Order Review, Approval, and Multiple E-Signatures
Prerequisites
To set up AME for purchase order review, approval, and multiple e-signatures
This setup assumes that purchase orders are routed for review, approval, and multiple e-signatures. This setup also assumes that the predefined Purchase Order Approval transaction type is used. Oracle Purchasing provides the flexibility to define parallel or serial process and use the following voting methods: First responder wins, Consensus, or Serial. The processes and voting methods described in this setup are for example only.
In this example, in addition to the supervisor or position hierarchy that is used for PO approval, the purchasing administrator completes the setup for approvers (additional), reviewers, and signers.
Navigate to the Approvals Management Administrator responsibility.
Search for the Purchase Order Approval (PURCHASE_ORDER) transaction type.
View the item classes, mandatory attributes, and configuration variables.
Navigate to the Approvals Management Business Analyst responsibility.
Select the Business Analyst Dashboard menu.
Search for the Purchase Order Approval transaction type. In this example setup, you will use the predefined attributes. If required, you can create conditions based on your business requirements.
Create rules.
For example:
Approver Rule with following values:
Rule Type = List Creation
Category = Approver
Condition
Action Type = Supervisory level
Action = Require approvals up to the first superior.
Reviewer Rule with the following values:
Rule Type = Combination (While creating rule for reviewers, you must choose Combination: List Creation or Combination:List Modification rule type)
Category = Approver
Condition
Action Type = Production rule and Action = Reviewer/Yes (reviewer is identified through Production rule and the Reviewer/Yes action).
Action Type = approval-group chain of authority and select an appropriate Action value.
Signer Rule with the following values:
Rule Type = Post List Approver Group(while creating rule for signers, you must select the Post List Approver Group. All persons with this rule type are recognised assigners).
Category = Approver
Condition
Action Type = post-chain-of-authority approvals. Note that for approver and review rules, you can use any action type. But for signer, you must select post chain of authority approvals as the action type.
Create approver groups.
For example:
Approver group, where the voting method is Serial and select the approvers. Note that these are additional approvers, in addition to the people listed in the supervisor hierarchy.
E-signature group, where the voting method is Serial and select the individuals who have to provide the e-signature.
Review group, where the voting method is First Responder Wins and select the individuals who will review documents.
Test your setup using Test Workbench feature.
To complete setup steps in Oracle Purchasing
Navigate to the Purchasing responsibility.
Select Document Styles (Setup > Purchasing). You can create a document style or update an existing document style.
Navigate to the Document Controls region in the Create Document Style (StyleEditPG) or Update Document Style (StyleEditPG).
Ensure that you make the following selections to enable AME for a purchasing document. This example uses predefined values.
PO Approval in the Approval Workflow field.
PO AME Approval Top Process in the Workflow Startup Process field.
Purchase Order Approval in the AME Transaction Type.
After you complete these setup steps and when buyers click Approval Options for purchase orders or agreements, Oracle Purchasing displays the Approvers region (AME Approval region). Based on the setup, the Approvers region displays approvers, reviewers, and signers. In the Add Adhoc Approver region, buyers can select adhoc approvers or individuals for e-signature. They cannot select reviewers. Only if a person is added in the post or after post approval group, then that person is recognized as the signer. Therefore, buyers must select an existing signer and then add an individual before or after the existing signer using insertion point. Buyers can identify reviewers and signers in the Approvers region using the action type. Signers are associated with the post-chain-of-authority approvals action type. Reviewers are associated with the Production rule action type. Oracle Purchasing routes the document for review, approval, and e-signature based on the AME and workflow rules setup.