Search Results customer_user

Overview

APPS.ENG_SEARCH_PEOPLE_V is a reporting view in Oracle E-Business Suite that exposes a unified, de-duplicated roster of system users who are associated with a person party record. Its name reflects its original function within the Engineering module search infrastructure: presenting a consolidated list of "people" who can be located by name or username within Oracle EBS. The view is owned by the APPS schema and is defined over synonyms of core EBS tables.

The defining characteristic of this view is that it merges three distinct person categories into a single result set using UNION ALL: internal employees, vendor users, and customer users. The PERSON_TYPE column carries the literal flag 'INTERNAL', 'VENDOR', or 'CUSTOMER' to identify the origin of each row. This design allows a single query to enumerate every FND_USER record that can be linked to a person party, regardless of how that person's party record is classified in the trading community data model. For users searching on terms such as "customer_user," this view is the object that surfaces FND_USER rows linked through HZ_PARTIES to HZ_CUST_ACCOUNTS.

Underlying Base Objects

The documented base objects referenced by the view are FND_USER, HZ_CODE_ASSIGNMENTS, HZ_CUST_ACCOUNTS, HZ_PARTIES, and PER_ALL_PEOPLE_F, each accessed through APPS-schema synonyms. The view is constructed from three branches joined by UNION ALL:

• Internal branch: Joins HZ_PARTIES (aliased EMPLOYEE) to PER_ALL_PEOPLE_F and FND_USER, matching on HR_EMPLOYEE.PERSON_ID = FND_USER.EMPLOYEE_ID and EMPLOYEE.PARTY_ID = HR_EMPLOYEE.PARTY_ID. The party_type is restricted to 'PERSON'.
• Vendor branch: Joins HZ_PARTIES (aliased VENDOR_USER) to HZ_CODE_ASSIGNMENTS and FND_USER. The code assignment must have OWNER_TABLE_NAME = 'HZ_PARTIES', CLASS_CODE = 'VENDOR_USER', and CLASS_CATEGORY = 'POS_PARTICIPANT_TYPE'. FND_USER is linked by CUSTOMER_ID and must have a null EMPLOYEE_ID.
• Customer branch: Joins HZ_PARTIES (aliased CUSTOMER_USER) to FND_USER where the party is a person and an HZ_CUST_ACCOUNTS row exists for that party_id. FND_USER is linked by CUSTOMER_ID and EMPLOYEE_ID must be null.

The outer SELECT DISTINCT collapses duplicate person/user pairings that could arise where multiple customer accounts or assignments reference the same party.

Key Columns

• PERSON_ID — Derived from HZ_PARTIES.PARTY_ID. Identifies the person party record and is the primary linking key to the trading community model.
• PERSON_NAME — Derived from HZ_PARTIES.PARTY_NAME. The display name of the person party.
• USER_ID — The FND_USER primary key of the associated application user account.
• USER_NAME — The FND_USER login name used for authentication and audit attribution.
• PERSON_TYPE — Literal discriminator indicating 'INTERNAL', 'VENDOR', or 'CUSTOMER' to denote the party's classification path.

Common Use Cases and Queries

The view is typically used for troubleshooting user identity issues, reconciling customer and vendor portal users against their party records, and building LOV-style lookups. A representative query to isolate customer users is:

SELECT person_id, person_name, user_id, user_name FROM apps.eng_search_people_v WHERE person_type = 'CUSTOMER' ORDER BY person_name;

To locate a specific login across all person categories:

SELECT person_type, person_id, person_name, user_id, user_name FROM apps.eng_search_people_v WHERE user_name = :p_user_name;

Because the view is read-only and built on current FND_USER and HZ_PARTIES data, it is suited to ad hoc reporting and integration lookups rather than transactional processing.