Search Results pay_etm_upd




Overview
Explore in AI Chat

Overview

PAY_ETM_UPD is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the ETRM (E-Business Suite Technical Reference Manual) as an "OTHER" API. Its name follows the Oracle HRMS Payroll naming convention, where the "PAY_" prefix denotes the Payroll product and the "ETM" segment refers to Element Templates. Accordingly, the package serves the business function of maintaining and updating element template definitions within Oracle Payroll.

Element templates are the metadata structures that drive the configuration of payroll elements, which in turn define how earnings, deductions, and other payroll components are calculated for employees. The PAY_ETM_UPD package encapsulates the logic required to modify these template definitions in a controlled, API-driven manner rather than through direct table manipulation. The package is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2, confirming its continued presence across the two release lines. It is a small, focused utility package: the ETRM metadata records only a single documented procedure and a single referenced table.

Key Procedures and Functions

The documented interface of PAY_ETM_UPD is minimal. ETRM records a total of two documented procedures or functions, the only named entry being UPD. The procedure UPD is the sole public entry point and is responsible for performing the update operation against the element template data. As with most Oracle HRMS utility procedures, it likely validates the incoming template identifier and attribute values before applying changes, thereby preserving data integrity.

The second documented subprogram is not separately named in the ETRM excerpt; it may be a private helper routine or a secondary overload associated with the update logic. No parameter lists are published in the available metadata, and none should be assumed. The package body additionally depends on HR_API, the core Human Resources API package, which supplies shared error-handling, date-tracking, and business-group utility routines. This dependency indicates that PAY_ETM_UPD routes its validation and error signalling through the standard HRMS API framework.

Tables Accessed

The only table documented as referenced through APPS synonyms is PAY_ELEMENT_TEMPLATES. This table stores the definitions of payroll element templates, including template identifiers, classification information, and the attributes that govern how elements are generated and processed. The UPD procedure reads from and writes to this table to apply the requested modifications to a template record.

In addition to the base table, the package depends on the shadow table PAY_ETM_SHD, as recorded in the ETRM dependency list. Shadow tables in HRMS capture the before-image of rows for audit and date-tracked (datetrack) processing; their presence confirms that element template updates are subject to Oracle's date-tracked change history, ensuring that historical payroll configurations remain reproducible.

Dependency information further shows that PAY_ETM_UPD references itself, meaning the package body calls its own procedures internally, and that it depends on SYS.STANDARD, the built-in PL/SQL package. No other application packages are documented as referencing PAY_ETM_UPD, so its use is not exposed as a published public API to the wider HRMS suite.

Usage Notes

Because PAY_ETM_UPD is classified as "OTHER" rather than as a supported public API, it is best regarded as an internal utility package. It is typically invoked indirectly by Oracle Payroll configuration forms or by other internal HRMS processing logic when an element template must be updated. Custom code should avoid calling this package directly; the supported route for element template maintenance is through the standard Oracle Payroll setup forms or through the documented HRMS APIs that Oracle publishes for element configuration.

When troubleshooting, developers may query PAY_ELEMENT_TEMPLATES and PAY_ETM_SHD to verify whether an update has been applied and to inspect the date-tracked history. Any direct invocation of UPD should be performed only with a clear understanding of the required business group and date-track context, and only after validating that no supported alternative exists. Because the package relies on HR_API, errors raised during execution are surfaced through the standard HRMS error stack rather than through product-specific messages.