Results for “prev_pay_basis”

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

Overview

The view APPS.PER_FULL_SALARY_HISTORY_V is a Human Resources (PER) product object in Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. ETRM documentation describes it simply as being "used to support user interface," and that description is accurate: the view is the data source for the Salary History and salary-basis comparison screens within the Oracle HRMS professional user interface, not a standalone reporting entity. It exposes, for each assignment, the element entry values that represent salary, along with the deltas and percentage changes between the selected entry and its preceding entry. It also resolves foreign-key values into their display forms, for example decoding PAY_BASIS through HR_GENERAL.DECODE_LOOKUP('PAY_BASIS', ...).

Because the view is designed for form and screen rendering, developers who query it directly for reporting should expect a row per assignment/element-entry combination with UI-oriented column positions, and should treat it as a convenient join point rather than an authoritative salary data model.

Underlying Base Objects

The view is defined over a substantial join of PER and PAY tables, including PER_ALL_ASSIGNMENTS_F (aliased twice, ASG and ASG2), PER_PEOPLE_F, PER_PAY_BASES (twice, PPB and PPB2), PER_TIME_PERIOD_TYPES, PER_PAY_PROPOSALS, PAY_ALL_PAYROLLS_F, PAY_ELEMENT_ENTRIES_F (twice, PEE and PEE2), PAY_ELEMENT_ENTRY_VALUES_F (twice, PEV and PEV2), PAY_ELEMENT_TYPES_F, PAY_ELEMENT_TYPES_F_TL, PAY_INPUT_VALUES_F, HR_ORGANIZATION_INFORMATION, and HR_POSITIONS. It also references PL/SQL packages HR_GENERAL, HR_API, HR_SECURITY, HR_PERSON_NAME, and FND_PROFILE.

The self-joins on element entries and entry values are the mechanism by which prior salary values are located and the difference and percentage change calculated. An important filter is the NOT EXISTS subquery against PER_PAY_PROPOSALS that excludes element entries created from salary proposals (CREATOR_TYPE = 'SP'), preventing proposal-driven rows from duplicating the effective salary history.

Key Columns

• ASSIGNMENT_ID, EFFECTIVE_START_DATE — the assignment and dated context for the salary record.
• SCREEN_ENTRY_VALUE — the salary amount (as a character string) from PAY_ELEMENT_ENTRY_VALUES_F.
• ELEMENT_ENTRY_ID — identifier of the element entry; the view returns 'Y'/'N' to indicate whether an entry exists.
• PAY_BASIS and its decoded lookup description — the pay basis for the entry and, via HR_GENERAL.DECODE_LOOKUP, its user-facing meaning. This is the column most commonly filtered by callers searching on pay_basis_id.
• RATE_ID, RATE_BASIS — the pay rate reference and its basis.
• NORMAL_HOURS, FREQUENCY, WORKING_HOURS — assignment working time and payroll frequency attributes.
• GRADE_ID, NUMBER_PER_FISCAL_YEAR, ORG_INFORMATION3, ORG_INFORMATION4 — grade, period type count, and organization flexfield context.
• ELEMENT_TYPE_ID, ELEMENT_NAME, OUTPUT_CURRENCY_CODE, INPUT_CURRENCY_CODE, UOM — element identity, name, currencies, and unit of measure.

Note that several output columns are explicitly cast placeholders (TO_CHAR(NULL), TO_NUMBER(NULL), TO_DATE(NULL)), used to align the select list with the consuming block's expected structure.

Common Use Cases and Queries

The primary use case is salary history review on an assignment, showing each change and its percentage movement. A typical query constrains by assignment and orders by effective date:

• Retrieve full history for an assignment:

SELECT assignment_id, effective_start_date, screen_entry_value,
       pay_basis, element_name, output_currency_code
FROM   apps.per_full_salary_history_v
WHERE  assignment_id = :p_assignment_id
ORDER  BY effective_start_date;

• Filter by a specific pay basis via the decoded lookup:

SELECT assignment_id, effective_start_date, screen_entry_value
FROM   apps.per_full_salary_history_v
WHERE  pay_basis = :p_pay_basis_id
AND    effective_start_date BETWEEN :p_from AND :p_to;

• Identify assignments whose salary element entries carry a pay basis, joining to PER_ALL_ASSIGNMENTS_F for current (latest) assignment rows.

Because the view performs self-joins and lookup decoding, direct queries can be expensive; restrict by ASSIGNMENT_ID or effective date ranges and avoid full-table scans on large PAY_ELEMENT_ENTRY_VALUES_F volumes.