Search Results create_remit_batch_conc_req

Overview

ARP_PROCESS_BOE is the core PL/SQL package body in Oracle Receivables that drives the Bank of America-style "create remittance batch" processing flow within Oracle E-Business Suite 12.1.1 and 12.2.2. Its principal business purpose is to let users assemble, modify, and submit remittance batches from a set of eligible cash receipts, and to drive the fully automatic batch creation process that groups receipts and on-account transactions by remittance attributes such as bank account, receipt method, and maturity date. The package encapsulates both the interactive add/remove logic used by the Receivables remittance batch forms and the concurrent request submission logic that performs the same work in background mode.

The package is owned by APPS and is classified as an OTHER API in the ETRM documentation. Its public interface exposes six documented procedures and is referenced by one other package in the ETRM repository, indicating a contained but important role in the Receivables batch processing layer.

Key Procedures and Functions

The package exposes six documented public procedures:

• ADD_OR_RM_REMIT_REC_TO_BATCH — Adds or removes an individual receipt from an existing remittance batch. Beyond membership changes, it also permits the user to alter receipt attributes such as the remittance bank account, the override remit account flag, bank charges, and maturity date.
• CREATE_REMIT_BATCH_CONC_REQ — The concurrent request entry point that builds a remittance batch. This is the procedure invoked when the user submits "Create Remittance Batch" from a concurrent program or SRS window; it is the object most closely associated with the user's search term create_remit_batch_conc_req.
• APP_FMT_AUTO_BATCH_CONC_REQ — Applies formatting and validation logic preparatory to submitting the automatic batch concurrent request.
• APP_FMT_REMIT_BATCH_CONC_REQ — Applies formatting and validation logic preparatory to submitting the remittance batch concurrent request.
• CREATE_AUTO_BATCH_CONC_REQ — The concurrent request entry point that automatically creates batches based on user-selected grouping criteria, without requiring the user to hand-pick each receipt.
• ADD_OR_RM_TXN_FROM_AUTO_BATCH — Adds or removes on-account and transaction records from automatically created batches, complementing the receipt-level add/remove procedure.

Tables Accessed

The package reads and writes a defined set of Receivables and shared tables via APPS synonyms:

• AR_BATCHES — the parent batch header record created, updated, or removed during processing.
• AR_CASH_RECEIPTS and AR_CASH_RECEIPT_HISTORY — the receipts added, removed, or modified, and their history records where bank charge and remittance bank information is updated.
• AR_PAYMENT_SCHEDULES — source of maturity/due date information used to group and validate receipts.
• RA_CUSTOMER_TRX, AR_RECEIVABLE_APPLICATIONS, and AR_CONS_INV — transaction and application data relevant to on-account receipts and auto-batch transaction removal.
• HZ_CUST_ACCOUNTS, HZ_CUST_SITE_USES, and HZ_PARTIES — customer and site information for validating paying customers and remit-to addresses.
• AR_RECEIPT_METHODS, AR_SYSTEM_PARAMETERS, and AP_PAYMENT_PROGRAMS — configuration and setup data driving batch behavior.
• IBY_FNDCPT_TX_EXTENSIONS — payment extensions supporting bank account and payment instrument processing.

Usage Notes

ARP_PROCESS_BOE is typically invoked from the Receivables remittance batch forms (Oracle Forms-based UI) when users manually add or remove receipts, and from concurrent programs when batch creation is submitted for background processing. The three CONC_REQ procedures serve as the concurrent request entry points; customizations that need to programmatically create remittance batches should call CREATE_REMIT_BATCH_CONC_REQ rather than re-implementing batch assembly. Because these procedures operate on committed Receivables data and update history records, callers should invoke them within a properly managed transaction and observe the package's validation of bank account, receipt method, and customer information. In 12.1.1 and 12.2.2 the package is unchanged in name and ownership; the header comment indicates the last significant revision addressed a batch total bug, so integrators should treat it as a stable, supported API surface.