Results for “first_name_alt”

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

Overview

OTA_VENDOR_CONTACTS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OTA (Learning Management) product family. Its documented purpose is to list all contacts associated with a supplier, consolidating vendor header information, vendor site addresses, and vendor contact details into a single denormalized result set. The view is a lightweight reporting layer rather than a transactional object; it exposes no DML of its own and inherits all data from the underlying purchasing views. Within ETRM 12.1.1 and 12.2.2 the object carries VALID status, and it is referenced by Learning Management functionality that requires supplier contact data—for example, when an external training vendor, instructor, or partner must be identified by name and correspondence address. Because it joins directly to PO_VENDORS, PO_VENDOR_SITES_ALL, and PO_VENDOR_CONTACTS, it is equally useful to reporting and integration developers who need supplier contact information without navigating the purchasing data model themselves.

Underlying Base Objects

The view is defined over three purchasing views, joined on their natural keys:

• PO_VENDORS (VEN) — supplies VENDOR_ID, VENDOR_NAME, and the row identifier. Joined to the site by VENDOR_ID.
• PO_VENDOR_SITES_ALL (SIT) — supplies the address components used to build the concatenated ADDRESS column. Joined to the contact by VENDOR_SITE_ID.
• PO_VENDOR_CONTACTS (CON) — supplies contact identifiers, names, titles, and the alternate name columns. Joined to the site by VENDOR_SITE_ID.
• FND_GLOBAL (PACKAGE) — referenced for session/context resolution (for example, operating unit or user context) rather than as a data source.

The join condition is CON.VENDOR_SITE_ID = SIT.VENDOR_SITE_ID AND SIT.VENDOR_ID = VEN.VENDOR_ID, meaning every row represents one contact at one supplier site, with the parent supplier repeated. Suppliers with multiple sites or multiple contacts therefore return multiple rows.

Key Columns

• ROW_ID / VENDOR_ID / VENDOR_NAME — supplier identity, taken from PO_VENDORS.
• CONTACT_ID — the vendor contact identifier (VENDOR_CONTACT_ID) from PO_VENDOR_CONTACTS; the effective primary key of a returned row.
• FIRST_NAME / LAST_NAME — the contact's primary name and family name.
• FULL_NAME — a derived concatenation: LAST_NAME || ', ' || INITCAP(TITLE) || ' ' || FIRST_NAME, producing a formatted display name.
• VENDOR_SITE_ID — the supplier site at which the contact resides.
• ADDRESS — a derived, comma-delimited address assembled from ADDRESS_LINE1 through ADDRESS_LINE3, CITY, PROVINCE, ZIP, and AREA_CODE. Nested REPLACE and RTRIM calls collapse empty segments and strip trailing delimiters.
• TITLE — the contact's job title.
• LAST_NAME_ALT / FIRST_NAME_ALT — alternate-name columns from PO_VENDOR_CONTACTS, used where a contact is recorded under a secondary or native-script name.

Common Use Cases and Queries

Typical uses include listing contacts for a specific supplier or site, resolving a contact name for a training event or purchase document, and driving extracts that need a ready-formatted mailing address. Because FULL_NAME and ADDRESS are pre-computed, the view suits direct display in reports and concurrent extracts.

Selecting contacts for one supplier:

• SELECT vendor_name, contact_id, first_name, last_name, title FROM ota_vendor_contacts_v WHERE vendor_id = :p_vendor_id;

Retrieving the alternate name for a contact, matching the user's search term FIRST_NAME_ALT:

• SELECT vendor_name, full_name, first_name_alt, last_name_alt FROM ota_vendor_contacts_v WHERE first_name_alt IS NOT NULL AND UPPER(first_name_alt) LIKE UPPER(:search || '%');

Filtering by formatted address is unreliable because ADDRESS is derived, so predicates should be applied to the base columns via the vendor and site identifiers rather than to the concatenated string. Queries should also be scoped by VENDOR_ID or VENDOR_SITE_ID wherever possible, since the three-way join across supplier, site, and contact can return large result sets in environments with extensive supplier master data.