Results for “pa_key_members_lov_v”

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

Overview

PA_KEY_MEMBERS_LOV_V is a database view owned by the APPS schema within the Oracle E-Business Suite. It belongs to the Projects (PA) product family and is delivered with a VALID status in both release 12.1.1 and 12.2.2. As its name implies, the object is designed to serve as a list of values (LOV) source. Its stated purpose is to display all key members associated with a given project or project template. In EBS forms and self-service pages, key members are the individuals designated to fill defined project roles, such as project manager, project administrator, or team member. This view provides a simplified row source that returns the person identifiers and display names required by those LOV components. Because it exposes only a narrow set of attributes, it functions as a presentation-layer convenience object rather than a transactional table. Reporting and integration developers occasionally query it directly when they need the same candidate pool of employees that the Projects forms present to end users, but its principal role remains supporting the key member assignment and inquiry flows within Oracle Projects.

Underlying Base Objects

According to the documented view text, PA_KEY_MEMBERS_LOV_V is defined with a single SELECT statement over one base object: the PA_EMPLOYEES view. The view text selects E.PERSON_ID and E.FULL_NAME from PA_EMPLOYEES E, filtered by the condition E.ACTIVE = '*'. This means the view returns only currently active employees as flagged within the Projects employee repository. Although the view text references only PA_EMPLOYEES, the ETRM metadata lists several additional referenced objects that participate indirectly through that underlying view and through security enforcement. These include the HR_GENERAL package, the HR_PERSON_NAME package, the HR_SECURITY package, and the PA_EMPLOYEES view itself. HR_SECURITY is of particular significance, as it enforces row-level security so that a querying user sees only the employees to which their security profile grants access. HR_PERSON_NAME supplies the formatted name value surfaced through the FULL_NAME column. In effect, the view is a thin projection over PA_EMPLOYEES, inheriting its security behavior and its dependency on core HR packages.

Key Columns

The view exposes a deliberately minimal column list. The PERSON_ID column carries the unique identifier of the employee or person record and corresponds to the PERSON_ID attribute of PA_EMPLOYEES. This is the value typically stored when a key member is assigned to a project role, making it the join key back to PA_PROJECT_PARTIES and related assignment tables. The FULL_NAME column carries the formatted display name of the person, derived through the HR_PERSON_NAME package logic, and is the value rendered to users in the LOV. The ETRM document also enumerates CODE and DESCRIPTION as documented attributes of the object. Because the SELECT is restricted to active employees, the returned candidate list automatically excludes terminated or inactive personnel without requiring callers to add their own status predicate. Consumers should not expect role, project, or assignment attributes from this view; it returns people, not project-specific role assignments.

Common Use Cases and Queries

The view is most frequently used as the validation and display source behind key member LOV fields on Oracle Projects forms. Developers building custom concurrent programs, OAF pages, or BI Publisher reports use it when they need the same active-employee pick list that standard Projects functionality presents. A typical inquiry is:

• SELECT person_id, full_name FROM apps.pa_key_members_lov_v WHERE full_name LIKE :search ORDER BY 2;
• SELECT person_id, full_name FROM apps.pa_key_members_lov_v WHERE person_id = :person_id;

The first query supports a search-and-select pattern for populating a key member, while the second validates a previously stored PERSON_ID. When resolving an existing key member assignment, the view is commonly joined to PA_PROJECT_PARTIES on PERSON_ID to obtain the display name alongside role and project context. Because HR_SECURITY governs the rows returned, results vary by the responsibility and security profile of the executing user; integration scripts that run under a privileged account may return a broader set than an end user would see. Callers should therefore avoid relying on the view for exhaustive employee enumeration and instead reference HR_EMPLOYEES or PER_ALL_PEOPLE_F when a complete, unfiltered list is required.