Search Results related_party_id

Overview

AMS_PERSON_RELATIONSHIPS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, catalogued under the AMS (Marketing) product family. Its documented purpose is to expose relationships between entities — specifically, the associations that exist between person parties and the other parties (person or organization) they are related to. The view is defined as a single SELECT statement joining data from the Oracle Trading Community Architecture (TCA) registry tables, and it is marked VALID in both the 12.1.1 and 12.2.2 releases. The view text is upstream of the TCA party model rather than of AMS transactional tables, which means it functions as a convenient denormalized projection of relationship data that marketing, campaign, and customer-facing processes can query directly without reconstructing the underlying join logic.

A frequent search term against this object is related_party_id. Although the underlying column physically exposed by the view is PR.PARTY_ID from HZ_RELATIONSHIPS (the related-party identifier), users and integrators commonly refer to it conceptually as the "related party id" when they are tracing how a subject party is associated with a related party.

Underlying Base Objects

The documented base objects referenced by the view are four TCA synonyms:

• HZ_PARTIES — appears three times in the FROM clause with the aliases PRSN (subject person), PARTY (the object/related party), and RELPARTY (the relationship party record carrying contact and address attributes).
• HZ_RELATIONSHIPS (alias PR) — supplies the relationship row itself, including RELATIONSHIP_ID, RELATIONSHIP_TYPE, STATUS, SUBJECT_ID, OBJECT_ID, and PARTY_ID.
• HZ_ORG_CONTACTS (alias C) — participates in the join, though the excerpted view text truncates before its predicate is shown.
• HZ_CONTACT_POINTS (alias CPPH) — supplies phone contact points and is outer-joined to HZ_RELATIONSHIPS via OWNER_TABLE_ID (+).

The join links the subject party (PRSN) to the relationship subject (PR.SUBJECT_ID), the relationship object to the related party (PR.OBJECT_ID = PARTY.PARTY_ID), the relationship party to the relationship-party record (PR.PARTY_ID = RELPARTY.PARTY_ID), and the relationship party to contact points. Filters restrict results to active rows only: PR.STATUS='A', PRSN.STATUS='A', and PARTY.STATUS='A'.

Key Columns

• PRSN.PARTY_ID — the subject person's party identifier.
• PR.PARTY_ID — the related party identifier surfaced from HZ_RELATIONSHIPS; this is the column most often sought as "related_party_id."
• PR.OBJECT_ID — the object party identifier, also usable to derive the related party.
• PR.RELATIONSHIP_ID, PR.RELATIONSHIP_TYPE, PR.STATUS — the relationship identifier, classification, and active status.
• PRSN.PARTY_NAME, PERSON_LAST_NAME, PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, KNOWN_AS, LAST_ORDERED_DATE — subject person descriptors.
• PARTY.PARTY_TYPE, PARTY.PARTY_NAME — the related party's type and name.
• Phone columns (PHONE_COUNTRY_CODE, PHONE_AREA_CODE, PHONE_NUMBER, PHONE_EXTENSION, PHONE_LINE_TYPE and a concatenated display form).
• Address columns (EMAIL_ADDRESS, ADDRESS1–ADDRESS4, STATE, CITY, PROVINCE, COUNTY, POSTAL_CODE, COUNTRY, plus concatenated address lines).
• Audit columns — CREATION_DATE, LAST_UPDATE_DATE, CREATED_BY, LAST_UPDATED_BY.

Common Use Cases and Queries

Typical uses include 360-degree customer analytics, relationship-based segmentation for marketing campaigns, and integration extracts that need a flattened relationship record. Because relationships are directional, queries usually filter on a specific subject party or relationship type.

Sample query retrieving all active relationships for a given subject person:

SELECT relationship_id, party_id AS related_party_id,
       relationship_type, party_name, phone_number
FROM   apps.ams_person_relationships_v
WHERE  party_id = :p_subject_party_id
ORDER BY party_name;

Sample query resolving the related party for a known relationship:

SELECT relationship_id, relationship_type, party_type,
       party_name, object_id
FROM   apps.ams_person_relationships_v
WHERE  relationship_id = :p_relationship_id;

Because the view restricts output to active records and person subjects, it should not be used to retrieve inactive or historical relationships; HZ_RELATIONSHIPS must be queried directly for those cases.