Search Results nowaitlock_f_batch_id

Overview

ARP_CASH_RECEIPTS_PKG is a core Oracle Receivables PL/SQL package owned by the APPS schema that encapsulates the low-level data access, locking, and persistence logic for the AR_CASH_RECEIPTS base table. In Oracle EBS 12.1.1 and 12.2.2 it functions as an internal data-handling layer rather than a public business API: it exposes simple CRUD operations (insert, update, delete, fetch) plus a family of pessimistic and optimistic locking primitives that allow callers to serialize concurrent modification of cash receipt rows. The package is declared AUTHID CURRENT_USER, meaning its SQL executes with the privileges of the invoking schema. It is not classified as a formal public API in the ETRM registry (API classification: OTHER) and is referenced internally by 22 other packages, which indicates its role as a shared utility used by higher-level Receivables logic such as receipt application, batch processing, and receipt reversal.

Key Procedures and Functions

The documented surface consists of fifteen procedures and functions, grouped by purpose.

• set_to_dummy — Initializes an AR_CASH_RECEIPTS%ROWTYPE record variable to a null/dummy state, typically used before population.
• update_p — Persists changes to a cash receipt. Two overloads exist: the newer form accepting both the record and an explicit cash_receipt_id, and the older single-parameter form retained for backward compatibility. The newer form is the intended entry point; the legacy form exists only to avoid breaking existing callers.
• insert_p — Inserts a new cash receipt row; the record parameter is passed as IN OUT so that generated or defaulted columns can be returned to the caller.
• delete_p — Removes a cash receipt identified by cash_receipt_id.
• fetch_p — Retrieves a cash receipt row into a %ROWTYPE record.
• lock_p / lock_fetch_p — Acquire a row lock (SELECT FOR UPDATE) by cash_receipt_id, with lock_fetch_p combining locking and retrieval in one call.
• nowaitlock_p / nowaitlock_fetch_p — Variants that fail immediately if the row is already locked, rather than waiting.
• nowaitlock_version_p — Extended non-blocking lock introduced under Bug fix 3032059, accepting an optional receiving version number to support optimistic concurrency control.
• update_version_number — Maintains the rec_version_number column used to detect conflicting updates.
• lock_f_batch_id / nowaitlock_f_batch_id — Lock the AR_BATCHES parent row by batch_id, ensuring batch-level consistency when receipts are added or modified within a batch.
• lock_compare_p — Compares the supplied record against the stored row, verifying that in-memory data has not been changed by another session before an update is committed.

Tables Accessed

All table access occurs through APPS synonyms. AR_CASH_RECEIPTS is the primary subject of every CRUD and locking operation, with AR_CASH_RECEIPTS_S providing the corresponding audit/intersection data maintained in parallel. AR_CASH_RECEIPT_HISTORY records the status and activity trail for each receipt as changes are applied. AR_BATCHES is locked and referenced for batch-level grouping of receipts (lock_f_batch_id and nowaitlock_f_batch_id). AR_SYSTEM_PARAMETERS supplies Receivables system options that condition processing behavior, and DUAL is used for scalar lookups and procedural control.

Usage Notes

Oracle does not document ARP_CASH_RECEIPTS_PKG as a supported public API, so custom code should avoid calling it directly and instead use the supported Receivables public APIs (for example AR_RECEIPT_API_PUB). Within Oracle's own code, the package is invoked from Receivables forms (notably the Cash Receipts and Receipts workbench), from concurrent programs that process receipt batches, and from the 22 dependent packages that require row-level locking and record manipulation. The standard usage pattern is: lock the batch or receipt row, fetch the record, modify the %ROWTYPE in memory, call update_p with the cash_receipt_id, and, where optimistic locking is employed, validate via lock_compare_p and update_version_number. Because of the AUTHID CURRENT_USER declaration, callers must have direct object privileges on the underlying tables, and all callers should supply the correct cash_receipt_id to the newer update_p overload to avoid ambiguity with the retained legacy signature.