Search Results insert_remit_batch

Overview

ARP_RW_BATCHES_PKG is the Receivables batch maintenance package in Oracle EBS Release 12.1.1 and 12.2.2. It encapsulates the server-side logic required to create, validate, and delete receipt batches stored in AR_BATCHES, shielding callers from the underlying table structure and validation rules. The package supports the three principal batch categories used by Receivables: manual batches entered by users, automatic batches generated by the automatic receipt creation and remittance processes, and remittance batches associated with a remittance method and bank branch. In addition to record maintenance, the package exposes locking and defaulting utilities used by the Receivables windows and by concurrent processes that must serialize access to batch records.

The package header comment reflects the standard Oracle Applications build identifier (ARERBATB.pls, version 120.13.12010000.2), and the body defines a debug flag derived from the AFLOG_ENABLED profile option, allowing the package to emit diagnostic output when Applications logging is enabled. Internal validation procedures such as validate_args_insert_manual, validate_args_insert_remit, and validate_args_insert_auto verify required arguments, set of books, currency, and batch attributes before an insert is permitted.

Key Procedures and Functions

• INSERT_MANUAL_BATCH — Creates a new manual receipt batch in AR_BATCHES after validating the supplied batch attributes, including set of books, currency, batch date, and auto-numbering rules drawn from the batch source.
• INSERT_AUTO_BATCH — Creates an automatic receipt batch used by automated receipt generation. This is the procedure referenced by the search term "insert_auto_batch." It validates the batch against the receipt class and receipt method supplied by the caller before inserting the batch record.
• INSERT_REMIT_BATCH — Creates a remittance batch, validating remittance method and remittance bank branch information in addition to the standard batch attributes.
• DELETE_BATCH — Removes a receipt batch, enforcing the business rules that determine whether a batch may be deleted given its state and applied status.
• DEFAULT_BATCH_SOURCE_PAY_MTHDS — Populates default payment methods associated with a batch source, used by the Receivables batch entry forms to derive valid values for the batch.
• RELEASE_LOCK — Releases the DBMS_LOCK lock held against a batch, allowing other sessions to proceed.
• REQUEST_LOCK — Acquires a DBMS_LOCK lock on a batch to serialize concurrent maintenance operations such as insert, update, or delete.

Tables Accessed

The package reads and writes AR_BATCHES, the primary batch repository. It consults AR_BATCH_SOURCES for batch source attributes such as auto-batch numbering and default payment methods, and AR_RECEIPT_CLASSES, AR_RECEIPT_METHODS, and AR_RECEIPT_METHOD_ACCOUNTS to validate automatic batch definitions. CE_BANK_ACCOUNTS and related bank branch data support remittance batch creation and validation. AR_PAYMENT_SCHEDULES is referenced to determine whether receipts associated with a batch constrain deletion. Customer and contact information is validated through HZ_PARTIES, HZ_CONTACT_POINTS, and HZ_RELATIONSHIPS. DBMS_LOCK provides the locking primitives used by REQUEST_LOCK and RELEASE_LOCK.

Usage Notes

The package is invoked from the Receivables batch entry and remittance windows, from concurrent programs that generate automatic receipts, and from custom PL/SQL that must create or remove batches programmatically. The INSERT_AUTO_BATCH path in particular is the supported entry point for automated batch creation in 12.1.1 and 12.2.2. The package is referenced by two other delivered packages, indicating its role as a shared internal service layer. Custom code should call these procedures rather than inserting directly into AR_BATCHES, because validation, defaulting, and batch locking are applied only through the package. All arguments should be supplied using the documented datatypes; callers should also honor the locking protocol by invoking REQUEST_LOCK before maintenance and RELEASE_LOCK afterward.