Search Results jtf_party_contacts_v




Overview
Explore in AI Chat

Overview

JTF_PARTY_CONTACTS_V is an APPS-owned database view in the JTF – CRM Foundation product family, delivered as part of the Oracle E-Business Suite 12.1.1 and 12.2.2 technology stacks. Its stated purpose is to retrieve all contacts associated with a party. In practical terms, the view flattens the Oracle Trading Community Architecture (TCA) contact model into a single, denormalized result set that exposes organization contact records alongside person, profile, role, contact point, and relationship attributes. Because it consolidates data that would otherwise require multiple joins across the HZ schema, the view is widely used as a reporting and integration surface for contact-centric functionality such as CRM call center lookups, party contact listings, correspondence generation, and third-party system extracts. The view is documented with STATUS VALID and is referenced by ETRM as a stable, supported object for query purposes in both 12.1.1 and 12.2.2 environments.

Underlying Base Objects

The view is defined over the following documented base objects, all accessed through APPS synonyms:

  • HZ_ORG_CONTACTS — the primary driving table, aliased ORG_CONT, providing contact identifiers, job title, department, status, and descriptive flexfield attributes.
  • HZ_PARTIES — aliased PARTY, supplying party identifier, party number and type, person name components, and name suffix/prefix adjuncts.
  • HZ_PERSON_PROFILES — aliased PROFILE, contributing date of birth, marital status, gender, known-as name, and phonetic name fields.
  • HZ_ORG_CONTACT_ROLES — aliased CONT_ROLE, providing the ROLE_TYPE assignment for the contact.
  • HZ_CONTACT_POINTS — aliased CONT_POINT, supplying the email address.
  • HZ_RELATIONSHIPS — aliased REL, contributing the relationship STATUS value.

The view therefore sits directly on the TCA contact foundation, and any query against it inherits the referential semantics of the HZ schema rather than a JTF-specific staging structure.

Key Columns

The projection exposes identifiers, descriptive attributes, and audit columns. ORG_CONTACT_ID is the contact primary key, while PARTY_ID links to the associated party. CONTACT_NUMBER and PARTY_NUMBER provide user-facing reference identifiers. Name data is spread across PARTY_NAME, PERSON_FIRST_NAME, PERSON_LAST_NAME, and PERSON_NAME_SUFFIX. Contact detail columns include EMAIL_ADDRESS, TITLE, JOB_TITLE, JOB_TITLE_CODE, DEPARTMENT, DEPARTMENT_CODE, and MAIL_STOP. The MANAGED_BY column is of particular interest to users searching on that term: it originates from HZ_ORG_CONTACTS.MANAGED_BY and indicates the party or entity responsible for managing the contact. The DECISION_MAKER_FLAG, REFERENCE_USE_FLAG, RANK, and STATUS columns support qualification and prioritization logic. Twenty ATTRIBUTE1 through ATTRIBUTE20 columns carry the descriptive flexfield content. Standard audit columns include CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and the REQUEST_ID/PROGRAM_ID concurrency set. Note that several columns (PARTY_ID, ORG_CONTACT_ID, PARTY_SITE_ID) appear more than once in the view text, and ROWID is projected for the driving table.

Common Use Cases and Queries

A typical reporting requirement is to list all contacts for a given party together with role and email, for example:

  • SELECT party_id, org_contact_id, party_name, email_address, role_type, managed_by FROM jtf_party_contacts_v WHERE party_id = :p_party_id;
  • SELECT contact_number, party_name, job_title, department, status FROM jtf_party_contacts_v WHERE managed_by IS NOT NULL AND status = 'A';
  • SELECT p.party_number, p.party_name, p.email_address, p.role_type FROM jtf_party_contacts_v p WHERE p.decision_maker_flag = 'Y' AND p.reference_use_flag = 'Y';

These patterns are common in CRM contact directories, marketing qualification extracts, and integration interfaces that populate external contact masters. Because the view performs multi-table joins internally, filter predicates on PARTY_ID or ORG_CONTACT_ID are strongly recommended to avoid full scans in high-volume TCA implementations.