Search Results hz_parties_n17

Overview

The AR.HZ_PARTIES table is the foundational registry of parties within the Oracle E-Business Suite Trading Community Architecture (TCA). A party is any entity that can establish a relationship with another party, and the table stores the basic, shareable information about each such entity. Records correspond to unique parties, though multiple parties may share the same name. Four party types are supported: Organization (for example, Oracle Corporation), Person (for example, Jane Doe), Group (for example, the World Wide Web Consortium), and Relationship (for example, Jane Doe at Oracle Corporation).

The table holds denormalized information drawn from HZ_LOCATIONS, HZ_PERSON_PROFILES, HZ_CONTACT_POINTS, HZ_ORGANIZATION_PROFILES, and HZ_PERSON_LANGUAGE, including the identifying address denormalized from HZ_LOCATIONS. Party records may be created and updated from third-party data sources such as Dun & Bradstreet Global Data Products. In Oracle EBS 12.1.1 and 12.2.2, HZ_PARTIES is owned by the AR schema and stored in the APPS_TS_TX_DATA tablespace with PCT Free 10. Because nearly every TCA-dependent module references it, its heuristic Data Vault classification is a hub: the central, business-keyed entity around which satellite attributes and many links to other hubs (accounts, sites, contacts) are organized.

Key Information Stored

The table contains 139 documented columns. The most significant include:

• PARTY_ID — Surrogate primary key, enforced by HZ_PARTIES_PK and the unique index HZ_PARTIES_U1.
• PARTY_NUMBER — Business-key candidate; enforced by the unique index HZ_PARTIES_U2, and the object most directly associated with the user search term hz_parties_u2.
• PARTY_NAME — Primary display name; indexed non-uniquely by HZ_PARTIES_N1.
• PARTY_TYPE — One of Organization, Person, Group, or Relationship.
• ORIG_SYSTEM_REFERENCE — Identifier of the source system that created the party; indexed by HZ_PARTIES_N12 and used for cross-system reconciliation.
• CUSTOMER_KEY — Alternate customer-facing identifier.
• PERSON_LAST_NAME, PERSON_FIRST_NAME, PERSON_MIDDLE_NAME — Person name components; PERSON_LAST_NAME is indexed by HZ_PARTIES_N2 and by the function-based index HZ_PARTIES_N14, UPPER("PERSON_LAST_NAME").
• EMAIL_ADDRESS — Contact e-mail; supported by the function-based index HZ_PARTIES_N16, UPPER("EMAIL_ADDRESS").
• TAX_REFERENCE and JGZZ_FISCAL_CODE — Tax identifiers, indexed by HZ_PARTIES_N11 and HZ_PARTIES_N10 respectively.
• DUNS_NUMBER_C — Dun & Bradstreet number, indexed by HZ_PARTIES_N17.
• STATUS, VALIDATED_FLAG — Party lifecycle state and validation indicator.
• LANGUAGE_NAME and HOME_COUNTRY — Foreign keys to FND_LANGUAGES and FND_TERRITORIES respectively.
• ADDRESS1–ADDRESS4, CITY, STATE, POSTAL_CODE, COUNTRY — Denormalized identifying address.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the TCA APIs.

Common Use Cases and Queries

Typical scenarios include resolving a customer or supplier name to a party identifier, deduplicating party records, and reporting on customers, prospects, and vendors.

Lookup by business key:

• SELECT party_id, party_name, party_type FROM hz_parties WHERE party_number = :p_number;

Name search leveraging the function-based index:

• SELECT party_id, party_name FROM hz_parties WHERE UPPER(person_last_name) = UPPER(:last_name);

Organization listing by DUNS number:

• SELECT party_id, party_name FROM hz_parties WHERE duns_number_c = :duns;

Reports frequently join HZ_PARTIES to HZ_CUST_ACCOUNTS via PARTY_ID to obtain accounts, to HZ_PARTY_SITES for addresses, and to FND_USER (CUSTOMER_ID, PERSON_PARTY_ID) for user-to-party mappings. Data-quality queries using ORIG_SYSTEM_REFERENCE expose duplicate parties created across integrated source systems, and the TCA party APIs (HZ_PARTY_V2PUB) operate on this table for programmatic creation and update.

Related Objects

HZ_PARTIES is referenced by a very large number of dependent tables. The most significant include:

• HZ_CUST_ACCOUNTS — Joins on PARTY_ID (and SELLING_PARTY_ID); the primary customer-account linkage.
• HZ_PARTY_SITES — Joins on PARTY_ID; stores physical party locations.
• HZ_PARTY_RELATIONSHIPS — Joins on PARTY_ID, SUBJECT_ID and OBJECT_ID; models relationships between parties.
• HZ_PERSON_PROFILES and HZ_ORGANIZATION_PROFILES — Join on PARTY_ID; hold detailed person and organization attributes.
• HZ_CONTACT_POINTS — Joins on OWNER_TABLE_ID; stores phone, e-mail and other contact points.
• HZ_CUST_ACCOUNT_ROLES — Joins on PARTY_ID; assigns party roles to accounts.
• FND_USER — Joins on CUSTOMER_ID and PERSON_PARTY_ID; maps application users to parties.
• CE_BANK_ACCOUNTS — Joins on BANK_ID, BANK_BRANCH_ID, ACCOUNT_HOLDER_ID and ACCOUNT_OWNER_PARTY_ID.
• ZX_PARTY_TAX_PROFILE — Joins on PARTY_ID; holds party-level tax configuration.
• AP_INVOICE_PAYMENTS_ALL — Joins on INVOICING_PARTY_ID for payment reporting.

Outbound foreign keys from HZ_PARTIES itself are limited to LANGUAGE_NAME referencing FND_LANGUAGES and HOME_COUNTRY referencing FND_TERRITORIES, confirming its role as a reference hub rather than a dependent child table.