Search Results arp_process_br_batches




Overview

The APPS.ARP_PROCESS_BR_BATCHES package is a Receivables (AR) batch processing utility that supports the creation and maintenance of Automatic Receipt batches and Bill of Exchange (BOE) batches originating from the AutoLockbox and Automatic Receipts workflows. It is defined with AUTHID CURRENT_USER, meaning that it executes with the privileges of the invoking session rather than the package owner, which is significant for any custom code that calls it directly. The prefix BR denotes "Batch Receipts," and the source header indicates the package was authored to service the Automatic Receipts batch maintenance and submission flows (originally derived from the arhmapss.pls lineage). The package provides the low-level data manipulation and orchestration procedures behind the Receipts batch form and its associated concurrent programs, rather than a single business transaction API. Its primary consumers are the Receivables batch entry forms and the AutoLockbox/Remittance batch creation processes, and the metadata records that it is referenced by one other package in the application.

Key Procedures and Functions

The ETRM metadata documents six procedures:

  • INSERT_BATCH — Creates a new row in the AR batch tables, capturing batch-level header information. Based on the source excerpt its parameters map directly to RA_BATCHES columns (batch source, batch date, GL date, type, currency, comments, the DFF attribute columns 1–15, issue date, maturity date, special instructions, and batch process status) together with selection criteria parameters drawn from AR_SELECTION_CRITERIA (due date low/high, transaction date low/high, customer transaction type, receipt method, and bank branch).
  • UPDATE_BATCH — Modifies an existing batch record, generally used when a user changes batch header or selection criteria before creation/submission.
  • DELETE_BATCH — Removes a batch and its associated processing artifacts, used from the batch form's delete action.
  • LOCK_COMPARE_BATCH — Performs a concurrency check and locks the batch row, comparing the caller's version against the database to detect conflicting edits before an update or create.
  • SUBMIT_PRINT — Submits the batch for printing; typically invoked after receipts or BOE documents are generated so that the physical output can be produced.
  • BR_CREATE — The central "batch receipt create" routine that the user searched for. It orchestrates the actual creation of the receipts or BOE transactions for the batch, reading the batch header and its selection criteria and driving the downstream transaction generation.

Tables Accessed

The package interacts with the following documented tables via APPS synonyms:

  • RA_BATCHES, RA_BATCH_SOURCES, RA_BATCH_SOURCES_ALL — the batch header and its source definitions; inserted and updated by INSERT_BATCH/UPDATE_BATCH.
  • AR_SELECTION_CRITERIA — holds the selection parameters that determine which transactions or customers are included in a batch, read by BR_CREATE.
  • AR_PAYMENT_SCHEDULES and RA_CUSTOMER_TRX — the transaction/payment schedule data against which receipts are created.
  • RA_CUST_TRX_TYPES — validation of the transaction type used in selection.
  • AR_RECEIPT_METHODS — validation of the receipt method applied to the generated receipts.
  • HZ_CUST_ACCOUNTS and HZ_CUST_SITE_USES — customer and site-level validation for the transactions and receipt destinations.

Usage Notes

This package is not a general-purpose public API and should be treated as an internal utility for the Receivables batch receipt flow. It is invoked from the Receivables batch entry forms (automatic receipts and BOE batch windows) and from AutoLockbox/remittance batch creation logic, and is referenced by one other package. Customizations should prefer the standard Receivables public APIs; direct calls to ARP_PROCESS_BR_BATCHES carry risk because the package executes with AUTHID CURRENT_USER and its interface is not contractually frozen. The procedures are available in both Oracle EBS 12.1.1 and 12.2.2; the source header revision 120.2 dates from 2003, indicating a stable interface across these releases. Any integration should account for the versioning/concurrency expectations set by LOCK_COMPARE_BATCH and should not bypass it when performing updates.