Results for “hrfv_salary_components”

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

Overview

HRFV_SALARY_COMPONENTS is a business view template owned by the APPS schema in Oracle E-Business Suite, delivered under the PER (Human Resources) product family. As its description states, it is a "business view template from which the flexfield view is generated." In practice, this view provides a flattened, denormalized representation of salary proposal component data, joining pay proposals, proposal components, assignments, people, and business group information into a single queryable object. Because it is a template rather than a purely static object, the view is associated with a descriptive flexfield context identifier (the "_DF" column, pointing to PER:PER_PAY_PROPOSAL_COMPONENTS:PCOMP), which enables the generation of flexfield-aware reporting views used by Oracle HRMS and its downstream reporting tools.

For users of Oracle EBS 12.1.1 and 12.2.2, this view is significant because it exposes the APPROVED_FLAG column — a decoded representation of the approval status of a salary proposal component. This is directly relevant for anyone searching on approved_flag, since the view translates the underlying APPROVED value in PER_PAY_PROPOSAL_COMPONENTS into a readable Yes/No value via the BIS_DECODE_LOOKUP function.

Underlying Base Objects

The view is defined over the following documented base objects:

• PER_PAY_PROPOSAL_COMPONENTS (SYNONYM) — the core salary component/line detail.
• PER_PAY_PROPOSALS (SYNONYM) — the parent proposal header, supplying the change date.
• PER_ALL_ASSIGNMENTS_F (SYNONYM) — the assignment effective-dated record.
• PER_PEOPLE_X (VIEW) — the person record with effective dating.
• HR_ALL_ORGANIZATION_UNITS_TL (SYNONYM) — provides the translated business group name.
• HR_BIS (PACKAGE) — supplies BIS_DECODE_LOOKUP for decoding lookup values.
• HR_GENERAL, HR_PERSON_NAME, HR_SECURITY (PACKAGES) — supporting utilities, including security profile filtering.

The joins are effective-dated: assignment dates must fall between the person's and proposal's effective ranges, and the business group is filtered through HR_BIS.GET_SEC_PROFILE_BG_ID so that only records within the user's security profile are returned. The view is created WITH READ ONLY.

Key Columns

• BUSINESS_GROUP_NAME — the translated name of the business group.
• PERSON_NAME and EMPLOYEE_NUMBER — the employee identity fields.
• SALARY_CHANGE_REASON — decoded proposal reason (via PROPOSAL_REASON lookup).
• APPROVED_FLAG — decoded Yes/No value for the component's approval status.
• SALARY_CHANGE_AMOUNT and SALARY_CHANGE_PERCENTAGE — the numeric and percentage change values.
• SALARY_CHANGE_DATE — the effective date of the proposal.
• CURRENT_EMPLOYEE_FLAG — decoded Yes/No indicator of current employment.
• ASSIGNMENT_NUMBER, ASSIGNMENT_ID, BUSINESS_GROUP_ID, PAY_PROPOSAL_ID, PERSON_ID, SALARY_COMPONENT_ID — identifiers used for joining and drill-down.
• "_DF" — a placeholder identifying the descriptive flexfield context for generated flexfield views.

Common Use Cases and Queries

This view is typically used in HRMS reporting, salary review analysis, and integration extracts. A common query filters on the approved flag to return only approved salary components:

SELECT person_name, employee_number, salary_change_reason,
       salary_change_amount, salary_change_percentage, salary_change_date
FROM   apps.hrfv_salary_components
WHERE  approved_flag = 'Yes'
ORDER BY salary_change_date DESC;

Another scenario reports pending (unapproved) changes by business group and reason:

SELECT business_group_name, salary_change_reason, COUNT(*)
FROM   apps.hrfv_salary_components
WHERE  approved_flag = 'No'
GROUP BY business_group_name, salary_change_reason;

Because the view enforces security profile filtering on business group and is read-only, it is safe for ad-hoc reporting and integration extracts without risking data modification. Analysts searching on approved_flag should note that the column returns decoded text values derived from the YES_NO lookup, not the raw Y/N codes stored in the base table.