Results for “per_pay_proposal_components”

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

Overview

The PER_PAY_PROPOSAL_COMPONENTS table, owned by the HR schema in Oracle E-Business Suite, stores the individual component details that make up a pay proposal for an employee assignment. Within the PAY (Payroll) product family, this table acts as the transactional detail layer beneath the header-level pay proposal record, capturing each distinct element of a proposed compensation change — such as a salary adjustment, a percentage-based increase, or an approved amount revision — together with its reason and approval state.

Pay proposals are used by compensation and HR administrators to model, submit, and approve changes to an employee's pay. A single pay proposal can contain multiple components, allowing a change to be decomposed into discrete, individually reasoned and individually approvable pieces. Each row in this table represents one such component and is anchored both to its parent proposal (through PAY_PROPOSAL_ID) and to the business group that owns the data (through BUSINESS_GROUP_ID).

From a dimensional modeling perspective, the ETRM metadata's heuristic Data Vault classification for this object is a link. That is, the table is best understood as an associative structure connecting a pay proposal to its component-level detail, with attributes such as amounts, percentages, approval status, and reason acting as descriptive payload on that association.

Key Information Stored

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

• COMPONENT_ID — The surrogate primary key (PER_PAY_PROPOSAL_COMPONENT_PK) that uniquely identifies each component row.
• PAY_PROPOSAL_ID — Foreign key to PER_PAY_PROPOSALS, identifying the parent proposal to which the component belongs. This column participates in the unique business key PER_PAY_PROPOSAL_COMPONENT_UK2.
• COMPONENT_REASON — The reason or nature of the proposed change; combined with PAY_PROPOSAL_ID, this forms the documented unique business key, enforcing that a proposal cannot carry two components with the same reason.
• BUSINESS_GROUP_ID — Foreign key to HR_ALL_ORGANIZATION_UNITS, providing the multi-tenant business group context.
• APPROVED — The approval flag indicating whether this component has been authorized.
• CHANGE_AMOUNT and CHANGE_AMOUNT_N — The monetary value of the change (the _N suffix typically denotes a numeric storage variant).
• CHANGE_PERCENTAGE — The percentage-based change applied to the component.
• NEW_AMOUNT — The resulting target amount for the component.
• COMMENTS — Free-text notes recorded against the component.
• OBJECT_VERSION_NUMBER — Optimistic locking and concurrency control for the row.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — Standard EBS audit columns tracking who created and last modified the row.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE20 — The standard EBS descriptive flexfield (DFF) column set for extensible customer-defined attributes.

Common Use Cases and Queries

Typical uses include reporting on pending versus approved compensation changes, reconciling proposed amounts to their resulting new amounts, and auditing the reasons behind pay changes. Because the business key is (PAY_PROPOSAL_ID, COMPONENT_REASON), queries frequently retrieve all components for a given proposal.

• Listing all components of a specific proposal:

  SELECT component_id, component_reason, change_amount,
         change_percentage, new_amount, approved
    FROM   hr.per_pay_proposal_components
   WHERE   pay_proposal_id = :p_proposal_id;

• Identifying unapproved components awaiting action:

  SELECT pay_proposal_id, component_reason, new_amount
    FROM   hr.per_pay_proposal_components
   WHERE   approved = 'N';

• Aggregating proposed change value by proposal:

  SELECT pay_proposal_id, SUM(change_amount) total_change
    FROM   hr.per_pay_proposal_components
   GROUP   BY pay_proposal_id;

• Joining to the parent proposal for assignment-level reporting, linking via PAY_PROPOSAL_ID, and filtering by BUSINESS_GROUP_ID for security-scoped reporting.

Related Objects

• PER_PAY_PROPOSALS — The parent table; joined on PER_PAY_PROPOSAL_COMPONENTS.PAY_PROPOSAL_ID = PER_PAY_PROPOSALS.PAY_PROPOSAL_ID. Provides proposal-level context such as the assignment and effective dates.
• HR_ALL_ORGANIZATION_UNITS — Referenced through BUSINESS_GROUP_ID to resolve the owning business group.
• PER_ASSIGNMENTS (indirectly via the parent proposal) — Supplies the employee assignment against which the proposed component applies.
• Payroll and compensation APIs — PL/SQL packages that create, update, and approve pay proposals typically manipulate this table through the parent proposal logic rather than direct DML.
• Related proposal and component views supplied by the PAY/HR modules, which join this table to the proposal header for reporting.