Search Results get_element_info

Overview

APPS.PAY_SIV_BUS is a server-side PL/SQL package body in the Oracle E-Business Suite HRMS/Payroll schema. Its name follows the Payroll "SIV" (Shadow Information Validation) naming convention used for business-layer packages that wrap validation logic for the shadow schema objects that Payroll uses to store template-driven element, formula, and balance feed definitions. The package serves as the business (BUS) tier companion to the corresponding table-handler (TBL/API) package, providing procedural business rules that govern how shadow records may be created, modified, and removed while preserving referential and functional integrity among templates and their dependent objects.

The package is classified in the ETRM repository as "OTHER" rather than as a public API, and it is referenced by three other packages, indicating that it is consumed internally by Payroll processing and setup components rather than being called directly by customer extensions. It is present in both Oracle EBS 12.1.1 and 12.2.2, and its header annotation (pysivrhi.pkb 120.0) reflects the original 11i-era build line retained through later releases.

Key Procedures and Functions

The ETRM metadata documents three procedures in this package: INSERT_VALIDATE, UPDATE_VALIDATE, and DELETE_VALIDATE. These are the standard business-layer validation hooks generated by the Oracle Application Object Library (AOL) table-handler pattern:

• INSERT_VALIDATE — Executes the business rules that must be satisfied before a new shadow record is inserted. It enforces template and element type consistency and confirms that mandatory parent references exist.
• UPDATE_VALIDATE — Applies the equivalent checks when an existing shadow record is changed, ensuring that modified attribute values remain consistent with the associated template and do not violate dependent-object relationships.
• DELETE_VALIDATE — Determines whether a shadow row may be removed, blocking deletion where dependent template core objects, formula rules, or exclusion rules still reference the record.

In addition, the package body contains non-documented helper procedures, notably get_element_info and get_template_info. The get_element_info procedure — the object associated with the user's search term — returns the template identifier and input currency code for a supplied element type identifier. It does so by joining PAY_SHADOW_ELEMENT_TYPES to PAY_ELEMENT_TEMPLATES on the element type identifier, and it uses HR_UTILITY.SET_LOCATION tracing consistent with Oracle's standard diagnostic instrumentation.

Tables Accessed

The package operates over the shadow and template schema. The documented tables include:

• PAY_SHADOW_ELEMENT_TYPES and PAY_ELEMENT_TEMPLATES — joined in get_element_info to resolve template and currency information.
• PAY_SHADOW_BALANCE_FEEDS, PAY_SHADOW_FORMULAS, PAY_SHADOW_FORMULA_RULES, PAY_SHADOW_INPUT_VALUES, PAY_SHADOW_ITERATIVE_RULES — the dependent shadow definitions validated during insert, update, and delete operations.
• PAY_TEMPLATE_CORE_OBJECTS and PAY_TEMPLATE_EXCLUSION_RULES — template-level structures consulted to determine whether a shadow record is still referenced and therefore protected from deletion.

All tables are addressed through APPS synonyms, and the package is expected to run under standard APPS schema privileges with no direct grants to end users.

Usage Notes

PAY_SIV_BUS is not intended to be called directly by customer code. It is invoked internally by the Payroll element and template setup forms, by the shadow schema maintenance concurrent processes, and by the three dependent packages recorded in ETRM. Developers tracing behavior for the keyword get_element_info should note that this routine is a private helper invoked during element information resolution, not a published API; it carries no explicit error handling for the NO_DATA_FOUND condition, so callers must ensure the element type identifier exists in PAY_SHADOW_ELEMENT_TYPES before invocation. Because the package writes tracing output through HR_UTILITY, DBMS trace or FND logging should be enabled when diagnosing failures during template or element setup.