Search Results pon_party_preferences




Overview
Explore in AI Chat

Overview

PON.PON_PARTY_PREFERENCES is a transactional configuration table within the Oracle E-Business Suite Sourcing (PON) module. It stores party-level preference records scoped to a specific application, allowing Oracle Sourcing to retain named preference values associated with individual trading partners or party records. The table resides in the PON schema and carries a VALID status in both Oracle EBS 12.1.1 and 12.2.2, with a documented physical schema of ten columns in the 12.2.2 ETRM registry.

Functionally, the table acts as a lightweight attribute store: it permits any application registered in the EBS application registry to persist a named preference against a party record, together with a stored value and a corresponding display meaning. This design supports extensibility without requiring schema changes to the Sourcing data model.

Under the heuristic Data Vault classification mined from its foreign key structure, PON_PARTY_PREFERENCES is best modeled as a link table. It connects two independent business entities — a party (HZ_PARTIES) and an application (FND_APPLICATION) — and qualifies that association with a named preference and its value. The classification is a modeling suggestion only; the underlying physical implementation is a conventional relational table.

Key Information Stored

The table is deliberately narrow, and the ten documented columns divide cleanly into key components and descriptive attributes:

  • PARTY_ID — Identifier of the party record to which the preference applies. This is a foreign key to HZ_PARTIES and forms the leading column of the composite primary key.
  • APP_SHORT_NAME — Short name of the owning application, foreign keyed to FND_APPLICATION. It scopes the preference to a specific EBS application context.
  • PREFERENCE_NAME — Name of the preference being stored. Together with the preceding two columns it constitutes the composite primary key.
  • PREFERENCE_VALUE — The stored value for the named preference.
  • PREFERENCE_MEANING — The human-readable meaning or description associated with the preference value, typically used for display and reporting.
  • ATTRIBUTE1 through ATTRIBUTE5 — Five generic descriptive flexfield-style columns reserved for extensible, implementation-specific data.

The primary key constraint is documented as POM_PARTY_PREFERENCES_PK, defined over the composite of PARTY_ID, APP_SHORT_NAME, and PREFERENCE_NAME. This composite is the business key: uniqueness is enforced at the level of a party/application/preference triple, meaning a given party may hold at most one value for any named preference within any single application. There is no documented single-column surrogate key; the composite itself serves as the primary identifier.

Common Use Cases and Queries

Because the table is indexed primarily by party, the dominant access pattern is a lookup of all preferences belonging to one party, optionally filtered by application. Typical SQL patterns include:

  • Retrieving every preference for a party: SELECT preference_name, preference_value, preference_meaning FROM pon.pon_party_preferences WHERE party_id = :party_id;
  • Narrowing to a single application: add AND app_short_name = 'PON' to the predicate above.
  • Resolving a specific preference: filter on all three key columns to guarantee at most one row.
  • Reporting joins to HZ_PARTIES on PARTY_ID and to FND_APPLICATION on APP_SHORT_NAME to produce readable party and application names alongside stored preference values.

Common reporting scenarios include auditing which sourcing preferences have been configured for a supplier or partner organization, comparing assigned preference values across parties, and validating that preference records reference applications that remain registered and active.

Related Objects

The documented relationship data identifies two direct foreign key dependencies:

  • HZ_PARTIES — joined via PON_PARTY_PREFERENCES.PARTY_ID = HZ_PARTIES.PARTY_ID. This is the primary parent entity and anchors the preference to a specific trading partner or party record.
  • FND_APPLICATION — joined via PON_PARTY_PREFERENCES.APP_SHORT_NAME = FND_APPLICATION.APP_SHORT_NAME. This constrains preferences to applications registered in the EBS application registry.

Because the table references HZ_PARTIES, related objects in the party model — HZ_ORGANIZATION_PROFILES, HZ_PARTY_SITES, and HZ_CUST_ACCOUNTS — are commonly used in downstream joins to enrich preference reporting with party classification and site information. Similarly, FND_APPLICATION is frequently joined to FND_APPLICATION_TL for translated application names. No PL/SQL API or view is documented as directly dependent on this table in the supplied metadata, so access is generally performed through direct SQL or through the enclosing Sourcing application logic.