Search Results partner_party_id




Overview
Explore in AI Chat

Overview

PV_PARTNER_CONTACTS_V is a PL/SQL view owned by the APPS schema in Oracle E-Business Suite, classified under the Partner Management (PV) product family. It exposes the set of contacts associated with partner organizations, resolving the relationship between a partner profile and the individual contacts who serve as employees of that partner. The view is defined entirely over Oracle Trading Community Architecture (TCA) relationship data joined to partner profile records, so it serves as the canonical reporting surface for partner-contact associations within the PV module.

In EBS 12.1.1 and 12.2.2, the view is marked VALID and is widely referenced by Partner Management forms, concurrent programs, and third-party integrations that require a flattened, denormalized list of partner contacts. Because it abstracts the multi-table TCA relationship model into a single row set, it is a common target for custom reports, OAF-based extensions, and outbound interface extracts. The view is read-only and contains no DML handlers; consumers query it directly.

Underlying Base Objects

The documented base objects are HZ_ORG_CONTACTS, HZ_PARTIES, HZ_RELATIONSHIPS, and PV_PARTNER_PROFILES, all exposed to APPS as synonyms. The view joins HZ_RELATIONSHIPS to HZ_PARTIES on SUBJECT_ID = PARTY_ID, and filters relationships where RELATIONSHIP_CODE = 'EMPLOYEE_OF' and DIRECTIONAL_FLAG = 'F'. The OBJECT_ID of that relationship is matched against a distinct list of PARTNER_PARTY_ID values drawn from PV_PARTNER_PROFILES. An EXISTS clause against HZ_ORG_CONTACTS, keyed on PARTY_RELATIONSHIP_ID = RELATIONSHIP_ID, restricts output to contacts that are formally registered as organization contacts. The view also applies effective-date filtering: HZR.START_DATE must be less than or equal to SYSDATE, and NVL(HZR.END_DATE, SYSDATE) must be greater than or equal to SYSDATE, ensuring only currently active relationships appear.

Key Columns

  • PARTNER_PARTY_ID — The party identifier of the partner organization, sourced from PV_PARTNER_PROFILES. This is the column users most frequently search on and the primary join key back to partner records.
  • PARTY_ID / PARTY_ID2 — The party identifier of the contact, with PARTY_ID2 populated as a literal '#' placeholder.
  • PARTY_NUMBER — The TCA party number of the contact party.
  • NAME / DESCRIPTION — Both populated from HZ_PARTIES.PARTY_NAME, providing the contact display name.
  • PARTY_TYPE — The party type (for example PERSON or ORGANIZATION) of the contact record.
  • STATUS / B_STATUS — The HZ_PARTIES.STATUS value, duplicated for form-layer binding; 'I' and 'D' statuses trigger END_DATE_ACTIVE population.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — Effective-date indicators; START_DATE_ACTIVE is always SYSDATE and END_DATE_ACTIVE resolves to SYSDATE only for inactive or deleted parties.
  • ID1 / ID2 — Internal surrogate keys derived from HZ_RELATIONSHIPS.PARTY_ID and a literal '#', used by the form block.

Common Use Cases and Queries

Typical usage centers on retrieving all contacts for a given partner party, or listing partners that have at least one active contact. A simple lookup by the searched attribute follows:

SELECT partner_party_id, party_id, party_number, name, party_type, status
FROM apps.pv_partner_contacts_v
WHERE partner_party_id = :p_partner_party_id
ORDER BY name;

For partner-to-contact rosters across all partners, omit the predicate and join to PV_PARTNER_PROFILES or HZ_PARTIES for additional partner attributes. Because the view enforces current-date and employee-of filtering, it is also used as a validation source in integrations that must confirm a contact is presently affiliated with a partner before creating a deal registration or channel transaction. Reporting extracts commonly filter on STATUS = 'A' to exclude inactive parties.