Search Results hr_contact_rel_api




Overview
Explore in AI Chat

Overview

APPS.HR_CONTACT_REL_API is a PL/SQL API package that provides a controlled, business-rule-validated interface for maintaining contact relationship records in Oracle E-Business Suite. The package encapsulates the logic required to create, maintain, and remove the associations that link a person to a contact person — for example, an emergency contact, a dependent, a beneficiary, or a next of kin — within the Human Resources foundation model. Rather than allowing direct DML against the underlying contact relationship tables, Oracle exposes this API so that callers inherit the same validations, defaults, and date-tracking behavior used by the standard Contact Relationships forms in the People windows.

The package is classified as an API in the ETRM inventory, with the header identifier $Header: pecrlapi.pkb 120.4 2011/11/15 11:33:50 sidsaxen ship $, confirming it is a shipped, supported object in the 12.1.1 and 12.2.2 code lines. It owns the PL/SQL logic for this entity; the corresponding specification, HR_CONTACT_REL_API, declares the public interface. The package is referenced by 14 other packages, indicating that it is a shared dependency used broadly across HR and related product APIs rather than a narrowly scoped utility.

Key Procedures and Functions

  • CREATE_CONTACT — Establishes a new contact relationship between a person and a contact person. The signature captured in the source excerpt shows the parameters that govern the relationship: the effective start date and business group context (p_start_date, p_business_group_id), the two parties to the relationship (p_person_id, p_contact_person_id), the relationship classification (p_contact_type), primary contact and personal flags, life-reason information, sequencing, and a DFF-style attribute block (p_cont_attribute_category through the p_cont_attribute series). A p_validate switch allows the caller to exercise the API without committing.
  • UPDATE_CONTACT_RELATIONSHIP — Applies changes to an existing contact relationship record. This is the procedure most commonly targeted by callers searching on the term update_contact_relationship. It provides the supported mechanism for modifying relationship attributes, effective dates, and descriptive flexfield values on a record previously created through CREATE_CONTACT.
  • DELETE_CONTACT_RELATIONSHIP — Removes or logically terminates a contact relationship record, ensuring that the supporting date-tracked data remains consistent with the HR effective-dating model.

Tables Accessed

The package reads and writes the following documented tables through APPS synonyms:

  • PER_CONTACT_RELATIONSHIPS — The primary transactional table for this API. It stores the contact relationship row itself: the person, the contact person, the contact type, effective dates, primary and personal flags, life reasons, sequence number, and the descriptive flexfield attribute columns. CREATE_CONTACT inserts into this table, UPDATE_CONTACT_RELATIONSHIP modifies existing rows, and DELETE_CONTACT_RELATIONSHIP terminates them.
  • PER_ALL_PEOPLE_F — The date-tracked person record. The API references it to validate that the person and contact person exist and are valid for the requested effective date, and to resolve person-level defaults and derived attributes used during insert or update processing.

Usage Notes

HR_CONTACT_REL_API is typically invoked in three ways. First, it is called by the standard Oracle Forms used to maintain contact relationships in the People and contact windows, which is why the accompanying p_validate parameter exists — the form can run the API in validation-only mode before committing. Second, it is called by other packaged APIs; the metadata records 14 referencing packages, so customizations that need to create or change contact relationships should call this API rather than performing direct inserts or updates on PER_CONTACT_RELATIONSHIPS. Third, it can be invoked from custom PL/SQL, concurrent program logic, or interface programs, provided the caller supplies a valid business group, an effective start date, and a valid contact type.

Because the package maintains data in PER_CONTACT_RELATIONSHIPS and validates against PER_ALL_PEOPLE_F, callers should always run in validation mode during development, pass dates consistent with existing person records, and avoid direct DML. Callers should also account for the descriptive flexfield attribute series when migrating or interfacing data, since those columns are populated exclusively through the API.