Results for “hz_party_preferences_pk”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

HZ_PARTY_PREFERENCES is a Receivables (AR) transaction table that stores configuration and behavioral preferences associated with parties (customers, prospects, organizations, and persons) in Oracle E-Business Suite. It is owned by the AR schema and carries a status of VALID in both 12.1.1 and 12.2.2. Following the TCA (Trading Community Architecture) naming convention, the table extends the HZ_PARTIES registry with flexible, code-driven preference records rather than fixed columns.

The ETRM metadata classifies this table heuristically as standalone under Data Vault modeling. In practice this is closer to a satellite or attribute-driven detail structure keyed by party, since a party may record multiple, distinct preference rows. The "standalone" label signals that the documented FK structure does not resolve to a strong parent-child link in the ETRM mining, so analysts should treat PARTY_ID as a logical (not enforced) association to HZ_PARTIES.

Key Information Stored

The table holds 20 documented columns. The most significant are:

• PARTY_PREFERENCE_ID — Surrogate primary key, defined by index HZ_PARTY_PREFERENCES_PK.
• PARTY_ID — The party to which the preference belongs; also a component of the U2 business key.
• MODULE — The functional area or product context in which the preference applies.
• CATEGORY — Grouping classifier for the preference type; part of U2.
• PREFERENCE_CODE — The specific preference identifier within its category; part of U2.
• VALUE_VARCHAR2, VALUE_NUMBER, VALUE_DATE — Typed value columns allowing the same structure to hold text, numeric, or date preferences; all three form part of U2.
• VALUE_NAME — A descriptive or display name for the preference value.
• ADDITIONAL_VALUE1 through ADDITIONAL_VALUE5 — Five flexible overflow attributes for supplementary data.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the TCA API layer.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard WHO audit columns.

Business-key candidates are documented through unique indexes: HZ_PARTY_PREFERENCES_U1 on PARTY_PREFERENCE_ID (effectively an alternate for the PK) and HZ_PARTY_PREFERENCES_U2 on PARTY_ID, CATEGORY, PREFERENCE_CODE, VALUE_VARCHAR2, VALUE_NUMBER, and VALUE_DATE.

Common Use Cases and Queries

Typical reporting and integration scenarios include retrieving a party's communication or delivery preferences, auditing who changed a preference, and joining preferences back to the party registry for segmentation. A representative query:

• SELECT p.party_number, p.party_name, pr.category, pr.preference_code, pr.value_varchar2, pr.value_number, pr.value_date FROM hz_party_preferences pr JOIN hz_parties p ON p.party_id = pr.party_id WHERE pr.party_id = :party_id;
• Filter by MODULE and CATEGORY to isolate preferences for a specific functional area.
• Use LAST_UPDATE_DATE for incremental extraction into a data warehouse or reconciliation report.
• Check OBJECT_VERSION_NUMBER during concurrent updates via the TCA party APIs.

Related Objects

The principal related objects follow the PARTY_ID association, since ETRM documents no enforced foreign keys (standalone classification).

• HZ_PARTIES — Parent registry of the party; join on PARTY_ID = HZ_PARTIES.PARTY_ID.
• HZ_PARTY_SITES — Party location records frequently queried alongside preferences; join on PARTY_ID.
• HZ_CUST_ACCOUNTS — Receivables customer accounts linked through PARTY_ID.
• HZ_PERSON_PROFILES — Person-level attributes that complement party preferences.
• HZ_ORGANIZATION_PROFILES — Organization-level attributes for party preference context.
• HZ_CONTACT_POINTS — Communication endpoints often governed by stored preferences.
• HZ_PARTY_PREFERENCES public TCA APIs (e.g., HZ_PARTY_PREFERENCE_V2PUB) — the supported interface for insert, update, and delete operations.