Results for “per_pay_proposals”

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

Overview

PER_PAY_PROPOSALS is a Human Resources (PER) module table in the HR schema of Oracle E-Business Suite, documented as valid in both release 12.1.1 and 12.2.2. It stores salary proposals and performance review information associated with employee assignments. Each row represents a proposed compensation change or review cycle entry for a specific assignment, capturing the proposed salary, performance ratings, review dates, and approval state. The table therefore serves as the transactional record of the compensation and performance-management workflow, linking assignment-level context to both the HR event that triggered it and the performance review that informs it.

From a dimensional modeling perspective, the ETRM-derived Data Vault classification for this table is satellite-leaning. This classification is a heuristic suggestion rather than a physical constraint. It reflects that PER_PAY_PROPOSALS carries descriptive, time-stamped attribute payload (proposed amounts, ratings, dates) keyed by a surrogate identifier, with limited independent relationship fan-out — the characteristics of a satellite rather than a hub or link. Modelers should treat this as guidance when designing downstream integration or warehouse layers.

Key Information Stored

The table is documented with 46 columns in the HR schema. The most operationally significant are:

• PAY_PROPOSAL_ID — the surrogate primary key, per the unique index PER_PAY_PROPOSALS_PK.
• ASSIGNMENT_ID — the assignment to which the proposal applies.
• EVENT_ID — foreign key to PER_EVENTS, tying the proposal to the triggering HR event.
• BUSINESS_GROUP_ID — foreign key to HR_ALL_ORGANIZATION_UNITS, scoping the record to the business group.
• PERFORMANCE_REVIEW_ID — foreign key to PER_PERFORMANCE_REVIEWS, linking the proposal to its review record.
• PROPOSED_SALARY and PROPOSED_SALARY_N — the proposed compensation amount (character and numeric representations, respectively).
• PERFORMANCE_RATING — the rating captured for the review.
• PROPOSAL_REASON — the reason code for the proposal.
• APPROVED — the approval status flag.
• CHANGE_DATE, REVIEW_DATE, REVIEW_DATE and DATE_TO — effective-dating columns governing the proposal's validity.
• NEXT_PERF_REVIEW_DATE and NEXT_SAL_REVIEW_DATE — scheduling dates for subsequent cycles.
• MULTIPLE_COMPONENTS and FORCED_RANKING — control flags for multi-component proposals and forced-ranking logic.
• OBJECT_VERSION_NUMBER — concurrency-control token.
• Standard WHO audit columns: LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE, plus ATTRIBUTE1–20 and ATTRIBUTE_CATEGORY for descriptive flexibility.

The documented unique indexes are PER_PAY_PROPOSALS_PK on PAY_PROPOSAL_ID and SYS_IL0000043921C00045$$ (the latter an internal LOB/index artifact, not a business key). PAY_PROPOSAL_ID is thus the only documented business-key candidate.

Common Use Cases and Queries

Typical reporting scenarios involve extracting active or approved proposals for a given assignment or organization, reconciling proposal amounts against component breakdowns, and tracking the approval workflow. A common pattern joins the parent event and business group to resolve context:

• Active proposals for an assignment: SELECT * FROM per_pay_proposals WHERE assignment_id = :id AND (date_to IS NULL OR date_to > SYSDATE);
• Approved proposals by business group: SELECT p.* FROM per_pay_proposals p, hr_all_organization_units o WHERE p.business_group_id = o.organization_id AND p.approved = 'Y';
• Proposal with its component detail: SELECT p.pay_proposal_id, c.* FROM per_pay_proposals p, per_pay_proposal_components c WHERE c.pay_proposal_id = p.pay_proposal_id;
• Proposals tied to a performance review: SELECT p.* FROM per_pay_proposals p, per_performance_reviews r WHERE p.performance_review_id = r.performance_review_id;
• Upcoming salary reviews: SELECT assignment_id, next_sal_review_date FROM per_pay_proposals WHERE next_sal_review_date BETWEEN SYSDATE AND ADD_MONTHS(SYSDATE,3);

These queries underpin compensation analytics, merit-increase reporting, and audit of approval cycles.

Related Objects

PER_PAY_PROPOSALS sits within a tightly related cluster of PER and BEN objects. The most significant referenced and referencing tables are:

• PER_EVENTS — via PER_PAY_PROPOSALS.EVENT_ID.
• HR_ALL_ORGANIZATION_UNITS — via PER_PAY_PROPOSALS.BUSINESS_GROUP_ID.
• PER_PERFORMANCE_REVIEWS — via PER_PAY_PROPOSALS.PERFORMANCE_REVIEW_ID.
• PER_PAY_PROPOSAL_COMPONENTS — child table referencing this table via PAY_PROPOSAL_ID.
• BEN_CWB_RPT_DETAIL — benefits compensation workbench reporting detail referencing PAY_PROPOSAL_ID.
• BEN_CWB_PERSON_RATES — person rate storage referencing PAY_PROPOSAL_ID.

These relationships position PER_PAY_PROPOSALS as the central proposal header, with component-level detail and benefits-side rate records hanging from its primary key.