Search Results rel_party_number




Overview
Explore in AI Chat

Overview

AST_LM_REL_SMARTSEARCH_V is an Oracle Applications (APPS) view owned by the APPS schema and registered under the FND Design Data identifier AST.AST_LM_REL_SMARTSEARCH_V. It is a standard, internal, valid view whose purpose is to support the "relationship smart search" capability within the Oracle E-Business Suite relational data model. The view presents a flattened, denormalized projection that combines party and person attributes with their associated relationship attributes, contact points, and address information, so that relationship searches can be driven against a single, convenient result set rather than joining the underlying TCA (Trading Community Architecture) tables directly.

Because the object is flagged "Oracle Internal Use Only," Oracle Corporation does not support access to its data except from standard Oracle Applications programs. The view is therefore not intended as a public integration interface, but it is frequently inspected by technical consultants and reporting developers who need to understand how relationship search results are assembled. It is available on both Oracle EBS 12.1.1 and 12.2.2, with the documented metadata corresponding to the 12.2.2 code line.

Underlying Base Objects

The view is defined over several TCA and foundation objects. The core party and relationship data is sourced from HZ_PARTIES, HZ_RELATIONSHIPS, HZ_RELATIONSHIP_TYPES, and HZ_ORG_CONTACTS. Contact point information, including email, phone, and URL data, is drawn from HZ_CONTACT_POINTS. Matching and scoring behavior, reflected in the SCORE column, is supported through HZ_MATCHED_CONTACTS_GT, a global temporary table used during search processing.

Supporting objects include FND_TERRITORIES_TL for country and territory descriptions, AR_LOOKUPS for lookup meanings, and the packages ARP_ADDR_LABEL_PKG, FND_PROFILE for address formatting and profile-driven defaults. In combination, these objects allow the view to resolve party names, relationship types, contact details, and formatted addresses into a single smart-search output.

Key Columns

The view exposes a broad set of columns. The primary party is identified by PARTY_ID, PARTY_NUMBER, and PARTY_TYPE, with PERSON_ID and the person name components (PERSON_NAME, PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, PERSON_LAST_NAME, PERSON_FULL_NAME). The related party, which is the object of the relationship search, is exposed through REL_PARTY_ID, REL_PARTY_NUMBER, and REL_PARTY_NAME; the user search term "rel_party_name" maps directly to the REL_PARTY_NAME column, which carries a length of 360 characters. RELATIONSHIP_TYPE, JOB_TITLE, and JOB_TITLE_CODE describe the nature of the association between the two parties. SCORE carries the numeric matching rank returned by the smart search.

Contact and location columns include EMAIL_ADDRESS, FULL_PHONE_NUMBER with its components (PHONE_AREA_NUMBER, PHONE_AREA_CODE, PHONE_COUNTRY_CODE, PHONE_NUMBER, PHONE_EXTENSION), URL, CONCAT_ADDRESS, ADDRESS, CITY, COUNTY, STATE, POSTAL_CODE, PROVINCE, COUNTRY_CODE, and COUNTRY. Additional attributes include ORGANIZATION_NAME, STATUS and STATUS_MEAN, CERTIFICATION_LEVEL and CERT_LEVEL_MEAN, ACCOUNT_NUMBER, and CUST_ACCOUNT_ID.

Common Use Cases and Queries

The most common scenario is filtering relationship search results by the related party name, which corresponds to the search term the user supplied. A representative query is:

  • SELECT party_name, rel_party_name, relationship_type, score from the view, filtering on rel_party_name LIKE :search_term.
  • Restricting by organization using organization_name or by party type using party_type.
  • Returning contact details such as email_address and full_phone_number alongside the related party name.
  • Ordering results by score descending to surface the closest relationship matches first.

Because the object is unsupported for direct external access, any query should be treated as diagnostic or informational, and production integrations should rely on supported Oracle APIs and public views rather than this internal view.