Oracle Purchasing enables you to approve awards, IDVs and modifications using a common process. When you complete your documents and are ready to start the approval process, click Submit in the Buyer Work Center to submit the document for approval.
If Owner Can Approve is enabled for the specific document type in the Document Types window and if you have the authority to approve the document, you can also approve the document.
When you select the Submit button in a document entry window, Oracle Purchasing performs submission checks to verify that the document is complete and in an appropriate state for the action you chose. Refer to the Document Submission Checks section in this chapter.
Oracle Approvals Management enables you to specify the approval rules for Oracle CLM Purchasing without having to write code or customize Purchasing. Once you define the rules, Purchasing communicates directly with AME to manage the approvals for business transactions.
The approvals management engine is now provided on top of the existing employee-supervisor and job-position approval hierarchies.
You can define the business rules that guide the approvals flow.
For more information on Approvals Management Engine, refer to the Oracle HRMS Approvals Management Implementation Guide.
For more information on setting up AME rules for CLM, refer to the Oracle Contract Lifecycle Management for Public Sector Implementation Guide.
You can also approve documents through the Notification Details web page, accessible through the Advanced Worklist option in Oracle Purchasing. The Notifications Summary page lists all the documents awaiting your approval, so that you can manage your pending approval queue and take approval actions. After opening a notification, you can drill down to the document itself, and review it and its action history. You can also modify the document if Approver Can Modify is enabled for the document type. After you modify a document, you need to return to the notification to take an approval action. You can also view and respond to notifications through email. Oracle e-Business Suite uses Oracle Workflow technology to route notifications through email. This way, an approver who has easier access to email than to the Purchasing application can view notifications and take approval actions.
Oracle Purchasing uses Oracle Workflow technology to handle the entire approval process. When you take an approval action in the Approve Document window or the notification, or through the Web or email, you are "submitting" the approval action to Workflow. Workflow works in the background, using the approval controls and hierarchies you've defined to route documents for approval. Because Workflow handles your approval process in the background, you can use Oracle Workflow Builder's easy interface to modify your approval process.
Use the Notification Details web page, accessible through the Advanced Worklist menu item in Oracle Purchasing, to manage your pending approval queue and take approval actions. After opening a notification, you can approve the document from the notification.
Oracle Purchasing offers the following document approval actions in the notification: Approve, Approve and Forward, Forward, Reject, Reassign and Request Information. You can also reassign a notification to somebody else.
Forward: Select Forward only if you want to forward the document to someone other than the next approver in the default Approval Path. If you select Forward, you must enter a Forward To person. If you don't select Forward, Purchasing will automatically route the document to the appropriate person in the Approval Path, if you're not the appropriate approver.
If the Forward To person is higher up in the default (or selected) Approval Path, but still does not have enough approval authority, Purchasing will continue the approval process with the next person in that Approval Path. If the Forward To person is not in the default (or selected) Approval Path, and also does not have enough approval authority, you will receive an Approver Not Found notification.
Reassign and Forward: To reassign a notification but still record you as the approver, select Reassign, and then select Transfer. To forward the notification so that the new approver is recorded in the action history instead of you, open the notification and select the Forward action (Do not use the Reassign/Transfer option).
Request Information: Ask for more information from any of the participants or to any users/other groups specified in the system. Clicking on the Request Information button opens the Request Information page that enables you to specify a workflow participant or a user in the system. Also enter your specific request for the information that you need and then click Submit.
The document details are displayed with the header information at the top and the line details below. The Approval Sequence is also displayed, along with the Action History.
Using the References region, you can edit or view the CLM document using either of the links:
Edit Document: From a notification that you have opened, you can also drill down to the document and modify it if Approver Can Modify is enabled for the document type.
Note: After you modify a document opened through the notification, you must return to the notification and select Approve there, not in the document itself, so that Purchasing can record your approval action and continue with or complete the approval process.
View Document Details: View the CLM document in read-only mode, once you have completed viewing the document, return to the Notification Details page by clicking the Notification Details link at the top of the view-only page.
The Response region enables you to enter a response, giving reasons for your decision (Approve or Reject). You can forward this to users in the system or any other group that has been specified.
The Bilateral Indicator field on the CLM document is provided to ensure that the vendor and the agency sign on the CLM document before the document is considered legally binding. The fields relevant to capturing the bilateral signature information for the CLM document are:
Bilateral Indicator: This is an indicator stating that the award is bilateral, that is, both the government and vendor parties must sign before the award is considered legally binding. If the award selected as bilateral, then there must be a record of having received vendor signature or acknowledgment of the award before finally approving it in CLM. If the award is listed as bilateral, then the vendor signatory information must be completed before finally approving it in CLM. The predefined values for this field are None, Proxy Signature and Signature.
Number of Signed Copies: If the supplier is required to sign the award, this free-text field indicates the number of (hard copy) copies to return to the contracting office.
When a buyer submits a document (an award, an IDV, or a modification) for approval, the relevant document submission checks are started, and the required error or warning messages are displayed. All errors must be resolved before the document can be successfully submitted. However, warnings may be bypassed after review by the buyer depending on current business considerations.
An approver can edit a CLM document (award, IDV, or Modification) using the Edit Document link in the approval notification, and then submit the document for approval. The same submission checks occur as a buyer submits the document for approval. Submission checks are started when the approver clicks OK in a notification. All errors need to be resolved before the document can be successfully submitted. However, warnings may be bypassed after review by the approver.
The following table lists the Document Submission Check Rules for CLM document approval:
Submission Check Rules | Awards | IDVs with Lines | IDVs without Lines | Modifications |
---|---|---|---|---|
Change Description has been generated and up to date | N | N | N | Y |
Standard Form & Document Format are not null and not expired | Y | Y | Y | Y |
Order Amount is within the Min Total Amount and Max Total Amount range of Source IDV | Y | N | N | Y |
Max Ceiling Award Amt is less than Max Per Order Amount or Total Line Amount is Max Per Order Amount | N | Y | Y | Y |
Effective Date for all Lines is between Order Start Date and End Date | Y | N | N | Y |
Line min start date is greater than Header start date and Line max end date is less than Header end date | N | Y | N | Y |
Header Effective Date can be less than or equal to the Need-By Date of all the shipments | Y | Y | N | Y |
Line quantity should not be null if either of these is not null: Minimum Per Order Qty, Maximum Per Order Qty, Maximum Total Qty, Minimum Total Qty | N | Y | N | Y |
Line amount should not be null if either of these is not null: Minimum Total Amount, Maximum Total Amount, Minimum Per Order Amount, Maximum Per Order Amount | N | Y | N | Y |
Total quantity of all PO Lines sourced to IDV should be between IDV Lines' min and max per order quantity | Y | N | N | Y |
Total quantity of all Lines of the same IDV lines across all POs which reference that IDV line should be less than IDV Lines' max total quantity | Y | N | N | Y |
Total amount of all Lines of the same IDV lines across all POs which reference that IDV line should be between IDV Lines min and max order amount | Y | N | N | Y |
Purchase Order Vendor should not be on hold | Y | Y | Y | Y |
Vendor is not null | Y | Y | Y | Y |
Vendor Site is not null | Y | Y | Y | Y |
Ship to Location is not null and is valid for priced lines only | Y | Y | Y | Y |
Invoice Office is not null and is valid | Y | Y | Y | Y |
Currency Code is not null | Y | Y | Y | Y |
Rate is not null if PO currency is not SOB currency | Y | Y | Y | Y |
Currency Rate Type cannot be "User" if the document contains any Lines with Value Basis of "Rate" | Y | Y | Y | Y |
Purchase Order should not be on hold | Y | Y | Y | Y |
Vendor should be valid | Y | Y | Y | Y |
Vendor Site should be valid | Y | Y | Y | Y |
Vendor Contact should be valid | Y | Y | Y | Y |
If acceptance is required for a document then there must exist a valid vendor contact with valid user name associated with it | Y | Y | Y | Y |
Header must have at least one line | Y | Y | N | Y |
Each Purchase Order Line must have at least one shipment (except Informational Lines) | Y | N | N | Y |
Quantities/Amounts between Purchase Order Line and Shipments must match | Y | N | N | Y |
The rate cannot be NULL for the distribution if we are using a foreign currency | Y | N | N | Y |
If using functional currency then rate has to be null | Y | N | N | Y |
The amount of all standard purchase orders for a contract should not exceed the amount limit of the contract | Y | N | N | Y |
Any of the standard PO's lines should not reference an unapproved contract | Y | N | N | Y |
Any of the standard PO's lines should not reference a contract whose vendor is different than the one on PO header | Y | N | N | Y |
Invalid Interclass conversions between UOMs should not be allowed | Y | N | N | Y |
If an item is restricted then the Purchase Order Vendor must be listed in the Approved Suppliers List table and must be approved | Y | N | N | Y |
If an item is restricted then the Purchase Order Vendor must be listed in the Approved Suppliers List table and must not be DEBARRED | Y | N | N | Y |
Contract referenced on a PO line should not be on hold | Y | N | N | Y |
ATO/CTO Model items not allowed on POs | Y | N | N | Y |
Item at Line and Shipment levels should be valid for purchasing | Y | Y | N | Y |
Either Promised Date or Need by date is required for planned items | Y | N | N | Y |
Ship to Location for shipments should be valid | Y | N | N | Y |
The Funded Value of the PO distribution should not be greater than its corresponding Total Order Value | Y | N | N | Y |
The IDV should be enabled for purchasing in the current OU | Y | N | N | Y |
IDV should be approved | Y | N | N | Y |
IDV should not be on hold | Y | N | N | Y |
The vendor on the PO should match the IDV | Y | N | N | Y |
The vendor site on the PO should match a vendor site on one of the IDV's enabled org assignments | Y | N | N | Y |
The PO Effective Date should be before IDV or corresponding Line expiration date | Y | N | N | Y |
The Need-by-date (or if NULL, the PO creation date) should be after the start dates of the IDV | Y | N | N | Y |
Currency Code on the PO should match the IDV | Y | N | N | Y |
The total amount on all the standard PO SHIPMENT lines in the current setup referencing the same IDV should be less than the amount limit on the IDV header | Y | N | N | Y |
The total amount on all the lines on the standard PO referencing same IDV line should be greater than the minimum release amount on the IDV line | Y | N | N | Y |
Current OU should be enabled for purchasing on the Global Contract being referenced | Y | N | N | Y |
Supplier Site should be a purchasing site defined in Global Contracts Org Assignments | Y | N | N | Y |
Amount Released should not exceed the amount limit on the Global Contract | Y | N | N | Y |
Effective Date range on the price break is within the Effective Date range of the Header and before the Expiration Date of the line | N | Y | N | Y |
Expiration Date on the line is within the effective range of the header | N | Y | N | Y |
ACRN value should be valid, should use alphanumeric code (excluding I & O and each charge account (line of accounting) should have a unique ACRN | Y | N | N | Y |
The sum of distribution amounts can be less than or equal to the total shipment (schedule) amount. | Y | N | N | Y |
The requisition distribution fund amount should be greater than the award distribution fund value. Otherwise an error is displayed. | Y | N | N | Y |
The total of distribution amounts for individual schedules should be less than or equal to the Schedule Amount. | Y | N | N | Y |
The sum of distribution quantities for individual schedules should be less than or equal to the Schedule Quantity. | Y | N | N | Y |
The PO Charge Account field should not be blank for a distribution. | Y | N | N | Y |
If the document contains orphan exhibits, the document cannot be approved. | Y | Y | N | Y |
Note: Modification Merge is performed during the approval of a modification. At this time, the modification is synced with the approved document and validation is performed.
While there are several submission checks that an award autocreated from a MIPR has to go through, the most important document submission checks for the award are as follows:
Header Level Errors:
The award has been autocreated from a MIPR-Own: FPDS-NG Reporting Method must be set to Exempt.
The award has been autocreated from a MIPR-Own: Communication Method must be set to None.
The award has been autocreated from a MIPR-Own: Bilateral Indicator must be set to None.
Header Level Warnings:
Multiple MIPR-Own are referenced on the award.
PR/PAR and MIPR-Others are referenced on the award.
MIPR-Others belonging to different requesting agencies are referenced on the award.
Distribution Level Errors:
A MIPR-Own reference is found in the Line, Schedule, and Distribution of this award; however, the award also references a MIPR-Own of another assisting agency.
A MIPR-Own reference is found in the Line, Schedule, and Distribution of this award; however, the award also references a PR/PAR/MIPR-Others.
A MIPR-Own (Direct Citation) reference is found in the Line, Schedule, and Distribution of this award; however, the award also references MIPR-Own (Reimbursement Order).