Search Results pay_pgr_shd




Overview
Explore in AI Chat

Overview

PAY_PGR_SHD is a PL/SQL package body owned by the APPS schema that supports the effective-dating and record lifecycle management of grade rules within Oracle Payroll. The "SHD" suffix indicates that this package operates as a shadow or surrogate datetrack helper, providing the low-level infrastructure that allows Payroll grade rule definitions to be inserted, updated, and end-dated along the datetrack (effective date) model used throughout Oracle HRMS. Business users configure grade rules—which associate pay grades with progression rules, experience levels, and rate determination logic—through the Grade Rules window, and PAY_PGR_SHD supplies the API plumbing that validates, converts, and applies those changes against the underlying PAY_GRADE_RULES_F table.

The package is classified under the API classification OTHER, reflecting its role as an internal support utility rather than a public business API. It depends on standard HRMS infrastructure components including DT_API (datetrack processing), HR_API, HR_UTILITY, and FND_MESSAGE, which together handle effective-date validation, error message resolution, and generic HR utilities. The package body is VALID in the documented releases (12.1.1 and 12.2.2), and its outputs are consumed by five referencing packages, confirming its position as a shared dependency in the Payroll grade rules processing chain.

Key Procedures and Functions

The documented program units are largely internal helpers that cooperate to enforce datetrack and concurrency rules:

  • RETURN_API_DML_STATUS — Returns the DML status of operations performed by the API, allowing callers to determine whether an insert, update, or delete succeeded.
  • CONSTRAINT_ERROR — Handles constraint violation errors encountered during processing, providing standardized error signaling to the calling code.
  • API_UPDATING — Flags or determines that an API-driven update is in progress, a common HRMS pattern used to bypass or modify validation behavior during programmatic updates.
  • FIND_DT_UPD_MODES — Determines the applicable datetrack update modes for a record, identifying whether changes require date-tracked updates, corrections, or other effective-date strategies.
  • FIND_DT_DEL_MODES — Determines the applicable datetrack delete modes, guiding whether a deletion is performed as an end-date, a purge, or another supported deletion pattern.
  • UPD_EFFECTIVE_END_DATE — Updates the effective end date on the relevant grade rule record, the core operation for closing out a datetracked row as part of the shadow/surrogate processing.
  • LCK — Acquires the necessary locking on the target record so that concurrent datetrack operations do not corrupt date ranges.
  • CONVERT_ARGS — Converts or normalizes the arguments passed into the API, aligning caller-supplied values with the internal representation expected by the datetrack and DML logic.

Tables Accessed

Two tables are documented as accessed via APPS synonyms:

  • PAY_GRADE_RULES_F — The core grade rules table. PAY_PGR_SHD reads and updates this table to apply effective-date changes, adjust the effective end date of grade rule rows, and maintain the datetracked timeline of grade rule definitions.
  • ALL_CONSTRAINTS — Used to inspect database constraint metadata, supporting the CONSTRAINT_ERROR handling logic and validation against the table's constraints.

Usage Notes

PAY_PGR_SHD is not intended for direct invocation by end users or custom code; it functions as an internal shadow package supporting the grade rules maintenance flow. It is most commonly exercised when users modify grade rule information through the Payroll Grade Rules form, or when the grade rules APIs (which depend on this shadow layer) are invoked by concurrent programs, datetrack processing routines, or upgrade scripts during patching and data migration. Because the package is referenced by five other packages and exposes no public entry points, customizations should avoid calling it directly and instead use the supported grade rules API surface. The presence of RETURN_API_DML_STATUS, LCK, and CONSTRAINT_ERROR indicates that any caller must inspect the returned DML status rather than assume success. In both 12.1.1 and 12.2.2 the object is VALID, so standard troubleshooting applies: query ALL_OBJECTS to confirm validity, and recompile if any dependent objects were recently modified.