Search Results ego_vendor_v




Overview
Explore in AI Chat

Overview

EGO_VENDOR_V is a reporting view owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It belongs to the EGO product family, Advanced Product Catalog, and its documented purpose is to store the vendor identifiers associated with supplier contacts. Rather than maintaining an independent data store, the view consolidates information from four base objects — FND_USER, AP_SUPPLIER_CONTACTS, AP_SUPPLIERS, and HZ_RELATIONSHIPS — to produce a single, denormalized result set linking an application user to a supplier (vendor) identifier.

The object is registered in ETRM with a status of VALID and is classified as a VIEW. Because it is a view rather than a table, it carries no data of its own; every query executes the underlying join at runtime. This makes it a convenient integration and reporting surface for modules that need to resolve the relationship between a named user and the vendor record they represent, without requiring developers to reconstruct the multi-table join themselves.

Underlying Base Objects

The ETRM metadata documents four referenced base objects, all exposed through SYNONYM entries in the APPS schema:

  • AP_SUPPLIERS — the supplier header table, aliased ASA, providing VENDOR_ID.
  • AP_SUPPLIER_CONTACTS — the supplier contact association table, aliased AC, supplying PER_PARTY_ID and RELATIONSHIP_ID.
  • FND_USER — the application user repository, aliased FU, supplying USER_NAME and USER_ID.
  • HZ_RELATIONSHIPS — the Trading Community Architecture relationship table, aliased HR, supplying RELATIONSHIP_ID and OBJECT_ID.

The view text joins FND_USER.PERSON_PARTY_ID to AP_SUPPLIER_CONTACTS.PER_PARTY_ID, AP_SUPPLIER_CONTACTS.RELATIONSHIP_ID to HZ_RELATIONSHIPS.RELATIONSHIP_ID, and HZ_RELATIONSHIPS.OBJECT_ID to AP_SUPPLIERS.PARTY_ID. The presence of SELECT DISTINCT indicates that the join can generate duplicate rows and that the view deliberately returns a unique set of user-to-vendor combinations.

Key Columns

The view exposes exactly three columns, each with a clear lineage:

  • USER_NAME — the application user login name drawn from FND_USER.USER_NAME; identifies the contact as a system user.
  • USER_ID — the surrogate key from FND_USER.USER_ID, suitable for joins back to FND_USER or to responsibility and session tables.
  • VENDOR_ID — the supplier identifier from AP_SUPPLIERS.VENDOR_ID, resolving the vendor against which the user is registered as a contact.

Because the view contains no descriptive supplier attributes (for example supplier name or supplier number), it functions primarily as a mapping or cross-reference structure rather than a full supplier master reporting source.

Common Use Cases and Queries

The view is most frequently used when a report or interface must determine which vendor a given application user is associated with, or conversely which users act as contacts for a vendor. Typical scenarios include supplier portal style reporting, user-to-vendor validation during data conversion, and reconciliation of contact records held in AP_SUPPLIER_CONTACTS against FND_USER.

A basic lookup returning all user-to-vendor mappings:

  • SELECT user_name, user_id, vendor_id FROM apps.ego_vendor_v;

Restricting the result to a single vendor:

  • SELECT user_name, user_id FROM apps.ego_vendor_v WHERE vendor_id = :p_vendor_id;

Resolving a user to the supplier header for descriptive detail:

  • SELECT v.user_name, s.vendor_name, s.vendor_number FROM apps.ego_vendor_v v, apps.ap_suppliers s WHERE v.vendor_id = s.vendor_id AND v.user_id = :p_user_id;

Because the search term ap_supplier_contacts leads directly to this object, developers investigating contact-to-vendor relationships should treat EGO_VENDOR_V as the documented, supported path for that join rather than querying AP_SUPPLIER_CONTACTS in isolation, since the relationship to the supplier party is resolved through HZ_RELATIONSHIPS and is not directly present on the contacts table.