Search Results hz_parties_pk

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:

• PARTY_ID — the surrogate primary key (HZ_PARTIES_PK / HZ_PARTIES_U1). This is the value propagated into virtually every downstream FK.
• PARTY_NUMBER — the human-readable business key, protected by unique index HZ_PARTIES_U2. Often the value users quote when identifying a customer or supplier.
• PARTY_NAME — the display name for the party (person or organization).
• PARTY_TYPE — discriminates between PERSON, ORGANIZATION, and GROUP records, driving which optional columns apply.
• KNOWN_AS, KNOWN_AS2, KNOWN_AS3, KNOWN_AS4, KNOWN_AS5 — alternate names and aliases.
• PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, PERSON_LAST_NAME, PERSON_NAME_SUFFIX, PERSON_PRE_NAME_ADJUNCT, PERSON_TITLE — structured person-name components.
• ORIG_SYSTEM_REFERENCE — the source-system key used for inbound integration and de-duplication.
• DUNS_NUMBER and TAX_REFERENCE / JGZZ_FISCAL_CODE — external identifiers used in matching and tax reporting.
• STATUS and VALIDATED_FLAG — lifecycle and verification indicators.
• EMAIL_ADDRESS, URL, PRIMARY_PHONE_NUMBER — denormalized contact attributes for the party's primary contact point.
• LANGUAGE_NAME and HOME_COUNTRY — the only documented FKs out of the table, pointing to FND_LANGUAGES and FND_TERRITORIES respectively.
• CATEGORY_CODE, THIRD_PARTY_FLAG, COMPETITOR_FLAG, REFERENCE_USE_FLAG — classification flags used across CRM and marketing modules.
• Standard WHO/audit columns plus ATTRIBUTE1–24 and GLOBAL_ATTRIBUTE1–20 for extensibility.

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:

• HZ_CUST_ACCOUNTS — references HZ_PARTIES.PARTY_ID (and SELLING_PARTY_ID). The primary bridge from TCA party identity to Receivables customer accounts.
• HZ_PARTY_SITES — references PARTY_ID and stores the party's addresses and site usages.
• HZ_CONTACT_POINTS — references OWNER_TABLE_ID to PARTY_ID, holding email, phone, and web contact points.
• HZ_PARTY_RELATIONSHIPS — references PARTY_ID, SUBJECT_ID, and OBJECT_ID, defining relationships between parties.
• HZ_ORGANIZATION_PROFILES / HZ_PERSON_PROFILES — party-type-specific descriptive extensions keyed by PARTY_ID.
• HZ_CUST_ACCOUNT_ROLES — links parties to accounts in specific roles such as bill-to or ship-to contact.
• FND_USER — references CUSTOMER_ID and PERSON_PARTY_ID, binding application users to party identities.
• AP_INVOICE_PAYMENTS_ALL / IBY_EXTERNAL_PAYERS_ALL — reference the party as the invoicing or payer entity in payables and payments flows.
• IGS_AD_DFLT_OUDTLS — references HZ_PARTIES through DECISION_MAKER_ID and ADM_OTCM_STATUS_AUTH_PERSON_ID. This is the object associated with your search term and illustrates how Student Systems (IGS) tables depend on the TCA party hub for admissions decision-makers and authorizing persons.
• AMS_* and AS_* tables — the marketing (AMS) and sales/CRM (AS) schemas reference party IDs extensively for leads, opportunities, partners, and event registrations.

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.