Search Results manager_person_id




Overview
Explore in AI Chat

Overview

JTF_RS_EMP_DTLS_VL is a CRM Foundation (JTF) reporting view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It resolves the employee-facing subset of the resource registry, returning one row for every resource record in JTF_RS_RESOURCE_EXTNS_VL whose CATEGORY attribute equals 'EMPLOYEE'. In other words, it isolates human resources that represent employees (as opposed to, for example, supplier contacts, teams, or other non-employee resource categories) and republishes the employee attributes under report-friendly column aliases.

The object is a standard, VALID view rather than a table, so it stores no data of its own; every query against it is rewritten against the underlying resource extension view at runtime. Its primary role is to give forms, concurrent programs, OBIEE extracts, and custom integrations a stable, semantically clear source of employee resource data, including identifiers such as RESOURCE_ID, SOURCE_ID, and PERSON_PARTY_ID, organizational context such as ORG_ID and ORG_NAME, and — the attribute most frequently searched by developers — MANAGER_PERSON_ID.

Underlying Base Objects

According to the documented view text, JTF_RS_EMP_DTLS_VL is defined over a single referenced base object: JTF_RS_RESOURCE_EXTNS_VL, aliased in the SQL as RSC. The defining predicate is a hard-coded filter, RSC.CATEGORY = 'EMPLOYEE', which restricts the result set to employee-category resources. The extension view itself aggregates resource header data (JTF_RS_RESOURCE_EXTNS / JTF_RS_RESOURCE_EXTNS_TL and related party, contact, and address information), which is why column names in JTF_RS_EMP_DTLS_VL often prefix the source attribute with SOURCE_ (for example SOURCE_ID, SOURCE_FIRST_NAME, SOURCE_MGR_ID). The view is a lightweight projection and rename layer: it adds no joins, no group-by clauses, and no business logic beyond the category restriction, so performance characteristics are inherited directly from JTF_RS_RESOURCE_EXTNS_VL.

Key Columns

  • RESOURCE_ID / RESOURCE_NUMBER — resource registry primary key and human-readable resource number; the standard foreign key for JTF resource references.
  • SOURCE_ID — identifier of the originating entity (typically the HR person or party), allowing joins back to PER_* tables for authoritative HR attributes.
  • PERSON_PARTY_ID / CONTACT_ID / ADDRESS_ID — HZ party, contact, and location references for the employee.
  • MANAGER_PERSON_ID — the person identifier of the employee's manager, drawn from RSC.SOURCE_MGR_ID. It is a PERSON_ID (party-based), not a RESOURCE_ID, so joins to PER_ALL_PEOPLE_F or HZ_PARTIES should use PERSON_ID / PARTY_ID. MANAGER_NAME supplies the denormalized manager display name.
  • FULL_NAME, FIRST_NAME, MIDDLE_NAME, LAST_NAME — the employee's name components sourced from the SOURCE_ attributes.
  • EMPLOYEE_NUMBER — the HR employee number (RSC.SOURCE_NUMBER), the standard integration key to Oracle HRMS.
  • EMP_CATEGORY / EMP_STATUS — employee category and status; EMP_CATEGORY retains the value 'EMPLOYEE' for this view.
  • ORG_ID / ORG_NAME — the business group of the employee, used for multi-organization (MOAC) filtering.
  • JOB_ID / JOB_TITLE, EMAIL, PHONE — assignment and contact details.
  • EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — resource active date range (aliased from START_DATE_ACTIVE / END_DATE_ACTIVE).
  • USER_ID — the FND user account linked to the resource, where one exists.

Common Use Cases and Queries

The view is typically used to list employees for assignment pickers, to drive approval-routing logic that must walk the management hierarchy, and to extract resource metadata into reporting layers. Because MANAGER_PERSON_ID is the column most often sought, a frequent pattern is to expose the employee-to-manager relationship together with HR-sourced manager details.

  • List employees and their managers for a given business group:

    SELECT RESOURCE_ID, EMPLOYEE_NUMBER, FULL_NAME, MANAGER_PERSON_ID, MANAGER_NAME FROM APPS.JTF_RS_EMP_DTLS_VL WHERE ORG_ID = :p_org_id AND SYSDATE BETWEEN EFFECTIVE_START_DATE AND NVL(EFFECTIVE_END_DATE, SYSDATE + 1);

  • Resolve managers to HR person records:

    SELECT V.FULL_NAME, V.MANAGER_PERSON_ID, P.FULL_NAME MANAGER_NAME FROM APPS.JTF_RS_EMP_DTLS_VL V LEFT JOIN APPS.PER_PEOPLE_F P ON P.PERSON_ID = V.MANAGER_PERSON_ID AND SYSDATE BETWEEN P.EFFECTIVE_START_DATE AND P.EFFECTIVE_END_DATE WHERE V.EMPLOYEE_NUMBER = :p_emp_num;

  • Feed a CRM resource or escalation report with active employee resources:

    SELECT RESOURCE_NUMBER, FULL_NAME, JOB_TITLE, EMAIL FROM APPS.JTF_RS_EMP_DTLS_VL WHERE EMP_STATUS = 'ACTIVE';

  • Join to FND_USER for self-service or assignment validation:

    SELECT V.RESOURCE_ID, V.FULL_NAME, U.USER_NAME FROM APPS.JTF_RS_EMP_DTLS_VL V JOIN APPS.FND_USER U ON U.USER_ID = V.USER_ID;

Because the view is a VL-layer object over JTF_RS_RESOURCE_EXTNS_VL, queries should apply the RESOURCE_ID, EMPLOYEE_NUMBER, or ORG_ID predicates at the top level; the underlying view exposes no additional indexes of its own, so filtering on these selective columns keeps the execution plan efficient. All access should be granted through the APPS synonym rather than querying the base view directly, ensuring consistency with the documented definition and forward compatibility across 12.1.1 and 12.2.2.