Search Results insert_manual_batch

Overview

APPS.ARP_RW_BATCHES_PKG is a Receivables batch management package in Oracle E-Business Suite Release 12.1.1 and 12.2.2. The package owns the lifecycle operations for Automatic Receipt, Manual Receipt, and Remittance batches, encapsulating the insert, validation, locking, and deletion logic required to create and maintain rows in the AR_BATCHES table. A primary element of its design is batch source resolution: the INSERT procedures use AR_BATCH_SOURCES to determine the receipt class, payment method, and numbering characteristics that govern how receipts are grouped and processed within a batch. The package also enforces concurrency control by combining a REQUEST_LOCK / RELEASE_LOCK pair with the DBMS_LOCK built-in, preventing two concurrent processes from mutating the same batch row simultaneously. Its API classification is OTHER — it is a support package rather than a documented public API — and it is referenced by AR_AUTOREC_API and AR_AUTOREM_API.

Key Procedures and Functions

• INSERT_MANUAL_BATCH — creates a batch for manually entered receipts, deriving receipt class, payment method, and batch numbering behavior from the selected batch source in AR_BATCH_SOURCES.
• INSERT_AUTO_BATCH — creates a batch for automatically generated receipts, applying the batch source attributes configured for automatic receipt creation and remittance.
• INSERT_REMIT_BATCH — creates a remittance batch used to consolidate receipts for remittance to the bank, driven by receipt class and receipt method setup.
• DELETE_BATCH — removes a batch record and manages the related batch state, subject to the batch's processing status.
• DEFAULT_BATCH_SOURCE_PAY_MTHDS — resolves and returns the payment methods associated with a given batch source, so callers can default valid receipt methods during batch entry.
• REQUEST_LOCK — acquires a logical lock on a batch to serialize concurrent processing; implemented using DBMS_LOCK.
• RELEASE_LOCK — releases the batch lock previously acquired through REQUEST_LOCK.

Tables Accessed

The package reads and writes the following documented objects through APPS synonyms:

• AR_BATCHES — the batch header repository; all INSERT and DELETE operations target this table.
• AR_BATCH_SOURCES — supplies the batch source attributes that drive receipt class, payment method, and numbering behavior; central to the INSERT procedures and to DEFAULT_BATCH_SOURCE_PAY_MTHDS.
• AR_RECEIPT_CLASSES and AR_RECEIPT_METHODS — define the receipt classification and method valid for a batch source.
• AR_RECEIPT_METHOD_ACCOUNTS — resolves the cash, receivables, and other accounting flexfield accounts associated with a receipt method.
• AR_LOOKUPS — retrieves lookup values used for validation and defaulting.
• CE_BANK_ACCOUNTS and CE_BANK_BRANCHES_V — resolve the bank account and branch for remittance and bank-related batches.
• AR_PAYMENT_SCHEDULES, HZ_CONTACT_POINTS, HZ_PARTIES, and HZ_RELATIONSHIPS — support validation and defaulting of customer and contact information.
• DBMS_LOCK — implements the REQUEST_LOCK and RELEASE_LOCK concurrency primitives.

Usage Notes

ARP_RW_BATCHES_PKG is normally invoked indirectly rather than from custom code. It is referenced by AR_AUTOREC_API and AR_AUTOREM_API, the public APIs for automatic receipt creation and automatic remittance, and it is called during batch entry in the Receivables forms (Batches and Automatic Receipts) and during AutoReceipt and AutoRemittance concurrent program runs. The REQUEST_LOCK / RELEASE_LOCK pair ensures that batch creation and receipt assignment are serialized, which is important where AutoReceipt runs overlap with manual batch maintenance. Customizations and CEMLI code should prefer the public AR_AUTOREC_API and AR_AUTOREM_API endpoints; direct calls to ARP_RW_BATCHES_PKG should be treated as internal and re-verified after any patch or upgrade. When migrating or replicating batch setup, note that the batch's behavior is ultimately determined by AR_BATCH_SOURCES, so source configuration must be in place before batches are created. Because the package is classified OTHER and its parameter signatures are not published, callers should obtain interface details from the package specification on the target instance rather than assuming portability across releases.