Results for “per_positions_lov_v2”

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

Overview

APPS.PER_POSITIONS_LOV_V2 is a VALID database view owned by the APPS schema within the PER (Human Resources) product of Oracle E-Business Suite. The ETRM metadata classifies it explicitly as a view "used to support user interface," which distinguishes it from reporting-oriented or integration-oriented views. Its purpose is to back a List of Values (LOV) used in HR self-service and professional forms where a user must select a valid, currently available position.

Because it is an interface-support construction, the view is not intended as a general-purpose reporting source. Its result set is dynamically filtered against the current session and the current effective date, so it answers the question "which positions may this user select right now?" rather than "what positions have ever existed?" This session- and date-sensitivity is the defining characteristic of the view, and it has direct consequences for reporting and integration usage.

Underlying Base Objects

The documented base objects are HR_ALL_POSITIONS_F, HR_POSITIONS_F, PER_SHARED_TYPES, FND_SESSIONS, the package HR_GENERAL, and the package HR_SECURITY, with HR_ALL_POSITIONS_F_TL referenced in the documented metadata. The view text joins HR_POSITIONS_F (alias P1) to HR_ALL_POSITIONS_F (alias P2) on POSITION_ID, then joins PER_SHARED_TYPES to validate the position's availability status, and finally joins FND_SESSIONS to constrain the result set to the calling session's effective date.

Effective-dating is applied on both sides: P1 rows are filtered where the session effective date falls between EFFECTIVE_START_DATE and EFFECTIVE_END_DATE, while P2 rows are filtered using HR_GENERAL.END_OF_TIME. The PER_SHARED_TYPES join requires SHARED_TYPE_ID to match AVAILABILITY_STATUS_ID with LOOKUP_TYPE of 'POSITION_AVAILABILITY_STATUS', allowing a NULL business group. The SYSTEM_TYPE_CD must resolve to 'ACTIVE'.

Key Columns

• POSITION_NAME — the display value presented in the LOV, drawn from HR_ALL_POSITIONS_F.NAME.
• POSITION_ID — the primary identifier returned when a user selects a row; the value typically written back to the calling form or DFF.
• ORGANIZATION_ID — the business unit or organization owning the position, from HR_POSITIONS_F.
• JOB_ID — the job to which the position is mapped, enabling downstream job-based validation.
• BUSINESS_GROUP_ID — the HR business group that owns the position; critical for multi-organization and security-sensitive filtering.

Common Use Cases and Queries

The view is primarily invoked indirectly by Oracle Forms through the LOV mechanism. Direct querying is common during diagnostics, for example to confirm whether a position a user expects to see is being suppressed by an inactive availability status, a date range, or a business group mismatch:

• SELECT POSITION_ID, POSITION_NAME, ORGANIZATION_ID FROM APPS.PER_POSITIONS_LOV_V2 WHERE POSITION_ID = :p_position_id;
• SELECT COUNT(*) FROM APPS.PER_POSITIONS_LOV_V2; executed from a session to determine how many positions are selectable in that context.
• Comparing PER_POSITIONS_LOV_V2 membership with HR_ALL_POSITIONS_F to isolate rows excluded by availability status or effective dating.

Because the view depends on FND_SESSIONS and USERENV('SESSIONID'), results are not reproducible outside an active EBS session, and the row count may be zero when queried from tools such as SQL*Plus without a valid session context. This behavior should be expected and is not indicative of a defect. For reporting or integration, querying the underlying HR_POSITIONS_F and HR_ALL_POSITIONS_F tables directly is the recommended practice.