Results for “per_recruiter_lov_v”

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

Overview

APPS.PER_RECRUITER_LOV_V is a Human Resources (PER) view shipped in Oracle E-Business Suite 12.1.1 and 12.2.2. Per the ETRM documentation, its stated purpose is "used to support user interface," meaning it exists primarily as a list-of-values (LOV) data source rather than as a transactional or reporting construct in its own right. The view presents a filtered perspective on the workforce, exposing the person identity and name attributes that the Oracle Forms-based Recruiter and related recruitment/requisition screens require when prompting a user to select a recruiter or responsible person.

In EBS 12.1.1 and 12.2.2, the object is owned by the APPS schema and holds a VALID status. Because the view is a thin wrapper over PER_ALL_WORKFORCE_V, it inherits the security model, effective-dating behavior, and business-group filtering already applied within that underlying workforce view. Its documentation status means it should be treated as an interface-support object with a stable but narrow column list. Reporting and integration consumers typically reach for it when they need the same recruiter population that the HRMS forms expose, without reconstructing the underlying join and filter logic themselves.

Underlying Base Objects

The ETRM metadata for 12.2.2 records the following referenced base objects:

• PER_ALL_WORKFORCE_V (VIEW) — the primary source; the view text documented is effectively a passthrough (SELECT * FROM PER_ALL_WORKFORCE_V) with a nesting wrapper. This is where the workforce/assignment joins, business-group scoping, and effective-dating logic reside.
• HR_PERSON_NAME (PACKAGE) — supplies name-formatting functions (via FORMAT_NAME) used to derive the display name attributes such as FULL_NAME and ORDER_NAME.
• FND_PROFILE (PACKAGE) — provides profile-option values, most notably BUSINESS_GROUP_ID, used to restrict the recruiter LOV to the session's current business group.

Consequently, PER_RECRUITER_LOV_V does not reference its own base tables directly; it depends entirely on PER_ALL_WORKFORCE_V, which in turn joins PER_ALL_PEOPLE_F and PER_ALL_ASSIGNMENTS_F (through the workforce construct) to present person-plus-assignment data.

Key Columns

• PERSON_ID — the unique party/person identifier; the primary key value returned by the LOV and subsequently stored on the calling form.
• FULL_NAME — the concatenated display name derived from HR_PERSON_NAME, used as the visible LOV description.
• ORDER_NAME — the name in alternate-order format, supporting sorted display and search.
• EMPLOYEE_NUMBER — the system-generated employee number, where the person is an employee.
• APPLICANT_NUMBER — the applicant identifier, where the person is an applicant/external candidate.
• NPW_NUMBER — the number assigned to non-payroll workers (contingent workers, contractors).
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — the effective-dating bounds of the person/assignment row returned.
• BUSINESS_GROUP_ID — the business group that scopes the returned workforce rows.

Common Use Cases and Queries

The view is most often queried to reproduce the recruiter LOV in custom reports or interfaces, or to validate that a stored recruiter value resolves to a current person. Typical usage includes:

• Populating a custom list-of-values or concurrent-program parameter for recruiter selection.
• Resolving a stored PERSON_ID back to a current FULL_NAME for display.
• Auditing which persons are visible to the recruiter LOV for a given business group.

Sample query:

SELECT person_id, full_name, order_name, employee_number, applicant_number, npw_number, business_group_id
FROM apps.per_recruiter_lov_v
WHERE business_group_id = fnd_profile.value('PER_BUSINESS_GROUP_ID')
ORDER BY order_name;

A second pattern resolves names for already-captured identifiers:

SELECT person_id, full_name
FROM apps.per_recruiter_lov_v
WHERE person_id = :p_person_id
AND TRUNC(SYSDATE) BETWEEN effective_start_date AND effective_end_date;

Because the view is UI-support and inherits the PER_ALL_WORKFORCE_V security and effective dating, consumers should always include the business-group predicate and respect the effective date range to avoid returning SIT (security-in-the-middle) records or unintended historical rows.