Results for “object_id_type”

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

Overview

IGS_PE_RELATIONSHIPS_V is a view owned by the APPS schema within the Oracle E-Business Suite Student System (IGS) product family. It presents the party-to-party relationships maintained against Oracle Trading Community Architecture (TCA) relationship data, exposing those relationships using a naming convention familiar to the Student System and its legacy relationship model. The view is defined over HZ_RELATIONSHIPS, HZ_PARTIES, and FND_LOOKUP_VALUES, and it joins these base entities to return a denormalized, ready-to-query rowset. Its principal value in reporting and integration is that it resolves the numeric foreign keys held in HZ_RELATIONSHIPS into party names, party numbers, and lookup meanings, so consumers do not have to reproduce that join logic themselves.

The view was created in response to the historical migration of party relationship data from the pre-TCA entity relationship model into TCA. It is a compatibility and reporting surface rather than a table that should be written to directly. In Oracle EBS 12.1.1 and 12.2.2 the view remains valid and continues to be used by Student System forms, concurrent programs, and custom reports that were originally written against the older relationship identifiers.

Underlying Base Objects

The ETRM metadata records no referenced base objects, but the documented view text identifies three sources explicitly:

• HZ_RELATIONSHIPS PR — the primary source of rows. Each record represents a directional relationship between a subject party and an object party.
• HZ_PARTIES P — joined on PR.OBJECT_ID = P.PARTY_ID, supplying the object party's number, type, and name.
• FND_LOOKUP_VALUES L1 — joined on PR.RELATIONSHIP_CODE = L1.LOOKUP_CODE where LOOKUP_TYPE = 'PARTY_RELATIONS_TYPE' and VIEW_APPLICATION_ID = 222, supplying the translated relationship code meaning.

The view filters on PR.STATUS = 'A', restricting output to active relationships, on L1.SECURITY_GROUP_ID = 0, and on L1.LANGUAGE = USERENV('LANG') so that lookup meanings are returned in the session language. Because it is a view, no storage is consumed and all access is resolved against the underlying TCA tables at execution time.

Key Columns

• PARTY_RELATIONSHIP_ID — aliased from PR.RELATIONSHIP_ID. This is the primary surrogate key users most often search for, and it uniquely identifies a single relationship row.
• ROW_ID — the ROWID of the underlying HZ_RELATIONSHIPS row.
• SUBJECT_ID and OBJECT_ID — the two parties participating in the relationship. OBJECT_ID_NUMBER, OBJECT_ID_TYPE, and NAME provide the object party's description.
• PARTY_RELATIONSHIP_TYPE and PARTY_RELATIONSHIP_TYP_MEANING — the relationship type code and its translated meaning.
• RECIPROCAL_FLAG — aliased from DIRECTIONAL_FLAG, indicating whether the relationship is reciprocal.
• START_DATE, END_DATE, STATUS, COMMENTS, CONTENT_SOURCE_TYPE — descriptive and lifecycle attributes.
• Standard WHO and DFF columns (CREATED_BY, CREATION_DATE, ATTRIBUTE1–20, GLOBAL_ATTRIBUTE1–20) are exposed for audit and descriptive flexibility.

Common Use Cases and Queries

A frequent scenario is resolving a relationship identifier to its participating parties and type, for example retrieving all relationships associated with a given party:

SELECT party_relationship_id,
       subject_id,
       object_id,
       name,
       party_relationship_typ_meaning
FROM   igs_pe_relationships_v
WHERE  object_id = :p_party_id
ORDER  BY start_date DESC;

The view is also used to enumerate all relationships of a particular type, or to locate a specific relationship by its internal identifier:

SELECT *
FROM   igs_pe_relationships_v
WHERE  party_relationship_id = :p_relationship_id;

Because the view already resolves the object party name and the relationship type meaning, it is well suited to operational lists, student-person relationship inquiries, and integration extracts that feed external systems. Queries should typically be filtered by STATUS and date ranges, since the view materializes all active relationships at execution time.