Search Results hr_contact_extra_info_api




Overview
Explore in AI Chat

Overview

The APPS.HR_CONTACT_EXTRA_INFO_API package is a public, server-side PL/SQL API within the Oracle E-Business Suite Human Resources (HR) module. It belongs to the set of "extra information" APIs that manage the descriptive, user-defined attribute columns collectively known as Descriptive Flexfields (DFF) and the related "Extra Information" (EIT) blocks attached to core HR entities. In this case, the entity is the contact record associated with a person or assignment.

Its business purpose is to provide a controlled, validated entry point for creating, updating, and deleting the extra information rows that are stored in the contact extra information table. Rather than allowing direct DML against the underlying table, Oracle mandates that all changes flow through this API so that validation, security, and date-tracking logic are consistently applied. The package is classified as an API object in the ETRM metadata for releases 12.1.1 and 12.2.2, and its status is VALID, confirming that it is a supported and compiled component of the APPS schema.

Key Procedures and Functions

The documented interface exposes three procedures, each aligned to a single row-level DML operation on the contact extra information entity:

  • CREATE_CONTACT_EXTRA_INFO — Inserts a new extra information row for a contact, populating the descriptive flexfield segment values and standard who-columns (creation date, created-by, etc.) for a newly established contact extra information record.
  • UPDATE_CONTACT_EXTRA_INFO — Modifies the segment or attribute values of an existing contact extra information row, applying the appropriate validation and updating the audit columns.
  • DELETE_CONTACT_EXTRA_INFO — Removes a contact extra information row, ensuring that dependent or dated records are handled correctly before the physical deletion is performed.

Each procedure follows Oracle's standard HR API conventions, including the use of an object version number for optimistic locking and a validation level to control whether the API performs full or partial business-rule checking. The metadata does not enumerate the individual parameter lists, so parameter-level details should be obtained from the package specification in the database dictionary.

Tables Accessed

The API operates against PER_CONTACT_EXTRA_INFO_F, accessed through an APPS synonym. This is the base table that physically stores the extra information rows associated with each contact. The _F suffix indicates that it is a date-tracked ("F" for the current effective record) table, meaning the API is responsible for maintaining the associated _F and date-tracked views so that historical and current values are correctly represented.

Beyond the primary table, the package depends on the shared HR API infrastructure package HR_API, which supplies common utilities such as object version number handling, validation level processing, and error trapping. This dependency confirms that the package adheres to the standard HR API error-handling and locking model rather than implementing bespoke logic.

Usage Notes

This package is typically invoked indirectly by the Oracle HR forms and by other server-side processes rather than being called directly from ad-hoc SQL. The ETRM dependency listing shows that it is referenced by HR_CONTACT_EXTRA_INFO_API itself, the corresponding HR_CONTACT_EXTRA_INFO_SWI (the "set-based" or "stub" wrapper used by the Forms layer), HR_IN_CONTACT_EXTRA_INFO_API for the India localization, HR_PROCESS_CEI_SS, PAY_JP_DEF_SS, and PAY_KR_ENTRIES_PKG. This reference set demonstrates that the API is consumed both by the standard contact maintenance forms and by localization and payroll processes that read or update contact extra information on behalf of Japan, Korea, and India.

Custom code and integrations should call the three documented procedures rather than issuing direct DML against PER_CONTACT_EXTRA_INFO_F. The recommended pattern is to supply the mandatory identifiers, the segment values, and the object version number for updates, and to allow the API and its HR_API dependency to perform validation and audit stamping. Because the package is documented and valid across both 12.1.1 and 12.2.2, the same interface can be relied upon when planning an upgrade between these releases.