Search Results pay_retro_component_usages




Overview
Explore in AI Chat

Overview

PAY_RETRO_COMPONENT_USAGES is a payroll configuration table residing in the HR schema within Oracle E-Business Suite (available in both 12.1.1 and 12.2.2). It defines the usage rules that govern how retroactive (retro) components are applied to payroll element entries when retroactive processing recalculates prior periods. Each row associates a retro component with a creator (typically an element or element type) and specifies how that component should be defaulted, reprocessed, and whether override dates or replacement runs apply when backdated changes trigger recalculation. The table therefore acts as the controlling metadata layer behind Oracle Payroll's retroactive pay functionality.

The documented Data Vault classification is standalone, meaning the table is not strictly modeled as a hub, link, or satellite in the mined dependency graph. From a modeling perspective, this suggests treating it as a standalone reference or configuration entity rather than a transactional fact or a pure relationship table, though its business key structure (combining retro component and creator) gives it link-like characteristics that can be modeled as a link–satellite pairing if a Data Vault representation is required.

Key Information Stored

The table contains seventeen documented columns. The most significant include:

The unique index PAY_RETRO_COMPONENT_USAGES_UK1 (RETRO_COMPONENT_ID, CREATOR_ID, CREATOR_TYPE, BUSINESS_GROUP_ID, LEGISLATION_CODE, ZD_EDITION_NAME) is the principal business-key candidate, preventing duplicate usage definitions per component, creator, group, and legislation.

Common Use Cases and Queries

Typical uses include auditing which components are defaulted for a given retro component, diagnosing unexpected retro calculations, and validating configuration during upgrades or data migrations. A common pattern retrieves all active usages for a component:

SELECT rcu.retro_component_usage_id, rcu.retro_component_id, rcu.creator_id, rcu.creator_type, rcu.default_component, rcu.reprocess_type, rcu.replace_run_flag, rcu.use_override_dates FROM hr.pay_retro_component_usages rcu WHERE rcu.retro_component_id = :component_id AND rcu.business_group_id = :bg_id;

Because the foreign key relationship to PAY_ELEMENT_SPAN_USAGES carries RETRO_COMPONENT_USAGE_ID, reporting queries frequently join the two to trace span-level usage back to its driving rule:

SELECT esu.element_span_usage_id, esu.retro_component_usage_id, rcu.reprocess_type FROM hr.pay_element_span_usages esu, hr.pay_retro_component_usages rcu WHERE esu.retro_component_usage_id = rcu.retro_component_usage_id;

Related Objects

Understanding these relationships is essential when troubleshooting retroactive payroll results and interpreting the reprocess and replacement-run behavior driven by this configuration table.