Search Results pay_siv_shd




Overview
Explore in AI Chat

Overview

APPS.PAY_SIV_SHD is a PL/SQL package body in the Oracle E-Business Suite Payroll (PAY) module. The suffix "SIV" denotes Shadow Input Values, and the package operates against the PAY_SHADOW_INPUT_VALUES table. Its overarching purpose is to support the shadow input value mechanism used by Oracle Payroll to capture, register, and convert input values that flow into payroll element processing outside of a formal payroll run. Shadow input values allow legislative and localization functionality to record derived or intermediate element inputs — for example, values produced by balance feeds, date-track processing, or third-party payroll integrations — without altering the primary input value records. The package exposes a small, focused API surface (four documented program units) and depends on HR_API and HR_UTILITY for the standard HRMS error-handling, locking, and message-resolution utilities. It is classified as an OTHER API rather than a public business API, indicating that it is intended for internal consumption by other payroll components rather than for direct customer invocation.

Key Procedures and Functions

  • CONSTRAINT_ERROR — Handles constraint-related error conditions raised during shadow input value processing. It standardises the raising or interpretation of constraint violations so that calling programs receive consistent HRMS-style errors.
  • API_UPDATING — Manages the update path for the shadow input value API. It governs whether and how existing shadow input value records may be modified, providing a controlled entry point for maintenance operations.
  • LCK — Implements record-level locking. It is used to serialise concurrent access to shadow input value rows, preventing lost updates when multiple payroll processes or concurrent requests touch the same element entries.
  • CONVERT_ARGS — Performs argument conversion, translating internal or raw shadow input value representations into the format expected by the payroll processing engine, or vice versa. This is the data-transformation core of the package.

No parameter lists are documented in the available metadata; consumption details should be confirmed against the deployed package specification in the target instance.

Tables Accessed

  • PAY_SHADOW_INPUT_VALUES — The primary data table. The package reads and writes shadow input value records, which store the effective input values used by payroll element processing for a given assignment, element, and time period.
  • ALL_CONSTRAINTS — Accessed via the PUBLIC synonym. The package queries constraint metadata, most likely in support of the CONSTRAINT_ERROR routine, to validate or identify integrity rules applying to shadow input value rows.

Additional dependencies on STANDARD, HR_API, and HR_UTILITY provide PL/SQL runtime and HRMS utility services rather than application data.

Usage Notes

PAY_SIV_SHD is not referenced by any database object, and the ETRM metadata records no direct referencing packages within this excerpt; however, the documented metadata notes that it is referenced by six other packages. It is therefore an internally consumed utility layer rather than a top-level API. Typical invocation is from within payroll processing logic: element processing routines, balance and date-track handling, and payroll action/run components that must persist or reconcile shadow input values. Because it manipulates data through the HR_API/HR_UTILITY stack, it inherits HRMS validation, security, and error semantics and should not be called directly from custom code without understanding those contracts. The presence of LCK confirms that callers are expected to operate within a transactional context where concurrent payroll runs may contend for the same rows. Customisations should treat this package as internal and unsupported for direct calls; integration should instead use the documented public payroll element entry APIs, allowing PAY_SIV_SHD to remain an implementation detail of shadow input value maintenance. In both 12.1.1 and 12.2.2 the object remains VALID in the APPS schema, and its behaviour follows the standard HRMS error-handling model.