Search Results person_academic_title
Overview
AS_PARTY_CONTACTS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the AS – Sales Foundation product. It exposes party contact information and is explicitly restricted to records where the party type is "PERSON." The view is compiled as VALID in both Oracle EBS 12.1.1 and 12.2.2, and it is registered in the ETRM (E-Business Suite Technical Reference Manual) object inventory for those releases.
The view functions as a denormalized, read-only projection over the Trading Community Architecture (TCA) party model. Rather than requiring report authors or integration developers to join HZ_PARTIES to contact, address, and person-profile tables directly, AS_PARTY_CONTACTS_V flattens the most frequently referenced attributes of a person party into a single queryable object. Its intended consumers are Oracle Reports, BI Publisher data templates, custom concurrent programs, SQL*Plus extracts, and inbound/outbound integration interfaces that require person-level contact detail without navigating the full TCA table hierarchy.
Because the view is defined with a fixed PARTY_TYPE = 'PERSON' predicate, it is a subset view rather than a complete projection of the underlying entity.
Underlying Base Objects
The documented base object for this view is HZ_PARTIES, accessed through a synonym in the APPS schema. HZ_PARTIES is the TCA registry of record for parties, storing identity attributes (party number, party name, party type, validated flag) together with the standard EBS who-columns and the DFF/global DFF attribute segments. The view's WHERE clause applies two filters: PARTY_TYPE = 'PERSON' and STATUS IN ('A','I'), meaning only active and inactive person parties are exposed. Location and organization parties are excluded by definition.
Although ETRM 12.2.2 documents HZ_PARTIES as the referenced base object, the view's column list reflects the conventional person-contact denormalization pattern in Sales Foundation, in which person name components, address lines, email, URL, and salutation are surfaced alongside the party header. Materialized query plans in 12.1.1 versus 12.2.2 may differ, but the view definition and exposed column set remain stable across both releases.
Key Columns
- PARTY_ID / PARTY_NUMBER / PARTY_NAME — Primary surrogate key, the user-visible unique party number, and the formatted party name.
- PARTY_TYPE — Always 'PERSON' for rows returned by this view.
- VALIDATED_FLAG — Indicates whether the party record has passed TCA validation.
- PERSON_PRE_NAME_ADJUNCT, PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, PERSON_LAST_NAME, PERSON_NAME_SUFFIX — Component parts of the person's name.
- PERSON_TITLE, PERSON_ACADEMIC_TITLE — Professional title and academic title (for example, Dr., Prof.) associated with the person. PERSON_ACADEMIC_TITLE is the column most frequently targeted by searches for "person_academic_title," and it is exposed here directly from the person profile.
- PERSON_PREVIOUS_LAST_NAME, KNOWN_AS, SALUTATION — Alternate and courtesy name forms used in correspondence.
- ADDRESS1–ADDRESS4, CITY, STATE, PROVINCE, POSTAL_CODE, COUNTY, COUNTRY — Flattened address attributes.
- EMAIL_ADDRESS, URL, DO_NOT_MAIL_FLAG — Electronic contact attributes and contact-preference indicator.
- STATUS — Party status; only 'A' and 'I' values appear.
- ATTRIBUTE1–24 and GLOBAL_ATTRIBUTE1–20 — Descriptive flexfield and global descriptive flexfield segments.
- CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE, WH_UPDATE_DATE — Standard EBS audit and concurrent-program columns.
Common Use Cases and Queries
Typical scenarios include person contact listings for Sales Foundation reports, name-and-address extracts for correspondence, and lookups of academic or professional titles for marketing and communications data feeds.
- Retrieve contact detail for a specific party.
- Identify persons holding an academic title.
- Extract active person contacts for a mailing or integration feed.
Sample queries:
SELECT party_id, party_number, party_name, person_first_name, person_last_name, person_academic_title, email_address FROM apps.as_party_contacts_v WHERE party_id = :p_party_id;
SELECT party_number, party_name, person_academic_title FROM apps.as_party_contacts_v WHERE person_academic_title IS NOT NULL ORDER BY person_last_name;
SELECT party_id, party_name, address1, city, state, postal_code, email_address FROM apps.as_party_contacts_v WHERE status = 'A' AND NVL(do_not_mail_flag,'N') = 'N';
Because the object is a view over HZ_PARTIES, it should not be used for DML; maintenance of person contact data must be performed through the TCA APIs and the standard Oracle EBS forms.
-
View: AS_PARTY_CONTACTS_V
12.1.1
owner:APPS, object_type:VIEW, fnd_design_data:AS.AS_PARTY_CONTACTS_V, object_name:AS_PARTY_CONTACTS_V, status:VALID, product: AS - Sales Foundation , description: It stores party contacts information. Party type = ?PERSON? , implementation_dba_data: APPS.AS_PARTY_CONTACTS_V ,
-
View: AS_PARTY_CONTACTS_V
12.2.2
owner:APPS, object_type:VIEW, fnd_design_data:AS.AS_PARTY_CONTACTS_V, object_name:AS_PARTY_CONTACTS_V, status:VALID, product: AS - Sales Foundation , description: It stores party contacts information. Party type = ?PERSON? , implementation_dba_data: APPS.AS_PARTY_CONTACTS_V ,