Search Results dqorg_contact_id




Overview
Explore in AI Chat

Overview

The APPS.HZ_DQM_ORG_CONTACT_INFO_V view is a denormalized reporting and integration object within Oracle E-Business Suite, owned by the APPS schema and validated in releases 12.1.1 and 12.2.2. Despite the HZ_ registry namespace, the view is documented under the AR (Receivables) product module and is used primarily by Oracle's Data Quality Management (DQM) and customer data cleansing workflows. It presents a consolidated, readable picture of organization contacts, their relationship to parties, their assigned roles, and their contact point information (phone, email, telex, or web).

The view deliberately prefixes its projected columns with the "DQ" convention (for example, DQORG_CONTACT_ID and DQCONTACT_POINT_ID), signaling that its results feed DQM merge, deduplication, and cleansing logic. Practically, it serves as a single query surface that flattens the many-to-many relationship between an organization contact record (HZ_ORG_CONTACTS), the underlying party relationship (HZ_RELATIONSHIPS/HZ_PARTIES), the customer account role (HZ_CUST_ACCOUNT_ROLES), and one or more contact points (HZ_CONTACT_POINTS), which would otherwise require a multi-table join against the TCA registry.

Because it is a view rather than a table, it stores no data and incurs no maintenance overhead. Its behavior is entirely dependent on the underlying TCA and Receivables base objects, and it is read-only in practice.

Underlying Base Objects

The documented base objects referenced by the view are:

  • HZ_ORG_CONTACTS (synonym) — source of ORG_CONTACT_ID, TITLE, and JOB_TITLE.
  • HZ_CONTACT_POINTS (synonym) — supplies contact point type, status, primary flags, and the raw address/phone/email/URL values.
  • HZ_PARTIES (synonym, accessed twice as D and F) — provides party identification and party name.
  • HZ_RELATIONSHIPS (synonym) — defines the directional party relationship linking the contact to the party.
  • HZ_CUST_ACCOUNT_ROLES (synonym) — supplies the ROLE_TYPE associated with the contact's party.
  • AR_LOOKUPS (view, joined twice as H and H1) — resolves lookup meanings for COMMUNICATION_TYPE and PHONE_LINE_TYPE.
  • ARPT_SQL_FUNC_UTIL (package) — called via GET_LOOKUP_MEANING to translate REGISTRY_STATUS lookup codes for the contact point status.

The view joins these through the party relationship ID, enforcing DIRECTIONAL_FLAG = 'F' and SUBJECT_TABLE_NAME = 'HZ_PARTIES'. Contact points are attached with an outer join on OWNER_TABLE_ID and OWNER_TABLE_NAME, and lookup joins are likewise outer joins. Contact points whose status is 'M' are excluded, preserving all other records.

Key Columns

  • DQORG_CONTACT_ID — the organization contact identifier, projected from HZ_ORG_CONTACTS.ORG_CONTACT_ID; the key value that users locate when searching for "dqorg_contact_id".
  • DQPTY_ID and DQPARTY_ID — the relationship object identifier and the party identifier, respectively.
  • DQTITLE_NAME — the party name associated with the contact.
  • DQROLE_TYPE — the customer account role type from HZ_CUST_ACCOUNT_ROLES.
  • DQMEANING and DQCONTACT_POINT_PURPOSE — decoded lookup meanings describing the communication type (with phone line type taking precedence for PHONE entries).
  • DQSTATUS and DQSTATUSM — the raw contact point status and its decoded REGISTRY_STATUS meaning.
  • DQPRIMARY_FLAG and DQPRIMARY_BY_PURPOSE — indicators of the primary contact point.
  • DQCONTACT_POINT_ID and DQCONTACT_INFO — the contact point identifier and the formatted contact value (concatenated area code and phone number, email address, telex number, or URL).

Common Use Cases and Queries

Typical uses include DQM data cleansing extracts, contact validation reports, and integration feeds requiring a flattened contact record. A basic lookup by contact identifier:

  • SELECT dqorg_contact_id, dqtitle_name, dqcontact_point_type, dqcontact_info FROM apps.hz_dqm_org_contact_info_v WHERE dqorg_contact_id = :org_contact_id;
  • SELECT dqparty_id, dqrole_type, dqstatusm FROM apps.hz_dqm_org_contact_info_v WHERE dqprimary_flag = 'Y';

Because results are DISTINCT and contact points are outer-joined, callers should expect one row per contact-point combination and filter on DQSTATUS when only active contact points are required.