Search Results hz_parties




Overview
Explore in AI Chat

Overview

HZ_PARTIES is the central registry of party records in Oracle E-Business Suite, owned by the AR (Receivables) schema and classified under the Trading Community Architecture (TCA) model. A "party" is any entity that can transact business with the enterprise — organizations, people, and groups. Because nearly every Oracle module that touches customers, suppliers, students, employees, banks, or trading partners must ultimately resolve those entities to a single TCA identity, HZ_PARTIES functions as the foundational master record upon which site, account, contact-point, and relationship data are built. The table is documented as VALID in the AR schema and is available in both Oracle EBS 12.1.1 and 12.2.2.

From a data modeling perspective, the mined foreign-key structure suggests that HZ_PARTIES is best understood as a Data Vault hub. Its primary key, PARTY_ID, is a business-independent surrogate key that serves as the stable join anchor for hundreds of dependent satellites, links, and transactional references across the E-Business Suite. The heuristic classification reflects the table's role as a durable identity registry rather than a link table (which connects hubs) or a satellite (which stores descriptive, time-variant attributes).

Key Information Stored

The table is documented with 139 columns. The most operationally significant attributes are:

Common Use Cases and Queries

Because PARTY_ID is the universal TCA identity, HZ_PARTIES is the natural first join in any query that must resolve a customer, supplier, contact, or student to a name. Typical reporting patterns include:

  • Resolving a customer name: joining HZ_CUST_ACCOUNTS.PARTY_ID to HZ_PARTIES.PARTY_ID to obtain PARTY_NAME and PARTY_NUMBER.
  • Supplier/vendor lookup: joining PO_VENDORS or AP supplier records through the party FK to obtain legal name and tax identifiers.
  • Contact-point reporting: joining HZ_CONTACT_POINTS.OWNER_TABLE_ID to HZ_PARTIES.PARTY_ID to list emails, phones, and URLs.
  • Deduplication and data quality: querying on DUNS_NUMBER, ORIG_SYSTEM_REFERENCE, or PARTY_NAME_PHONETIC variants to detect duplicate parties before assuming a unified customer view.
  • Role-based analysis: using PARTY_TYPE, CATEGORY_CODE, and the flag columns to segment persons versus organizations and to isolate competitors, third parties, or reference-eligible parties.

A representative query joining party identity to customer account:

SELECT p.party_number, p.party_name, p.party_type, a.account_number
FROM   hz_parties      p,
       hz_cust_accounts a
WHERE  p.party_id = a.party_id
AND    p.status   = 'A';

Related Objects

HZ_PARTIES anchors an exceptionally large FK footprint. The most significant related objects, drawn from the documented relationship metadata, include:

Querying HZ_PARTIES directly is safe for read-only reporting; all maintenance should flow through the Public TCA APIs (for example, the Party, Party Site, and Contact Point APIs) to preserve referential and validation integrity.