Search Results pay_bacm




Overview
Explore in AI Chat

Overview

PAY_BACM is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite, validated as VALID in both the 12.1.1 and 12.2.2 releases. The name follows the Oracle Payroll naming convention in which the "PAY_" prefix identifies a Payroll module object and the "BAC" stem denotes a balance, archive, or batch-related utility. Within the standard ETRM (E-Business Suite Technical Reference Manual) classification, PAY_BACM is registered as an API of type OTHER, indicating that it is not a public, externally versioned interface such as those exposed through the Oracle PL/SQL API framework (for example, PAY_API or HR_API packages). It is instead an internal helper package consumed by the Payroll application's own logic during payroll run processing, balance calculation, and rerun/archive handling. Its dependency list is confined to a small set of Payroll base tables — PAY_ELEMENT_TYPES, PAY_INPUT_VALUES, PAY_RUN_RESULTS, and PAY_RUN_RESULT_VALUES — which confirms that its scope is restricted to reading and interpreting payroll run result data and the element and input-value definitions that qualify those results. Because the package body is not referenced by any other database object in the shipped schema, it is effectively a leaf-level component whose behavior is driven by the processes that instantiate it at runtime.

Key Procedures and Functions

The ETRM metadata documents a single public program unit in the package specification and body:

  • IS_DATE_VALID — A validation function whose evident purpose is to determine whether a supplied date value is valid for the context in which the Payroll processing logic intends to use it. Given the package's dependency footprint on PAY_RUN_RESULTS and PAY_RUN_RESULT_VALUES, this function is typically used to guard date-based comparisons (for example, deciding whether an effective date or a run result date falls within an acceptable range before a balance or archive operation proceeds). The function returns a boolean-style validity indicator; the precise parameter list is not exposed in the ETRM documentation and should not be assumed. No other procedures or functions are documented for this package, and no private helper routines are listed in the ETRM extract.

Tables Accessed

The documented table dependencies, resolved through APPS synonyms, are as follows:

  • PAY_RUN_RESULTS — The primary payroll run result table, storing one row per assignment per element per payroll run. PAY_BACM reads this table to obtain the result records whose dates or values require validation.
  • PAY_RUN_RESULT_VALUES — The child table holding the individual input value results associated with each PAY_RUN_RESULTS row. It is read to support validation that depends on specific input values rather than the parent result row alone.

The dependency report additionally lists PAY_ELEMENT_TYPES and PAY_INPUT_VALUES. These are referenced indirectly (through the element-type and input-value definitions that qualify run results) and confirm that PAY_BACM operates within the standard Payroll data model rather than against external or temporary structures. No DML against these tables is documented, suggesting a read-only validation role. The metadata does not document any SQL statements beyond these dependencies, so the exact query predicates cannot be reproduced from the ETRM record alone.

Usage Notes

PAY_BACM is an internal Payroll package and is not intended for direct invocation by customer-written code. It is normally called from within Payroll concurrent programs (such as the Payroll Run, QuickPay, and RetroPay processes), from balance and archive routines, and from corrective/rerun logic that must validate date-bearing run result data before applying adjustments. Because the package is not referenced by any other database object in the shipped schema, it should be treated as a private implementation detail: Oracle application logic instantiates it at runtime, and the object has no documented extension points. Customers and partners should avoid wrapping or directly calling IS_DATE_VALID in custom code, since Oracle may change or remove the package without notice in a patch or upgrade. When troubleshooting payroll date-validation errors, the package can be inspected in the database via its VALID status in ALL_OBJECTS and its source in ALL_SOURCE, but remediation should target the calling Payroll process rather than the package itself. In 12.2.2 environments, the same object is present and valid with an identical dependency footprint, so behavior is consistent across the two releases covered by the ETRM metadata.