Search Results pay_batch_lines_bruid

Overview

HR_BATCH_LOCK_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the ETRM as an "OTHER" API type. Its business purpose is to provide concurrency control for payroll batch processing by acquiring and releasing locks on batch header records. In a multi-user environment, several concurrent processes—such as batch element entry, batch line validation, and batch transfer to Oracle Payroll—may attempt to act on the same batch simultaneously. HR_BATCH_LOCK_PKG serializes this access by locking the corresponding row in PAY_BATCH_HEADERS, thereby preventing conflicting updates, duplicate processing, and data corruption. The package is particularly relevant to the Oracle Payroll batch element entry (BEE) flow and to the batch control totals mechanisms. In the context of the 12.1.1 and 12.2.2 releases, it remains a valid, non-form-bound server-side utility relied upon by the batch processing infrastructure rather than being called directly by end users. The user search term "pay_batch_control_totals_bruid" reflects the close association between this locking package and the batch control totals business rule/entity, which consumes locked batch headers to compute and maintain control totals.

Key Procedures and Functions

The ETRM metadata documents exactly one callable program unit within HR_BATCH_LOCK_PKG:

• BATCH_HEADER_LOCK — The sole documented procedure. Its purpose is to obtain a row-level lock on a payroll batch header so that the calling process has exclusive control over that batch for the duration of its transaction. By locking the PAY_BATCH_HEADERS row, the procedure ensures that no other concurrent session can validate, modify, or transfer the same batch until the lock is released at commit or rollback. While the package signature indicates additional parameters may exist, the documented metadata does not enumerate them; per ETRM conventions, the procedure should be treated as an internal locking primitive invoked with the relevant batch header identifier. No other procedures or functions are listed as documented for this package, so BATCH_HEADER_LOCK represents the entirety of its published interface.

Tables Accessed

The ETRM documents a single table referenced by HR_BATCH_LOCK_PKG via APPS synonyms:

• PAY_BATCH_HEADERS — The header table for payroll batches. HR_BATCH_LOCK_PKG reads and locks rows in this table. The lock is the essential operation: by issuing a SELECT ... FOR UPDATE (or equivalent) against the batch header, the package prevents concurrent modification while allowing the caller to safely read the batch status, control totals, and line counts. No other tables are documented in the dependency list, which is consistent with the package's narrow, single-purpose design as a locking utility. The package itself depends only on SYS.STANDARD, indicating a minimal internal footprint and no other application schema dependencies.

Usage Notes

HR_BATCH_LOCK_PKG is referenced by two other packages: PAY_BATCH_CONTROL_TOTALS_BRUID and PAY_BATCH_LINES_BRUID. This reference pattern confirms that the locking package is invoked by the batch control totals and batch lines business rule packages before they perform their respective operations. In practice, when a user or concurrent program initiates validation or transfer of a payroll batch, the downstream business rule packages call HR_BATCH_LOCK_PKG.BATCH_HEADER_LOCK to secure the header before reading or updating batch lines and totals. Typical invocation points therefore include the Batch Element Entry form, batch validation concurrent programs, and batch transfer-to-payroll processes within Oracle Payroll. Because the package is not itself a form-level or concurrent-program entry point, it is not intended for direct end-user invocation; custom code that manipulates payroll batches should likewise call this package to honor the platform's concurrency contract. Correct usage requires that the calling transaction complete (commit or rollback) promptly, since the lock is held for the life of the transaction and can block other sessions from processing the same batch. These behaviors hold true across both EBS 12.1.1 and 12.2.2, where the package remains VALID and unchanged in its documented interface.