Search Results pay_etm_shd




Overview
Explore in AI Chat

Overview

PAY_ETM_SHD is a shadow (internal helper) package body in the APPS schema that supports the Oracle Payroll Element Template Module (ETM). Its role is to provide the low-level plumbing for creating, validating, and updating element templates — the reusable definitions that govern how payroll elements such as earnings, deductions, and accruals are structured and processed. Element templates in Oracle Payroll are stored in PAY_ELEMENT_TEMPLATES and drive the automatic generation of element classifications, input values, balances, and processing rules. The "_SHD" suffix indicates that this is a shadow package: it is not intended to be called directly by customers or external code, but rather is invoked internally by the ETM user interface, concurrent processes, and seeding routines. The package encapsulates constraint checking, record locking, argument conversion, and update guards so that higher-level ETM logic can manipulate templates safely against the underlying payroll data model.

Key Procedures and Functions

The ETRM metadata documents four procedures or functions within this package body. Because the metadata does not expose parameter signatures, the descriptions below are limited to documented purpose.

  • CONSTRAINT_ERROR — Handles constraint-related error conditions raised during template manipulation. It centralizes error trapping so that violations detected while validating or writing template records are surfaced with consistent, payroll-specific error messages rather than raw Oracle constraint exceptions.
  • API_UPDATING — Acts as an update guard flag or routine that marks when an API-driven update to a template is in progress. This prevents conflicting direct DML or re-entrant updates while an element template is being modified through the supported API path.
  • LCK — Provides record-level locking for element template rows. It ensures that concurrent sessions cannot simultaneously modify the same template, preserving data integrity during multi-user payroll configuration.
  • CONVERT_ARGS — Converts or normalizes arguments passed into the ETM package layer, mapping caller-supplied values into the internal representation expected by the template routines before they are applied to PAY_ELEMENT_TEMPLATES.

Tables Accessed

The package references two tables through APPS synonyms, as documented in the ETRM metadata.

  • PAY_ELEMENT_TEMPLATES — The primary payroll table holding element template definitions. PAY_ETM_SHD reads and writes this table when creating, locking, or updating templates. All locking and update-guard logic (LCK, API_UPDATING) is oriented around rows in this table.
  • ALL_CONSTRAINTS — The data dictionary view used to inspect constraint definitions, enabling the package to validate template data against the constraints defined on the underlying payroll tables and to raise meaningful errors through CONSTRAINT_ERROR.

The dependency list also shows references to HR_API, HR_UTILITY, and the package's own body (PAY_ETM_SHD), plus SYS.STANDARD. HR_API and HR_UTILITY supply standard Oracle HRMS APIs and utility routines for validation and error handling that the ETM layer relies on.

Usage Notes

PAY_ETM_SHD is an internal, undocumented-for-external-use package. It is characteristically invoked indirectly rather than from custom code. Typical invocation paths include the Element Template configuration forms and windows within Oracle Payroll, concurrent programs that seed or migrate element templates, and the higher-level ETM API layer that calls PAY_ETM_SHD for constraint checking, locking, and argument conversion. The package is referenced by nine other packages, confirming its role as a shared helper within the ETM and payroll configuration stack. The metadata states it is not referenced by any database object in the ETRM snapshot, reinforcing that its consumers are PL/SQL packages rather than views or triggers. Consultants should not call this package directly; instead they should use the supported element template APIs. Because "_SHD" packages are subject to change between releases, any direct dependency is unsupported and may break on patching. In both 12.1.1 and 12.2.2 the package remains VALID and structurally consistent, with the same dependency footprint.