This program is used in the accrual reconciliation process to populate the accrual reconciliation table with all the necessary transaction data. Running this program is normally the first step in that reconciliation process. See: Accrual Write-Offs.
After you have entered your receipt transactions, matched and approved your accounts payable invoices, you will need to run the accounting process that creates the accounting for these transactions in the final mode and subsequently transfer these transactions to the general ledger. You can then begin the accrual reconciliation process by running the Accrual Reconciliation Load program. This program is used to populate the accrual reconciliation table with all the necessary transaction data for you to perform the reconciliation process. The program can be run for an operating unit incrementally.
The program parameters, from date and to date, can be used to run the load incrementally. These two dates represent the transaction dates that are used to fetch the transaction information from the transaction tables. All the affected PO distributions (in the case of AP/PO transactions and individual transactions in the case of miscellaneous transactions) will be deleted first and the transaction information for these distributions will be fetched and loaded into the accrual reconciliation tables. The data in the accrual reconciliation table will be regenerated only for the specified date range; the rest of the data will remain as is.
When the accrual load program is run for the first time for a given operating unit, old write off transactions for that operating unit (write offs from prior releases) are upgraded and loaded into the new accrual reconciliation tables. The “from date” for this very first run is ignored and the load runs from the start of transaction history to the current system date (or the “to date” provided by the user). Additionally, you cannot reverse write off transactions that were written off in prior releases.
Since this process loads transactions from purchase order receipts and accounts payable invoices, you must install Oracle Purchasing and Payables to run this report.
In the Submit Requests window, select Accrual Reconciliation Load Run in the Name field.
Select the operating unit for which you want to load accrual data.
This is the first date from which the data will be rebuilt. You can schedule this program to run on a repeated basis, which will automatically update the from and to date parameters. If the program is scheduled to run every month, then the from and to date parameters will be automatically updated to reflect the first and last date of that month.
This is the last date from which the data will be rebuilt.
Related Topics
Overview of Receipt Accounting
The ASL Upgrade process performs the same upgrade of AutoSource rules as AutoInstall, when you upgrade from Release 10.7. AutoSource rules in Release 10.7 and earlier have been replaced by enhanced sourcing rules and Approved Supplier List (ASL) entries in this release. Both AutoInstall and the ASL Upgrade process are designed to upgrade old AutoSource rules.
Run this process only if AutoInstall failed to upgrade your AutoSource rules automatically.
In the Submit Requests window, select ASL Upgrade in the Name field.
Select a Supplier Status of New. This Supplier Status appears next to all of your suppliers in the Approved Supplier List window once the ASL Upgrade process upgrades your ASL entries. New is the only Supplier Status supported by the ASL Upgrade process.
Select Current and future rules. This option upgrades source documents with current effectivity dates as well as effectivity dates that don't begin until the future. Current and future rules is the only option supported by the ASL Upgrade process.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Oracle E-Business Suite Upgrade Manual
The Self-Service PruchasingConfirm Receipts Workflow Select Orders process in Purchasing must be running in order to use the Confirm Receipts workflow. The Confirm Receipts workflow sends notifications through the Web, e-mail, or Notification Details Web page (accessible through the Notifications Summary menu in Purchasing) to requestors or buyers who create requisitions in Purchasing or iProcurement. It lets people know they should have received an item.
The Confirm Receipts workflow sends notifications for items with a Destination or Deliver-To Type of Expense, a Routing of Direct Delivery, and a Need-By date that is equal to or later than today's date.
Submit the Workflow Background Engine before you submit the Confirm Receipts Workflow Select Orders process. In the Submit Requests window, in the System Administrator responsibility, select Workflow Background Engine in the Name field. See: To Schedule Background Engines, Oracle Workflow Guide.
To submit the Confirm Receipts Workflow Select Orders process:
Navigate to the Submit Requests window and select Confirm Receipts Workflow Select Orders in the Request Name field.
Choose Schedule.
Choose how often you want the process to run.
For example, choose Periodically if you want the process to run periodically. If you set it to run one or two times a day, the Confirm Receipts workflow will query for purchase orders that meet the criteria described above and send notifications (if required) one or two times a day.
Choose OK, or select other options and then choose OK.
Choose Submit to begin the process.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Use the Create Internal Sales Orders process to send requisition information from approved, inventory-sourced requisition lines to the Order Management interface tables. Then the OrderImport process is run from within Order Management to generate the internal sales orders. You can set the Create Internal Sales Orders and OrderImport processes to run automatically at specified intervals.
The Create Internal Sales Orders process automatically schedules internal orders by setting the Schedule Ship Date on the order to the request date. If a subinventory is specified on the internal requisition line, Order Management reserves the goods and uses only the specified subinventory for allocation. If the goods do not exist at the specified subinventory, Order Management backorders them, even if they do exist in another subinventory.
The Create Internal Sales Orders process loads the Order Management open interface, OrderImport, using the order type you define in the Purchasing Options window. OrderImport creates internal sales orders from the records in the interface table, and determines the order cycle and defaults values based on the order type.
To run the Create Internal Sales Orders process:
Navigate to the Submit Requests window.
Select Requests in the first field.
Select Create Internal Sales Orders in the Name field.
Choose Submit to begin the process.
Related Topics
Creation of Internal Sales Orders
Submitting a Request, Oracle Applications User's Guide
Defining Internal Requisition Options
Use the Create Releases process to create releases for requisition lines that meet the following criteria:
Approved (and Reserved, if requisition encumbrance is active)
Requisition is already sourced to an existing blanket purchase agreement (not a global agreement)
Item is populated on the requisition line (one-time items not released)
The Approved Supplier List entry for the item, supplier, and blanket indicate that the Release Generation method is either Automatic Release or Automatic Release/Review
The requisition line is not already on a purchase order
The source blanket is still active and the release will not put the blanket over the amount limit.
If the release generation method is Automatic Release, the process sets the status to Approved.
You can set the Create Releases process to run automatically at specified intervals.
To run the Create Releases process:
Navigate to the Submit Requests window.
Select Requests in the first field.
Select Create Releases in the Name field.
Choose Submit to begin the process.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Use the Fill Employee Hierarchy process to create a direct mapping between the defined position hierarchies and the employees holding positions in each hierarchy. When you run this process, it checks each position hierarchy and updates each employee, his supervisor, the level of supervision (a direct supervisor is level 1), the employee's position, and the supervisor's position.
The process creates an error log which lists all positions to which no employee is assigned, but having such positions is a benign error that does not hamper system operation.
If you do not use hierarchical security for any of your documents and do not use position hierarchies for your approvals, you do not need to run this process. Otherwise, you must run this process before any of the following changes can take effect:
add or delete an employee
change an employee name or an employee position. See: Enter Person, Oracle HRMS Enterprise and Workforce Management Guide.
add, delete, or modify a position. See: Representing Jobs and Positions.
add, delete, or modify a position hierarchy. See: Representing Jobs and Positions, Oracle HRMS Enterprise and Workforce Management Guide.
To run the Fill Employee Hierarchy process:
Navigate to the Submit Requests window.
Select Requests in the first field.
Select Fill Employee Hierarchy in the Name field.
Choose Submit to begin the process.
Related Topics
Submitting a Request, Oracle Applications User's Guide
This program automatically creates or updates Sourcing Rules and ASLs (Approved Supplier List) for a blanket purchase agreement. The program acts upon documents which have the archival option set to Archive on Approve.
Features:
Can specify the default assignment set and the blanket agreement, supplier and supplier site for which the sourcing rules or ASLs need to be created or updated.
Create global or local sourcing rules and ASLs:
Global: Create a sourcing rule that is enabled in all organizations and is assigned at the item level. Create a global ASL.
Local: Create a sourcing rule that is specific to the inventory organization selected. Create a Local ASL and associate the blanket agreement to the specific inventory organization.
Create or update sourcing rules or ASLs for all lines or for new lines (entered since the previous archive) only.
Exceptions:
The program inserts all Blanket Lines for which a Sourcing Rule or ASL was not created into the Purchasing Document Interface Errors table, with the appropriate reason. This enables the buyer to identify and fix the errors if required before resubmitting the program. The buyer can submit the Purchasing Document Interface Errors Report for source type of PO_DOCS_OPEN_INTERFACE to view the errors.
Navigate to the Submit Requests window and select Document Sourcing Rules Creation Process in the Name field.
Select an active supplier who has at least one valid purchasing site in the current operating unit.
Select a blanket purchase agreement for the selected supplier that is approved and is not cancelled, closed, finally closed, frozen or on hold. Global agreements must be owned by the current operating unit or the current operating unit must be the procuring organization.
If you selected a global blanket agreement, select an organization listed as Purchasing Organization on the agreement.
Select either: All Lines or New Lines.
Select a Purchasing Site for the global blanket agreement.
Select an Assignment Set.
Select either: Item or Item-Organization.
If you selected a Sourcing Level of Item-Organization, select an Inventory Organization.
Enter a name to update the sourcing rule name or for the given supplier, supplier site and item combination.
Select one of: Automatic Release/Review, Automatic Release, or Release Using Autocreate.
Related Topics
Overview of Approved Supplier List
Submitting a Request, Oracle Applications User's Guide
The Import Price Catalogs process imports price/sales catalog information and responses to requests for quotation (RFQs) electronically from suppliers in the form of blanket purchase agreements or catalog quotations. There are several ways you can import agreements and quotations into Oracle Purchasing.
Use the e-Commerce Gateway to import the electronic catalog information into the Purchasing Documents Open Interface. The Import Price Catalogs program then validates the information before importing it into Purchasing. When using the e-Commerce Gateway (EDI 832 or EDI 843 transactions) you have the option of running the Import Price Catalogs program either from within the gateway by choosing Import Programs from the menu, and entering the parameters or running the Import Price Catalogs program from Oracle Purchasing.
The other way to import agreements and quotations is to use a custom program to import the electronic catalog information into the Purchasing Documents Open Interface and then run the Import Price Catalogs program from Oracle Purchasing.
In the Submit Requests window, select Import Price Catalogs in the Name field.
Enter the default buyer name to be associated with the incoming documents.
Valid options are Blanket and Quotation. The option of Blanket directs Purchasing to create a blanket agreement from the price/sales catalog or quotation to be imported. The option of Quotation directs Purchasing to create a catalog quotation for the information to be imported.
Used with document type of Quotation to indicate a document sub type of Catalog for Response to RFQ to be imported. The document sub type of Bid Quotation is invalid for the transaction.
Used with the Price/Sales Catalog or Response to RFQ to indicate whether to update the item master with catalog item changes or add catalog items to the item master.
Indicate Yes or No on whether supplier sourcing rules should be created automatically during the Price/Sales Catalog and Response to RFQ import process. Yes means that Purchasing creates sourcing rules and Approved Supplier List entries from the supplier, item, and document information that the supplier sends.
If you choose Yes, make sure the Approval Status field for the submitted documents is Approved. Sourcing rules can be created only when the Purchasing documents have a status of Approved.
Enter desired status of Approved or Incomplete for the Blanket Agreements and Quotations to be created.
The following table shows the effects of the Approval Status you choose here on an agreement's or quotation's current status, when you import an Update price/sales catalog.
| Current Document Status | Import as Incomplete | Import as Approved |
|---|---|---|
| Incomplete | Document remains Incomplete | Document changes to Approved |
| Approved | Document remains Approved | Document remains Approved |
Used when Document Type is set to Blanket and Create Sourcing Rules is set to Yes. Select from the following three blanket release methods:
Automatic Release/Review: Purchasing automatically generates releases and forwards them for approval.
Release Using AutoCreate: Enables you to use AutoCreate to convert purchase requisitions into blanket releases for blanket purchase orders.
Automatic Release: Purchasing automatically generates approved blanket releases for items that are sourced to a single supplier.
Enter a valid batch ID, that is a unique identifier for the group of documents in this submission. If you don't enter a Batch ID, one is generated for you when the process runs.
Enter Yes here to indicate that you wish to create global agreements from the blanket agreements that you are importing.
Related Topics
Receiving Price/Sales Catalog Information Electronically
Running the EDI Price/Sales Catalog Inbound Program, Oracle e-Commerce Gateway User's Guide
Running the EDI Response to Request for Quotation Inbound Program, Oracle e-Commerce Gateway User's Guide
Submitting a Request, Oracle Applications User's Guide
The Import Standard Purchase Orders program enables you to import standard purchase orders from legacy systems into Oracle Purchasing. Oracle Purchasing provides an open interface that validates the purchase order information, and then the Import Standard Purchase Orders concurrent program imports it into Purchasing.
To use this feature, you must first use a custom import program to load the data into the interface tables. Once the data is loaded, the Import Standard Purchase Orders program is run from within Oracle Purchasing to validate and create standard purchase orders.
The PO Approval workflow can be initiated automatically from the Import Standard Purchase Orders concurrent program. This eliminates the need to individually query each imported purchase order and submit it for approval. Additionally, Oracle Purchasing supports importing standard purchase orders of an approved status from legacy systems. This eliminates the need for any further approval processing for imported standard purchase orders.
In the Submit Requests window, select Import Standard Purchase Orders in the Name field.
Enter the default buyer name to be associated with the incoming documents that are not assigned to a buyer..
If a default buyer is not specified and the imported purchase order also does not have buyer information, the program will use the normal Purchasing defaulting mechanism to generate buyer information. If the buyer name provided in the interface is not valid, then the record will error out and the default buyer name will not be supplemented.
The valid response is Yes or No. If Yes, the program will also create items in the item master from those buyer part numbers in the interface data where there is no corresponding item master entry. If No, the program will not create new item master entries.
For purchase orders, you must choose either Approved, Incomplete, or Initiate Approval. The impact of this parameter on the import logic is explained in the table below:
| Document Status in Interface Table | Concurrent Program Approval Status Parameter | Resulting Document Status |
| Null | INCOMPLETE | INCOMPLETE |
| Null | APPROVED | APPROVED |
| Null | INITIATE APPROVAL | INITIATE APPROVAL |
| INCOMPLETE | INCOMPLETE | INCOMPLETE |
| INCOMPLETE | APPROVED | INCOMPLETE |
| INCOMPLETE | INITIATE APPROVAL | INITIATE APPROVAL |
| APPROVED | INCOMPLETE | APPROVED |
| APPROVED | APPROVED | APPROVED |
| APPROVED | INITIATE APPROVAL | APPROVED |
You can import Standard purchase orders with an INCOMPLETE status and then automatically initiate the PO Approval Workflow for these imported documents. Specifying a status of Incomplete or leaving the status Null in the interface data, and specifying a value of Initiate Approval for the Approval Status runtime parameter can achieve this.
Standard purchase orders can also be imported with an APPROVED status. Specifying a status of Approved in the interface data or leaving the status Null in the interface data, and specifying a value of Approved for the Approval Status runtime parameter can achieve this. The PO Approval Workflow is not initiated.
Enter a valid batch ID, that is a unique identifier for the group of documents in this submission. If you don't enter a Batch ID, one is generated for you when the process runs.
Related Topics
Submitting a Request, Oracle Applications User's Guide
This program has been designed to streamline the process of maintaining organizational changes. You may have to change the person name (buyer, approver, deliver-to) on existing purchasing documents. The Mass Update of Purchasing Documents program updates person information on Oracle Purchasing documents from a previous (old) person to a new person.
The following Purchasing documents will be updated:
Standard Purchase Order
Blanket Purchase Agreements
Blanket Releases
Planned Purchase Orders
Planned Releases
Contract Agreements
You can run the Mass Update of Purchasing Documents program from within Purchasing. Documents will remain in the same status after the person name update. Document revision and archival will not take place.
Mass updates can be done for documents with the following statuses: Approved, Requires Approval, Pre-Approved, Incomplete, Rejected, and In-Process. You cannot perform mass update for documents with a status of Cancelled, Finally Closed, Closed POs and Frozen POs.
A report is produced as output from the concurrent program. This report lists the document number and document type of the Oracle Purchasing documents that were updated by the program.
In the Submit Requests window, select Mass Update of Purchasing Documents in the Name field.
Select from All, Approver, Buyer, Deliver To.
Enter or select the person name that needs to be changed. This must be a person name that is currently in the system (active or inactive).
Enter or select the person name that is to be updated on all the documents that match the old person. This will show all the current persons except the one entered as the old person.
Select one of the following document types: All, Blanket Purchase Agreement, Contract Purchase Agreement, Planned Purchase Order, Standard Purchase Order. If Blanket Purchase Agreement is selected, then the updates are applicable for all the releases associated to the Blanket Purchase Agreement.
Enter the range of the document numbers for the documents that you want updated.
Enter the date range for which you want the documents to be updated.
Enter the Vendor (Supplier) Name. If this field is left blank, then the person name is updated for all suppliers.
Enter Yes or No, depending on whether you want to include closed Purchase Orders or Requisitions in the mass update.
Specify how many records should be updated before they are committed.
Note: This program is not intended to update action history or archive the information it is expected to change.
Related Topics
Submitting a Request, Oracle Applications User's Guide
You can perform mass update of purchase requisitions for Purchase Requisitions or Internal Requisitions that have the following statuses: Approved, Requires Approval, Pre-Approved, Incomplete, Rejected and In Process. You cannot perform mass updates of requisitions that have a status Cancelled.
A report is produced as output from the concurrent program. This report lists the document number and document type of the Oracle Purchasing documents that were updated by the program.
The parameters for the Mass Update of Requisitions are:
Select from the following persons in the dropdown LOV: All, Approver, Preparer, Requester.
Enter or select the person name that needs to be changed. This must be a person name that is currently in the system (active or inactive).
Enter or select the person name that is to be updated on all the documents that match the old person. This will show all the current persons except the one entered as the old person.
Select one of the following document types: All, Blanket Purchase Agreement, Contract Purchase Agreement, Planned Purchase Order, Standard Purchase Order. If Blanket Purchase Agreement is selected, then the updates are applicable for all the releases associated to the Blanket Purchase Agreement.
Enter the range of the document numbers for the documents that you want updated.
Enter the date range for which you want the documents to be updated.
Specify how many records should be updated before they are committed.
The Mass Close of Purchasing Documents concurrent program enables you to change the status of purchase orders to Closed. This is applicable to purchase orders that have been fully processed but which do not have a status of Closed. When you run the concurrent program, the purchase orders are mass closed completely (this includes headers, lines, shipments).
You can mass close purchase orders with the following statuses: Frozen, On Hold, Approved, Reserved, Requires Reapproval, Closed for Invoicing and Closed for Receiving.
You can mass close the following documents: Standard Purchase Orders, Blanket Purchase Agreements, Planned Purchase Orders and Contract Agreement and Blanket Releases. The parameters for running the concurrent programme are Document Type, Document number, Date range and Supplier Name.
A report is produced as output from the concurrent program. This report lists the document number and document type of the Oracle Purchasing documents that were updated by the program.
Payment on Receipt enables you to automatically create standard, unapproved invoices for payment of goods based on receipt transactions. Invoices are created using a combination of receipt and purchase order information, eliminating duplicate manual data entry and ensuring accurate and timely data processing. Payment on Receipt is also known as Evaluated Receipt Settlement (ERS) and Self Billing.
You can automatically create invoices with multiple items and distribution lines, and include tax.
You define which supplier sites participate in Payment on Receipt and enforce matching rules to ensure the proper payments are made to the suppliers.
Payment on Receipt builds invoices with the following information:
| Variable | Description |
|---|---|
| Amount | Determined by multiplying the Quantity received by the Purchase Order Item Unit Price. |
| Payment Terms | Defaulted from the purchase order payment terms or from the supplier site payment terms, depending on your Oracle Payables setup. |
| Tax | Based on Tax Codes on each purchase order shipment, or the default tax hierarchy in Payables. |
If the purchase order currency and the supplier site Payment Currency (in the Supplier Sites window) are not fixed-rate currencies (for example, not euro-related currencies), Payment on Receipt builds the invoices this way, regardless of the supplier site Invoice Currency:
| Variable | Description |
|---|---|
| Invoice Currency | Defaulted from the purchase order Currency. |
| Payment Currency | Defaulted from the purchase order Currency. |
If the purchase order currency and the supplier site Payment Currency are fixed-rate currencies (for example, euro-related currencies), Payment on Receipt builds the invoices this way, regardless of the supplier site Invoice Currency:
| Variable | Description |
|---|---|
| Invoice Currency | Defaulted from the purchase order Currency. |
| Payment Currency | Defaulted from the supplier site Payment Currency. For example, if the purchase order Currency is francs and the supplier site Payment Currency is the euro, the Payment Currency on the invoice is the euro. Defaulted from the supplier site Invoice Currency if no supplier site Payment Currency is defined and the supplier site Invoice Currency is a fixed-rate currency. Defaulted from the purchase order Currency if the supplier site Invoice Currency is not a fixed-rate currency. |
If the Alternate Pay Site is populated for the Supplier Site used on the Purchase Order, the invoice created is for the Alternate Pay Site, otherwise the Supplier Site on the Purchase Order is used. The Supplier Site used for the invoice must be defined as a Pay Site.
You can choose to automatically generate debit memos for Return To Supplier transactions once Payment on Receipt creates the invoice. To enable this functionality, enable the supplier site as a Pay Site (or indicate an Alternate Pay Site) and select Create Debit Memo from RTS Transaction in the Supplier Sites window. Once you enable this functionality, a debit memo is created for each return line you enter in the Returns window. When you create the return, make sure the Create Debit Memo option is selected in the Returns window. (The Aging Period profile option and field in Payment on Receipt do not account for returns for which a debit memo was already created, so that duplicate debits are not made. Likewise, a debit memo will not be created if the Aging Period functionality already handled the debit.) See: Debit Memos.
When Payment on Receipt runs, it automatically performs invoice matching to the purchase order or receipt, depending on which Invoice Match Option was chosen in the purchase order Shipments window. (The Invoice Match Option on the shipment defaults from the Supplier Sites window, but you can change it on the shipment.) See: Entering Purchase Order Shipments.
If matching invoices to receipts, Payment on Receipt uses the exchange rate information on the receipt. If matching invoices to purchase orders, Payment on Receipt uses the exchange rate information on the purchase order.
You can enable Payment on Receipt for individual purchase orders and releases, for any purchase order or release type, by using the Pay On field in the Terms and Conditions window. (The Pay On value on a blanket purchase agreement is defaulted onto all the releases created against it.) The Pay On field defaults to Receipt for all documents whose supplier site is set up as a Payment on Receipt site in the Supplier Sites window, meaning that Payment on Receipt creates the invoices. Changing the Pay On field to Null means that Payment on Receipt does not create an invoice for that document, even if the supplier site is a Payment on Receipt site. If the supplier site is not a Payment on Receipt site, the Pay On field is disabled. See: Entering Purchase Order Detail Information.
The Pay On field also shows up on the Printed Purchase Orders Report, so your supplier knows that you will create an invoice upon receipt, and the supplier does not need to submit an invoice.
You may want to allow time for corrections or returns against the receipts before using Payment on Receipt to automatically convert the receipts into invoices. The profile option PO: ERS Aging Period enables you to specify this delay period between the receipt date and the invoice creation date.
When you run Payment on Receipt, it processes only those receipts whose dates are past the aging period. Payment on Receipt invoices include the sum of all corrections or returns made against a receipt during that aging period. Any adjustments you make after that aging period, you must process manually-by adjusting the invoice itself, or creating a debit memo.
The aging period does not include returns for which debit memos have already been automatically created. See: Debit Memos.
Example
Your aging period is two days. You receive 100 items on Monday, but on Tuesday discover that two items were missing from the shipment. You enter a correction to adjust the amount received to 98. When run on Wednesday (or later), Payment on Receipt generates an invoice for 98 items.
See: Purchasing Profile Options.
You can find Payment on Receipt invoices by using the Find Invoices window in Oracle Payables to search for any invoice in your system containing the prefix 'ERS-.' However, you can change this prefix, using the profile option PO: ERS Invoice Number Prefix. For example, shortening this prefix allows extra spaces for longer packing slip or receipt numbers. See: Purchasing Profile Options.
Self-billing invoices (SBI) is an automated invoicing process where the buying company creates an invoice on behalf of the supplier. Oracle Purchasing supports gapless invoice numbering for all self-billing invoice types including: payment on receipt, debit memos, and purchase price adjustment. See: Define Document Control Options.
You can create a single invoice for one or more items on a single purchase order as long as the items have not been previously invoiced and matched to a purchase order or a receipt. If you are creating an invoice from the receipt transaction and purchase order, you are able to create an invoice for all ordered and received items. In the event of a partial shipment or multiple delivery dates, you are able to create multiple invoices for a single purchase order.
In addition, if your purchase order contains multiple distribution lines, you can create an invoice in Oracle Payables with the same multiple distribution lines.
When creating multiple distribution lines for invoices with partial receipt quantities, the Pay on Receipt AutoInvoice program will either prorate the charges across all your purchase order distribution lines (for the received item) or use the FIFO method if you utilize Cascading Receipts. After the invoice has been created, you are able to make changes to the invoice distribution in accordance with the current Oracle Payables system functionality.
Invoices created automatically are subject to the same match approval levels as standard invoices to ensure proper payment. Two-, three- and four-way match approval levels are enforced by Oracle Payables if you specify two-, three-, or four-way for the supplier site Match Approval Level. Two-way match approval is the process of verifying that the purchase order and invoice information match within accepted tolerance levels. Three-way match approval is the process of verifying that the purchase order, invoice, and receiving information matches within accepted tolerance levels. The three-way match approval level is available with the Receipt Required option.
Four-way match approval is the process of verifying that the purchase order, receipt, inspection, and invoice information matches within accepted tolerance levels. The four-way match approval level is available with the Inspection Required purchasing option.
Oracle Payables requires that you approve invoices before you create accounting entries for them or pay them. Approvals can be submitted for selected invoices in the Invoice Workbench or by batch process. All discrepancies and/or adjustments must be handled manually using the appropriate online Oracle Purchasing, Receiving, and/or Payables windows.
Payment on Receipt invoices include tax, which is based on each purchase order shipment and the setup in Oracle E-Business Tax. See: Tax Information in Purchasing.
Tax on Payment on Receipt invoices is not calculated until invoice approval in Oracle Payables, or until tax calculation is performed in the Invoice Distributions window in Oracle Payables.
Oracle Payables creates scheduled payments for each invoice based on the payment terms and the invoice terms date. After the invoice has been created, you can use the Scheduled Payments window to modify information such as due dates, and to change payment and discount amounts.
You can enter supplier information in the Suppliers and Supplier Sites windows to identify which of your suppliers are eligible for Payment on Receipt and can have their invoices automatically created using the Pay on Receipt AutoInvoice program. In addition, you can specify an alternate Payment on Receipt pay site if the supplier's pay site address is different from the purchasing address. For invoices created based on receipt transactions, you can set up invoice consolidation levels for an individual pay site. You also define the default Payment Currency in the Suppliers and Supplier Sites windows.
See: Defining Standard Suppliers, Oracle iSupplier Portal Implementation Guide.
The level of invoice consolidation determines how an invoice will be created for each run of Pay on Receipt AutoInvoice program. For invoices created based on receipt transactions, you set up invoice consolidation levels for an individual pay site in the Supplier Sites window. The levels are:
'Pay Site' -- one invoice is created per supplier pay site for all the transactions that have the same transaction date.
'Packing Slip' -- one invoice is created per packing slip per supplier pay site for all the transactions that have the same transaction date.
'Receipt' -- one invoice is created per receipt per supplier pay site.
Invoice numbers are created based on the summary level. The invoice number is of the following format:
'ERS'-< X >-< Seq# >
where:
- ERS is the default prefix for Pay On Receipt invoices or any prefix you specify in the profile option PO: ERS Invoice Number Prefix. See: Profile Options in Purchasing.
- Seq# is a unique system generated number.
- X depends on the summary level:
- if summary level = Pay Site then X = Invoice Date
- if summary level = Packing Slip then X = Packing Slip Number
- if summary level = Receipt then X = Receipt Number
If gapless self-billing invoice (SBI) numbering is enabled, the SBI buying company identifier and selling company identifier are included in the invoice number following the prefix as shown below. See: Self-Billing Invoices.
<Prefix>-<SBI Buying Company Identifier>-<Selling Company Identifier>-<Invoice Type Code>-<Seq #>
The Pay on Receipt AutoInvoice program automatically creates an invoice batch depending on the options in the Payables Options window. Invoice count and invoice total are calculated automatically.
Prerequisites:
The supplier and supplier site must be set up correctly. Specifically, the supplier site must be set up as a Pay on Receipt site.
Important: Check that the receipts that you are interested in have been created successfully before running this program. You can do this by locating the receipt in the Receiving Transactions Summary window.
See: Defining Standard Suppliers, Oracle iSupplier Portal Implementation Guide
Enter an Invoice Currency and a Payment Currency in the Supplier Sites window.
If you need to calculate tax on the invoices, enable Automatic Tax Calculation and set the Calculation Level to Line or Tax Code in the Supplier Sites window.
If the profile option Sequential Numbering is set to Partially Used or Always Used, ensure that document sequences have been defined for your invoices and have been set to automatic numbering. Otherwise, Payment on Receipt may not be able to complete because it cannot generate document numbers for the invoices. See: Common User Profile Options, Oracle Applications User's Guide. See: Voucher Numbers, Oracle Payables User's Guide.
To run Payment on Receipt:
Navigate to the Submit Requests window.
Choose Requests as the Type.
Choose Pay on Receipt AutoInvoice as the Name.
Choose the Transaction Source ERS.
Enter a Commit Interval. The Commit Interval is a numeric representation of the number of invoices evaluated before they are committed. For example, if you have a Commit Interval of 10, after 10 invoices have been processed, they are committed. If you then process another 5, and the process fails, only 5 will not be committed.
Optionally enter a Receipt Number.
Note: If the Receipt Number is null, the program will try to process all the receipts that have not been invoiced successfully. If you enter a Receipt Number, only that receipt will be processed.
Optionally enter an Aging Period.
The Aging Period defaults from the PO: ERS Aging Period profile option, but you can change it here. For example, an Aging Period of 2 means that Payment on Receipt processes only those receipts that are 2 or more days old.
Choose OK and then Submit Request to begin the process.
Make sure the Payment on Receipt process and the Payables Open Interface Import process complete successfully.
After this process completes, it calls the Payables Open Interface Import process to complete invoice creation. Therefore, note the following in the View Output screen for the Pay on Receipt process:
The Request ID for the Payables Open Interface Import process. Use this ID to check the status of the Payables Open Interface Import process to be sure it also completes successfully. If not, fix the errors in the Open Interface Invoices window and resubmit the Payables Open Interface Import process. See: Payables Open Interface Import, Oracle Payables User's Guide. See: Open Interface Invoices Window, Oracle Payables User's Guide.
The Group ID for the invoice batch number. If you need to query this invoice batch to fix errors, use the Group ID to query this invoice batch.
The PO Output for Communication process creates an Adobe Portable Document Format (PDF) of the purchase orders you specify. The PDF version of purchase orders are an electronically viewable format that you can share with your suppliers. Oracle Purchasing provides a default layout which can be customized. See: Printed Purchase Order Overview.
In the Submit Requests window, select PO Output for Communication in the Name field.
Select one of the following options:
| Variable | Description |
|---|---|
| All | Print the report for all purchase orders. This is the default for no entry. |
| Changed | Print the report only for changed purchase orders. |
| New | Print the report only for new purchase orders. |
Select a buyer name to restrict the report to a specific buyer.
To restrict the report to a range of purchase orders, select the beginning and ending numbers.
To restrict the report to a range of releases, select the beginning and ending numbers.
To restrict the report to a release date range, enter the beginning and ending dates.
Select Yes or No to indicate whether the report is restricted to approved purchase orders.
Select Yes or No to indicate whether the report is a test.
Enter Y or N to indicate whether you want blanket and planned purchase order releases to be automatically reported with the blanket and purchase order agreements.
Select one of the following options:
| Variable | Description |
|---|---|
| Buyer Name | Sort the report by buyer name and purchase order number. |
| Purchase Order Number | Sort the report by purchase order number. |
Enter Y or N to indicate whether you want backing blanket purchase orders printed with standard purchase orders.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Viewing Requests, Oracle Applications User's Guide
Use the Purchasing Database Administration process to initiate concurrent processes that purge obsolete records in Purchasing interface tables and other temporary tables. The purging of obsolete data helps reduce memory load and improve system performance. You need to run this process only once because the AutoSubmit process resubmits itself daily after you submit it the first time.
To run the Purchasing Database Administration process:
Navigate to the Submit Requests window.
Select Requests in the first field.
Select Purchasing Database Administration in the Name field.
Choose Submit Request.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Viewing and Responding to Notifications
The Purchasing Documents Open Interface process has been replaced with two separate processes.
Import Standard Purchase Orders
Use the Receipt Accruals - Period-End process to create period-end accruals for your uninvoiced receipts for Expense distributions. Purchasing creates an accrual journal entry in your general ledger for each expense distribution uninvoiced receipt you choose using this form. If you use encumbrance or budgetary control, Purchasing reverses your encumbrance entry when creating the corresponding accrual entry.
Important: When using Cash Basis Accounting, you should use the Purchasing Options window to set the Accrue Expense Items flag to Period End, but you will not normally run the Receipt Accrual - Period-End process. See: Defining Accrual Options.
Purchasing provides you with complete flexibility and control for your period-end accruals. You can use the Uninvoiced Receipts Report to analyze your uninvoiced receipts before you accrue them. You can then run the Receipt Accruals - Period-End process as many times as you want to generate accruals entries for the receipts (Vendor or Category) you choose. Purchasing does not accrue receipts for purchase orders on or before the last date of the Accrual Period.
You create accruals for a specific purchasing period. Purchasing automatically accrues all uninvoiced receipts you entered up to the end of the accrual period you specify. Each time you run the Receipt Accruals - Period-End process, Purchasing creates a batch in receiving subledger. It also creates accounting events in SLA. If you are using encumbrance, Purchasing creates another set of accounting events in SLA. Purchasing creates an unposted journal entries batch in your general ledger for your receipt accruals. If you are using encumbrance or budgetary control, Purchasing creates another journal entries batch in your general ledger corresponding to the encumbrance reversal entries for the uninvoiced receipts you accrued.
Each time you create accrual entries for a specific purchase order, Purchasing marks this purchase order as accrued and ignores it the next time you run the Receipt Accrual - Period-End process. Purchasing creates accrual entries only up to the quantity the supplier did not invoice for partially invoiced receipts.
Follow the steps listed below:
Identify the purchasing period for your receipt accrual entries. Purchasing creates receipt accruals for all receipts you entered up to the end of this period. To prevent any period-end disruption, Purchasing lets you provide a receipt date that is different from the date you enter the receipts. You never have to enter all the receipts for a period before the end of this period. You can enter these receipts later. You simply need to backdate the receipt date. Of course, you should make sure you entered all receipts for a specific period before you create receipt accruals for that period.
If you perform additional receiving activity to an item after a period is closed-for example, you return an item received in a previous period and re-receive it using a date in the current period-encumbrance and accrual entries for the item are made for the current, open period.
Enter and match all invoices you received during the period for your receipt accrual entries.
Close the accounts payable period corresponding to the purchasing period for your receipts accrual entries.
Run the Uninvoiced Receipts Report and analyze your uninvoiced receipts that are accrued at period end.
Run the Receipt Accrual - Period-End process as many times as you need. You can use the search criteria to choose what you want to accrue and accrue your receipts step by step. This process creates accounting accrual entries using the journal source 'Purchasing' and the journal category 'Accrual' in Receiving subledger.
Run Create Accounting – Cost Management for process category Receiving to create accounting in SLA.
Note: If you are using encumbrance then you don’t need to run the Create Accounting – Cost Management as Receipt Accruals – Period-End creates the accounting in SLA automatically.
Run Journal Import in General Ledger to import the receipt accruals journals from General Ledger into Purchasing. See: Importing Journals, Oracle General User's Guide.
Transfer to general ledger from SLA using Transfer Journal Entries to GL - Cost Management for Process Category Receiving. You can provide the general ledger batch name while transferring to general ledger.
Post Accrual and Encumbrance Reversal journal entry batches in your general ledger.
Perform all the steps you need to close your accounting period and generate period-end reports and financial statements in your general ledger.
Run the Accrual Reconciliation Report after period close to analyze your receipts accrued on receipt.
Use your general ledger system to reverse all the receipt accrual and encumbrance reversal batches for your period-end accruals.
Close the purchasing period for your receipt accruals. When you close a purchasing period, Purchasing automatically un-marks all the receipts you previously accrued to make sure you can accrue these receipts again if they are still uninvoiced in the next period.
Make sure the Close Purchasing Periods process completes before you open the next period. When you close a period in the Open and Close Periods window and then save, the Close Purchasing Periods process runs automatically. Make sure this process completes before opening the next period.
After you have opened your next period in General Ledger and have either closed the previous general ledger period or have completed all previous month receipt accruals, you can reverse the previous month's receipt accruals in the new month. You perform this by reversing each general ledger journal batch in General Ledger.
Run Complete Multiperiod accounting which automatically reverses the accrual entries on the first day of next period.
To run the Receipt Accruals - Period End process:
Navigate to the Submit Requests window.
Select Requests in the first field.
Select Receipt Accruals - Period-End in the Name field.
Enter the Minimum Accrual Amount.
For example, if you do not want to accrue amounts less than $.10, enter .10. In this example, an accrual of .09 or less will not be created. Any accrual amount of .10 or greater will still be accrued. The default minimum accrual amount is 0, meaning all amounts are accrued.
Enter the Supplier to restrict period-end receipt accruals to a single supplier.
Enter the item Category to restrict period-end receipt accruals to a single category.
Enter the Period for which you want to perform period-end receipt accruals. Purchasing automatically provides you with a list of acceptable accrual periods. This list contains periods that you closed in your accounts payable system and either opened or did not use in your general ledger system.
Choose Submit to begin the process.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Use the Receiving Transaction Processor to process your pending or unprocessed receiving transactions. How the Receiving Transaction Processor handles these transactions depends on the processing mode, which is a profile option that you can set at the site, application, responsibility, and user levels.
In On-line processing mode, Purchasing calls the Receiving Transaction Processor when you save your work.
In Immediate processing mode, when you save your work, the receiving forms call the Receiving Transaction Processor for the group of transactions you have entered since you last saved your work. Note that this is a specific group of transactions. Transactions belonging to other groups (for example, those entered by another user in Batch processing mode) are not included.
In Batch processing mode, the receiving forms insert transaction information into the receiving interface tables. These transactions remain in the interface table until you run the Receiving Transaction Processor. The receiving forms take into account all pending transactions, but Purchasing does not update the transaction history, source documents, and supply information until the transactions are processed.
You can set Standard Report Submission parameters to run the Receiving Transaction Processor at specified intervals so that your pending transactions are processed as often as required.
The Receiving Transaction Processor performs the following functions:
validates Advance Shipment Notice (ASN) and Advance Shipment and Billing and Notice (ASBN) information in the receiving open interface
derives and defaults values into the receiving interface tables (For example, if a particular value or field is not received, the receiving open interface tries to derive the value using defaulting and derivation rules.)
creates receipt headers for intransit shipments
creates receipt lines for all receipts
maintains transaction history information
maintains lot and serial transaction history
accrues uninvoiced receipt liabilities
maintains the following purchase order quantities: quantity received, quantity delivered, quantity accepted, and quantity rejected
closes purchase orders for receiving
maintains the following requisition quantities: quantity received, quantity delivered
maintains supply information
maintains inventory information (for Inventory destination type)
maintains outside processing information (for Shop Floor destination type)
To run the Receiving Transaction Processor:
Navigate to the Submit Requests window.
Select Requests in the first field.
Select Receiving Transaction Processor in the Name field.
Choose Submit to begin the process.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Use the Requisition Import process to import requisitions from other Oracle or non-Oracle systems. Work in Process, Master Scheduling/MRP, Order Management, and Inventory (as well as custom systems) can provide requisition information for the Purchasing requisition interface table. For example, drop-ship orders from Order Management and Kanban orders from Inventory are sent to the requisition interface table and converted into requisitions. Also, project and task information from Master Scheduling/MRP are imported through the Requisition Import process. Requisition Import creates a requisition line and one or more requisition distributions for each row it finds in the interface table. It then groups these lines on requisitions according to parameters you define below.
You can set the profile PO: Release During ReqImport to create releases each time you run the Requisition Import process. For example, when you implement planned orders as requisitions in the MRP Planner Workbench, you can automatically create the releases at the same time you create the requisitions. Purchasing automatically creates (and optionally approves) the releases for all blanket-sourced, approved requisitions as part of the Requisition Import process, not just those created by the Requisition Import run.
You can place requisitions you imported on purchase orders just as you would any other requisition. Purchasing automatically sources your requisition line to a blanket agreement or catalog quotation number if the supplier for the item is in the Approved Supplier List and if sourcing rules are set up for the item.
Each requisition you create using Requisition Import enters Purchasing with the approval status that was specified when the row in the interface table was created. However, if you are using requisition encumbrance (the Use Requisition Encumbrance field in the Encumbrance Information region of the Financials Options window is set to Yes), Requisition Import changes the Approved status to Pre-Approved, and you must approve the requisitions.
Note: A Pre-Approved requisition does not show up as supply until its status changes to Approved. See: Approved Documents and Supply.
For Incomplete and Pre-Approved requisitions, Requisition Import calls the PO Requisition Approval workflow to submit the requisitions to the approval process unless you specify not to when you submit Requisition Import. For Approved requisitions, Requisition Import calls the PO Create Documents workflow in Purchasing to automatically create corresponding purchase orders, and the PO Create Documents workflow then calls the PO Approval workflow to approve the purchase orders, if you've enabled automatic creation and approval. See: Choosing Document Creation Options.
When you submit the Requisition Import process, Purchasing automatically prints the Requisition Import Run Report. You can view this report by using the View Requests window and choosing the Report option in the View field for the Requisition Import process you submitted. If there were no records in the transaction interface table, the report has two lines:
No records were processed
Number of records in error = 0
Otherwise, the report normally has three lines:
Number of approved requisitions created = n
Number of unapproved requisitions created = n
Number of records in error = n
When there are transaction records that cannot be processed, the report includes a fourth line:
Number of records pending = n.
Enter the Import Source. Leave this field blank for all import sources.
If you do not see a particular import source in the list of values, there are currently no requisitions from that source.
Enter the Import Batch Identification for the batch that you want to import. Leave this field blank to import all batches.
Use the Group By feature to determine how requisition lines are grouped on the requisitions you create. The default in this field is set in the Purchasing Options window. Choose one of the following options:
All: Group all requisition lines on one requisition
Buyer: Group requisition lines for each buyer name on a separate requisition
Category: Group requisition lines for each purchasing category on a separate requisition
Item: Group requisition lines for each item on a separate requisition
Location: Group requisition lines for each location on a separate requisition
Supplier: Group requisition lines for each supplier name on a separate requisition
Enter the Last Requisition Number that exists in your system. Purchasing increments this number by one to calculate the next requisition number. If the calculated number is already in use, Purchasing selects the next available requisition number. Leave this field blank to automatically get the next available requisition number.
Choose No for Multiple Distributions.
In a previous release, the Import Source of ICX (for Web Requisitions) required you to choose Yes. This release supports iProcurement, which saves its requisitions directly to the Purchasing tables rather than using Requisition Import. Therefore, Yes is no longer a valid option for Multiple Distributions.
Choose whether to initiate approval automatically for the requisitions after they are imported.
Yes: The PO Requisition Approval workflow is launched automatically for requisitions imported with a status of Pre-Approved or Incomplete.
No: The PO Requisition Approval workflow is not automatically launched for Pre-Approved or Incomplete requisitions. You can submit these to the approval process later, when you select the Approve button on the requisition.
Choose Submit to begin the process.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Viewing Requests, Oracle Applications User's Guide
Demand for Internal Requisitions
Workflow for Creating Purchase Orders and Releases
Purchase Order Approval Workflow
The Reset Period End Accrual Flags program resets the accrued flag on purchase order distributions preparing them for the next run of the Period End Accrual process. This program can be run for specific operating units to reset their accrued flags.
The Reset Period End Accrual Flags program is to be used by organizations that have a multi-org setup. The Close Purchasing Period program only updates the accrued flag for the operating unit it is run in. With the Reset Period End Accrual Flags program you can update the accrued flag for the other operating units within the organization.
For organizations using a single operating unit, the Close Purchasing Period program itself resets the accrued flag and would be the only program you need to run.
In the Submit Requests window, select Reset Period End Accrual Flags in the Name field.
None.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Use the Reschedule Requisitions process to update requisition information for the rows that Master Scheduling/MRP has inserted into the rescheduling interface table. This information can include changes to need-by dates recommended by MRP as well as changes to requisition quantities made by means of the Planner's Workbench.
To run the Reschedule Requisition process:
Navigate to the Submit Requests window.
Select Requests in the Type field.
Select Reschedule Requisitions in the Name field.
Choose Submit to begin the process.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Overview of Implementing Planning Recommendations, Oracle Master Scheduling/MRP and Supply Chain Planning User's Guide
If Oracle Services Procurement is implemented and contract workers enter their time through Oracle Time and Labor, use this process to generate receipts for the recorded time. You can complete the procure-to-pay flow by running the Pay on Receipt process.
This process loads the time transactions into the Receiving Open Interface and then the Receiving Transaction Processor is automatically launched to import the receipts.
In the Submit Requests window, select Retrieve Time from OTL in the Name field.
Related Topics
Submitting a Request, Oracle Applications User's Guide
Over the life of purchasing documents prices can change. The Retroactive Price Update on Purchasing Documents concurrent program automatically updates existing blanket releases and standard purchase orders retroactively with price changes from the parent blanket agreement or global purchase agreement. Other changes can include updates to price breaks quantities, ship-to organization or location, new price breaks, and deletion of existing price breaks.
Considerations:
The Retroactive Price Update on Purchasing Documents concurrent program updates the prices of your purchase orders or releases based on the profile PO: Allow Retroactive Pricing.
It does not update the prices if your purchase orders or releases have any encumbrances associated with them.
It does not process documents associated with blanket agreement lines that are cumulatively priced.
When buyers with edit access to global agreements execute this concurrent program, it updates documents in all enabled operating units.
It only considers price updates from lines of blanket agreements that are currently in the following statuses:
Approved
Closed
Blanket releases or standard purchase orders in the following document statuses are not considered for update:
In Process
Pre-Approved
Reserved
Frozen
Finally Closed
Canceled
It updates following Oracle Purchasing documents:
Standard Purchase Orders against Global Agreements
Blanket Releases
The Retroactive Price Update on Purchasing Documents program uses your parameter values to retrieve blanket agreement lines that have undergone price changes (it ignores cumulatively priced lines) as well as the release shipments created against these lines. It then updates shipments with any new prices from the blanket agreement and update the timestamp information on release shipments with that of the blanket agreement line. For standard purchase orders against global agreements, the timestamp information is stored at the purchase order line level and is updated with that of the global agreement line. Purchasing documents that were in an approved status prior to the update can be automatically submitted for re-approval.
Prerequisites:
Set the profile option PO: Allow Retroactive Pricing of POs to Open Release Only or All Releases. See: Profile Options and Security Functions.
The PO Change Order Workflow must be configured to allow automatic re-approval of the updated releases and purchase orders. See: Workflow Processes for Approving Change Orders.
In the Submit Requests window, select Retroactive Price Update on Purchasing Documents in the Name field.
Enter or select the supplier whose pricing needs to be updated. This must be a supplier that is currently in the system.
Enter or select the supplier site.
Enter a specific blanket or contract agreement number for which you want the pricing updated.
Enter a range (from and to) of item numbers for which you want the pricing updated.
Enter a range (from and to) of categories for which you want the pricing updated.
Specify a date to identify releases or standard purchase orders to be updated. The release shipment need-by date should be on or after the specified date. If need-by date is not available, the release shipment creation date will be used.
Indicate if you want the updated releases or purchase orders communicated to the supplier. The communication method is determined by the Supplier Notification Method setting of the supplier site. See: Communicating Purchase Orders to Suppliers
Related Topics
Submitting a Request, Oracle Applications User's Guide
The workflow process, Send Notifications for Purchasing Documents, looks for documents that are incomplete, rejected, or in need of reapproval and sends notifications to the appropriate people of the document's status. You can view and respond to these notifications through the Notifications Summary window. In order for these notifications to be sent, you need to start this concurrent program process, Send Notifications for Purchasing Documents, and choose how frequently you want the process to run. (The workflow definition itself, Send Notifications for Purchasing Documents, which is initiated by this concurrent program process, is viewable through the Oracle Workflow Builder.)
For information on the kinds of notifications sent by the Send Notifications for Purchasing Documents process, see: Viewing and Responding to Notifications.
To run the Send Notifications for Purchasing Documents process:
Navigate to the Submit Requests window and select Send Notifications for Purchasing Documents in the Request Name field.
Choose Schedule.
Choose how often you want the process to run.
For example, choose Periodically if you want the process to run periodically. You can then choose to run the process every so many month(s), week(s), day(s), hour(s), or minute(s). For example, choose On Specific Days if you want the process to run on specific days of the month or week.
Choose OK.
Choose Submit Request once you've selected your options and are ready to run the process.
Related Topics
Oracle Workflow Guide, Oracle Workflow Guide
Submitting a Request, Oracle Applications User's Guide