Results for “pay_shadow_iterative_rules”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PAY_SHADOW_ITERATIVE_RULES is a Payroll (PAY) module table owned by the HR schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented description is "Element Template Shadow Iterative Rules." The table stores the iterative rule definitions associated with shadow element templates — the "what-if" or simulated versions of payroll elements that payroll administrators use to model the effect of configuration changes before promoting them to the live element definition. Each row defines a single iteration rule that the payroll calculation engine evaluates repeatedly during a payroll run against a shadow element type, referencing either an input value or a template exclusion rule to determine the result.

From a Data Vault modeling perspective, the mined metadata places this object in the link category. That classification is a heuristic suggestion: the table's dominant pattern is a set of foreign key references that connect a shadow element type to an input value and an optional exclusion rule, which is characteristic of a link entity associating several hubs rather than a standalone reference (hub) or a descriptive (satellite) structure.

Key Information Stored

The documented physical schema contains 14 columns. The most significant are:

• ITERATIVE_RULE_ID — the surrogate primary key, defined by the PAY_SHADOW_ITERATIVE_RULES_PK constraint. It uniquely identifies each rule row.
• ZD_EDITION_NAME — the editioning column. Together with ITERATIVE_RULE_ID it forms the unique business-key candidate in the documented unique index, reflecting the Edition-Based Redefinition (EBR) architecture used in EBS 12.2.
• ELEMENT_TYPE_ID — foreign key to PAY_SHADOW_ELEMENT_TYPES; identifies the shadow element type to which the rule belongs.
• INPUT_VALUE_ID — foreign key to PAY_SHADOW_INPUT_VALUES; identifies the input value the rule reads or drives.
• EXCLUSION_RULE_ID — foreign key to PAY_TEMPLATE_EXCLUSION_RULES; identifies the exclusion rule that qualifies when this iterative rule does not apply.
• RESULT_NAME — the name of the result produced when the iterative rule executes.
• ITERATIVE_RULE_TYPE — classifies the rule, distinguishing the kind of iteration performed against the element type.
• SEVERITY_LEVEL — controls the severity assigned to the rule outcome, typically driving error, warning, or informational behavior.
• Standard audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY — record who changed the rule and when.
• OBJECT_VERSION_NUMBER — supports optimistic locking for concurrent updates.

Common Use Cases and Queries

Typical scenarios include auditing the iterative rules attached to a shadow element, reviewing exclusion coverage before promoting a shadow template to the live definition, and reporting by rule type or severity. A representative join resolves shadow element names and input values for a rule set:

• SELECT r.ITERATIVE_RULE_ID, r.RESULT_NAME, r.ITERATIVE_RULE_TYPE, r.SEVERITY_LEVEL FROM PAY_SHADOW_ITERATIVE_RULES r WHERE r.ELEMENT_TYPE_ID = :p_element_type_id
• Join to PAY_SHADOW_ELEMENT_TYPES on ELEMENT_TYPE_ID and to PAY_SHADOW_INPUT_VALUES on INPUT_VALUE_ID to render readable rule definitions for a configuration report.
• Use OBJECT_VERSION_NUMBER in the WHERE clause of updates to detect concurrent modification of rules.
• When querying under EBR in 12.2, filter on ZD_EDITION_NAME to select the correct edition of the rule set.

Related Objects

The documented foreign keys identify the primary related objects, all joined on their respective ID columns:

• PAY_SHADOW_ELEMENT_TYPES — joined via PAY_SHADOW_ITERATIVE_RULES.ELEMENT_TYPE_ID; the parent shadow element definition.
• PAY_SHADOW_INPUT_VALUES — joined via PAY_SHADOW_ITERATIVE_RULES.INPUT_VALUE_ID; the input against which the rule operates.
• PAY_TEMPLATE_EXCLUSION_RULES — joined via PAY_SHADOW_ITERATIVE_RULES.EXCLUSION_RULE_ID; limits rule applicability.

These three parent tables constitute the principal dependency chain. Because the table is a link entity, changes to shadow element types or their input values may cascade to the rules stored here, so referential integrity should be verified before deploying shadow template changes.