Results for “per_contact_relationships_v2”

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

Overview

PER_CONTACT_RELATIONSHIPS_V2 is a VALID APPS-schema view owned by the Oracle Human Resources (PER) product, defined in Oracle E-Business Suite 12.1.1 and 12.2.2. Per the ETRM metadata, its documented purpose is to support the user interface, meaning it is an internal, presentation-oriented construct rather than a pure reporting interface. The view denormalizes the transactional contact-relationship records held in PER_CONTACT_RELATIONSHIPS and enriches them with decoded lookup meanings and life-event reason names so that the Contact Relationships UI can render descriptive text instead of raw codes. Although the ETRM description is deliberately terse, the view text confirms that it exposes the complete set of descriptive flexfield attribute columns (CONT_ATTRIBUTE1–20, CONT_INFORMATION1–20) together with the financial aid / beneficiary flags and WHO-style audit columns.

Because the view is flagged as user-interface support, it is technically not part of the supported public API surface. Developers and report authors who reference it do so at their own risk; nevertheless, it is frequently encountered in custom reports and extracts because it is one of the few ready-made objects that resolves the contact type meaning and life-event reason names in a single query.

Underlying Base Objects

The ETRM 12.2.2 metadata lists the following referenced base objects: BEN_LER_F_VL (VIEW), FND_SESSIONS (SYNONYM), HR_API (PACKAGE), HR_LOOKUPS (VIEW), and PER_CONTACT_RELATIONSHIPS (SYNONYM). The view text joins:

• PER_CONTACT_RELATIONSHIPS — the core transactional table of contact relationships; every exposed column is prefixed with the CON alias.
• HR_LOOKUPS — aliased C, supplying the MEANING for CONTACT_TYPE.
• BEN_LER_F_VL — used twice (BEN1 and BEN2) to resolve START_LIFE_REASON_ID and END_LIFE_REASON_ID to a life-event reason name. This is the object the user searched for under the term "ben_ler_f_vl".
• FND_SESSIONS — aliased FND, joined to enforce the current session context.
• HR_API — referenced by the view definition as the supplying package for the view's underlying logic.

Key Columns

• CONTACT_RELATIONSHIP_ID — primary identifier of the relationship record; joined to ROWID for row-level DML.
• PERSON_ID / CONTACT_PERSON_ID — the person and the related contact person; the order is reversed in the select list to support both navigation directions in the UI.
• CONTACT_TYPE / MEANING — the lookup code and its decoded meaning from HR_LOOKUPS.
• DEPENDENT_FLAG, BENEFICIARY_FLAG, THIRD_PARTY_PAY_FLAG, BONDHOLDER_FLAG, PRIMARY_CONTACT_FLAG, PERSONAL_FLAG, RLTD_PER_RSDS_W_DSGNTR_FLAG — the functional classification flags that drive benefits eligibility.
• DATE_START / DATE_END — effective dates of the relationship, with the corresponding START_LIFE_REASON_ID and END_LIFE_REASON_ID plus BEN1.NAME and BEN2.NAME from BEN_LER_F_VL.
• CONT_ATTRIBUTE1–20 / CONT_INFORMATION1–20 — the descriptive flexfield context and segment values.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE, REQUEST_ID, PROGRAM_ID — standard WHO and concurrent-manager audit columns.

Common Use Cases and Queries

Typical usage is a benefits or HR extract that needs decoded contact type and life-event reason information. A representative query filtering the session context is:

SELECT contact_relationship_id, person_id, contact_person_id,
       contact_type, meaning, date_start, date_end,
       dependent_flag, beneficiary_flag
FROM   apps.per_contact_relationships_v2
WHERE  person_id = :p_person_id;

Report authors often join this view back to PER_ALL_PEOPLE_F on CONTACT_PERSON_ID to obtain the contact's name, and to BEN_LER_F_VL for life-event reason descriptions. Because the view relies on FND_SESSIONS, direct SQL outside a valid EBS session may return no rows or raise errors; queries should therefore be executed from the Applications context or with APPS initialized. Given its UI-support status, Oracle does not guarantee column stability across patches, so any custom dependency on PER_CONTACT_RELATIONSHIPS_V2 should be documented and re-validated after upgrade from 12.1.1 to 12.2.2.