Search Results known_as2

Overview

AST_PER_V is an APPS-owned database view in Oracle E-Business Suite, delivered as part of the AST — TeleSales product module. The object resides in the APPS schema and carries a status of VALID in both 12.1.1 and 12.2.2 releases. The view presents a denormalized, person-centric party record that joins core Oracle Trading Community Architecture (TCA) data with contact point and lookup information. Its design intent is to supply TeleSales and adjacent modules with a ready-to-consume projection of individual (person-type) parties, including their names, addresses, phone numbers, status, and descriptive attributes. Because it flattens several base tables into a single relational source, AST_PER_V simplifies reporting and integration logic that would otherwise require multiple joins. The presence of the KNOWN_AS, KNOWN_AS2 through KNOWN_AS5 columns reflects the TCA person party model, which supports multiple alternate or preferred names for an individual — a feature commonly surfaced in TeleSales agent screens and correspondence.

Underlying Base Objects

The ETRM 12.2.2 metadata documents three referenced base objects: AR_LOOKUPS (documented as a VIEW), HZ_CONTACT_POINTS (SYNONYM), and HZ_PARTIES (SYNONYM). The view text confirms these sources, alias-named PARTY, PHONE, and LKUP1/LKUP2/LKUP3. HZ_PARTIES and HZ_CONTACT_POINTS are TCA registry entities: the former stores party records for persons, organizations, and groups, and the latter stores contact points such as phone numbers. AR_LOOKUPS is the Oracle Receivables lookup view used to resolve coded values into their meanings. The join between PARTY and PHONE is an outer join on PARTY_ID = OWNER_TABLE_ID, allowing parties with no recorded contact point to remain visible. Additional lookup joins resolve PERSON_PRE_NAME_ADJUNCT to CONTACT_TITLE meanings and PARTY.STATUS to REGISTRY_STATUS meanings. The view restricts output to party type 'PERSON' and to status values 'A' (active) or 'I' (inactive).

Key Columns

• PARTY_ID, PARTY_TYPE, ROWID — primary identity and the Oracle row identifier for the source party.
• PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, PERSON_LAST_NAME — structured personal name components.
• KNOWN_AS, KNOWN_AS2, KNOWN_AS3, KNOWN_AS4, KNOWN_AS5 — alternate names or nicknames recorded for the person; queries searching for "known_as3" specifically target this third alternate-name column.
• PHONE_NUMBER, PHONE_COUNTRY_CODE, PHONE_AREA_CODE, PHONE_EXTENSION — telephony contact details sourced from HZ_CONTACT_POINTS.
• SALUTATION, PERSON_TITLE, PERSON_ACADEMIC_TITLE, PERSON_NAME_SUFFIX — honorific and title attributes.
• ADDRESS1–ADDRESS4, CITY, STATE, PROVINCE, COUNTY, POSTAL_CODE, COUNTRY — postal address elements.
• STATUS — party registry status restricted to active or inactive.
• ATTRIBUTE_CATEGORY, ATTRIBUTE1–ATTRIBUTE24 — the DESCRIPTIVE flexfield context and segments.
• LOOKUP_CODE, MEANING — resolved lookup values from AR_LOOKUPS.

Common Use Cases and Queries

AST_PER_V is typically used for TeleSales agent lookups, person party listings, and integration feeds requiring consolidated person data. A representative query follows, filtering specifically on the KNOWN_AS3 alternate-name column that prompted the original search:

SELECT party_id, party_name, known_as3, phone_number, city, status FROM apps.ast_per_v WHERE UPPER(known_as3) = 'SMITH';

Bulk extraction for interfaces may use:

SELECT party_id, person_first_name, person_last_name, email_address, attribute1 FROM apps.ast_per_v WHERE status = 'A';

Because the view already enforces PARTY_TYPE = 'PERSON' and the active/inactive status filter, callers need not restate those predicates. Note that the phone join is an outer join, so phone columns may be NULL; report logic should account for this. For performance, queries should filter on indexed TCA identifiers where possible, as the underlying joins against HZ_CONTACT_POINTS and the three AR_LOOKUPS alias instances add overhead.