Search Results process_pay_receipt

Overview

AR_AUTOREM_API is a PL/SQL package owned by the APPS schema that implements the Automatic Remittance processing functionality within Oracle Receivables. Its central business purpose is to automate the creation and matching of receipts against open customer transactions when remittance information is received electronically, typically through bank lockbox files or other remittance transmission channels. Rather than requiring a receivables clerk to manually apply each payment, the package programmatically interprets remittance advice data, resolves the paying customer, identifies the appropriate receipt method and bank account, and generates cash receipts that are applied to open payment schedules. In this sense it acts as the engine behind the Automatic Receipts and Automatic Remittance features of Receivables.

The package is classified as an API within ETRM, indicating that it exposes callable entry points intended for use by concurrent programs, forms, and, where appropriate, custom extensions. It is a self-referencing package (AR_AUTOREM_API references and is referenced by itself) and is not referenced by any other documented package, which confirms its role as a top-of-stack driver rather than a shared utility.

Key Procedures and Functions

ETRM documents eleven callable units within the package. Their documented purposes are as follows:

• GET_PARAMETERS — Retrieves the runtime parameters that govern an automatic remittance run, establishing the processing context used by the remaining procedures.
• SUBMIT_AUTOREM_PARALLEL — Submits the automatic remittance processing as a parallel concurrent request, enabling large remittance volumes to be split across workers.
• INSERT_BATCH — Creates the AR_BATCHES record that groups generated receipts for a given run.
• CREATE_AND_UPDATE_REMIT_REC — The single-organization entry point that creates and updates remittance receipts.
• CREATE_AND_UPDATE_REMIT_REC_PA — The parallel-aware counterpart to CREATE_AND_UPDATE_REMIT_REC, invoked by worker processes handling a subset of the overall workload.
• SELECT_UPDATE_REC — Selects candidate records and applies updates as part of the receipt generation cycle.
• PROCESS_PAY_RECEIPT — Processes an individual payment receipt through the remittance matching logic.
• PROCESS_PAY_RECEIPT_PARALLEL — The parallel variant of PROCESS_PAY_RECEIPT used by concurrent workers.
• INSERT_EXCEPTIONS — Writes records that could not be processed successfully into the exceptions table for later review.
• SUBMIT_REPORT — Submits the reporting output summarizing the results of an automatic remittance run.
• REC_RESET — Resets the interim/working state so that a run can be re-executed or restarted cleanly.

Tables Accessed

The package reads and writes a defined set of Receivables, Payables, and Trading Community tables, reached through APPS synonyms. Source and reference data are drawn from AR_RECEIPT_METHODS, AR_RECEIPT_METHOD_ACCOUNTS, AR_RECEIPT_CLASSES, AP_BANK_ACCOUNTS, HZ_CUST_ACCOUNTS, HZ_PARTIES, and AP_PAYMENT_PROGRAMS. Receipt and application data are handled through AR_CASH_RECEIPTS (AR_CASH_RECEIPTS_ALL), AR_CASH_RECEIPT_HISTORY, AR_BATCHES (AR_BATCHES_ALL), AR_PAYMENT_SCHEDULES, AR_AUTOREM_INTERIM, and AR_AUTOREC_EXCEPTIONS. The interim and exceptions tables are particularly significant: AR_AUTOREM_INTERIM holds staged remittance records during processing, while AR_AUTOREC_EXCEPTIONS captures failures that require manual intervention.

Usage Notes

AR_AUTOREM_API is most commonly invoked indirectly, through the Automatic Remittance concurrent program and related Receivables setup screens, rather than being called directly by end users. When the concurrent program is launched, SUBMIT_AUTOREM_PARALLEL and SUBMIT_REPORT coordinate the run and its output, while CREATE_AND_UPDATE_REMIT_REC_PA and PROCESS_PAY_RECEIPT_PARALLEL do the per-record work in parallel workers. Custom integrations and extensions that need to drive automatic remittance programmatically should call the documented procedures rather than manipulating the underlying tables directly, since the package encapsulates the required validation, receipt numbering, and accounting derivation logic. The presence of REC_RESET also makes the package suitable for controlled re-runs, allowing a failed or partial remittance pass to be reset before being reprocessed. Because the package writes directly to receipt, batch, and history tables, any custom invocation should respect concurrency controls and be tested thoroughly in a non-production environment.