Search Results pay_us_emp_baladj_cleanup




Overview

PAY_US_EMP_BALADJ_CLEANUP is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the cleanup and reconciliation of U.S. employee balance adjustment processing within Oracle Payroll. Balance adjustments are used to correct prior payroll results for an assignment, and the mechanical work of applying those adjustments creates payroll actions, assignment actions, and interlocks that must be sequenced, validated, and periodically purged. This package encapsulates the server-side logic required to identify the affected payroll actions, locate the relevant input values and element classifications, create the corrective payroll action, and pre-process the data before the adjustment run executes.

The package is classified as an OTHER API within the ETRM repository, meaning it is an internal, product-owned utility rather than a published, customer-facing API. Its documented dependency footprint is narrow: outside of the SYS.STANDARD package and the self-reference within APPS, it is not referenced by any other package. This indicates that the package is invoked directly rather than being reused as a shared library, which is consistent with its role as a targeted cleanup utility.

Key Procedures and Functions

The package exposes seven documented program units:

  • GET_PAYROLL_ACTION_INFO — retrieves descriptive information about an existing payroll action so that the cleanup logic can identify, and operate against, the correct action record.
  • GET_INPUT_VALUE_ID — resolves the input value identifier associated with an element input value, which is required to construct valid adjustment entries.
  • RANGE_CURSOR — a cursor-based routine used to iterate over the set of assignments or actions that fall within the processing range for the cleanup.
  • ACTION_CREATION — creates the payroll action (and the associated assignment actions) needed to carry out the balance adjustment cleanup.
  • INITIALIZE — performs setup and session-level initialization before the main processing begins.
  • DEINITIALIZE — reverses or releases the resources established by INITIALIZE at the end of processing.
  • RUN_PREPROCESS — executes the pre-processing phase that prepares and validates data prior to the main adjustment run.

The documented procedure list does not include parameter signatures; the naming convention nonetheless indicates a clear lifecycle of initialize, retrieve, create, pre-process, and de-initialize.

Tables Accessed

The package reads and writes a set of core Oracle Payroll tables through APPS synonyms. Payroll action data is handled through PAY_PAYROLL_ACTIONS, PAY_ACTION_INFORMATION and its _S shadow table, PAY_ACTION_INTERLOCKS, and PAY_ASSIGNMENT_ACTIONS with PAY_ASSIGNMENT_ACTIONS_S. Element and input value metadata is drawn from PAY_ELEMENT_TYPES_F, PAY_INPUT_VALUES_F, PAY_ELEMENT_CLASSIFICATIONS, and FF_USER_ENTITIES. Assignment context comes from PER_ALL_ASSIGNMENTS_F.

U.S. tax-specific data is read from PAY_US_STATES, PAY_US_EMP_STATE_TAX_RULES_F, and PAY_US_RPT_TOTALS, which supply the state-level rules and reporting totals relevant to balance adjustments. DBMS_LOCK is referenced to serialize processing and prevent concurrent execution conflicts during the cleanup.

Usage Notes

Because the package is an internal utility and is not referenced by any other package, it is normally invoked either from a concurrent program or from Oracle Payroll's own balance adjustment flows rather than from customer-written code. The presence of INITIALIZE, RUN_PREPROCESS, and DEINITIALIZE, together with DBMS_LOCK, suggests a batch-oriented execution model in which the utility acquires a lock, prepares the driver data, performs the adjustment processing, and releases resources on completion.

Customers should treat PAY_US_EMP_BALADJ_CLEANUP as product-owned and refer to it for diagnostic or troubleshooting purposes only; direct invocation is not supported and any call must be made from the APPS schema respecting the documented initialize/de-initialize sequence. Behavior is consistent across EBS 12.1.1 and 12.2.2, with the ONLINE PATCH EDITION differences in 12.2 affecting the underlying AD/TXK infrastructure rather than this package's logic.