Search Results vendor_user




Overview
Explore in AI Chat

Overview

The APPS.ENG_SEARCH_PEOPLE_V view is a reporting and integration object within the Oracle E-Business Suite Engineering (ENG) product family. It presents a unified, de-normalized list of system users who can be attributed to a person record, spanning three distinct participant categories: internal employees, vendor users, and customer users. The view resolves the dichotomy in EBS between Oracle Applications users (defined in FND_USER) and the underlying parties/people records held in the TCA (Trading Community Architecture) and HRMS models, exposing a single row per (person, user) pairing together with a classification label.

Its primary role is to support Engineering search and selection interface elements, where the application must present selectable "people" whose origin may be an employee, a supplier contact, or a customer contact. Because the view consolidates all three populations with a common column projection, consuming forms, search pages, and integrations can query a single source rather than union logic across multiple tables. In releases 12.1.1 and 12.2.2 the definition is unchanged, and the object is documented as VALID in the APPS schema under ETRM metadata.

Underlying Base Objects

The view is defined as a three-way UNION ALL over the synonym-referenced base objects FND_USER, HZ_PARTIES, PER_ALL_PEOPLE_F, HZ_CODE_ASSIGNMENTS, and HZ_CUST_ACCOUNTS. Each branch of the union targets a different person type:

The use of DISTINCT at the head of the first branch (and union semantics throughout) prevents duplicate person/user combinations. All base objects are accessed through APPS synonyms, so the view inherits the standard EBS security and compilation dependencies of its owning schema.

Key Columns

The view exposes five columns:

  • PERSON_ID — the HZ_PARTIES.PARTY_ID of the person; the primary identifier for the individual across TCA and HRMS.
  • PERSON_NAME — the party name of the person, suitable for display in search and selection lists.
  • USER_ID — the FND_USER.USER_ID of the associated application user account.
  • USER_NAME — the FND_USER.USER_NAME login credential.
  • PERSON_TYPE — a derived literal value of 'INTERNAL', 'VENDOR', or 'CUSTOMER', classifying the origin of the person.

Common Use Cases and Queries

The view is commonly used to drive LOVs, search pages, and integration extracts where an application user must be mapped to a TCA party. Boolean filtering by PERSON_TYPE is the most frequent access pattern.

Retrieve all customer-type users:

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

Locate the user account for a known party:

  • SELECT user_name, person_type FROM apps.eng_search_people_v WHERE person_id = :party_id;

Resolve a login to its party and classification:

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

Because the customer branch requires existence of a matching HZ_CUST_ACCOUNTS row and excludes employees, results reflect only genuine external customer users; similarly, the vendor branch depends on a POS participant type assignment. Queries joining this view to FND_USER, HZ_PARTIES, or PER_ALL_PEOPLE_F should account for the DISTINCT/UNION semantics when counting persons, since a single party may theoretically appear under only one PERSON_TYPE by construction of the mutually exclusive join predicates.