Search Results hr_contact_api




Overview
Explore in AI Chat

Overview

APPS.HR_CONTACT_API is a public PL/SQL API supplied by Oracle E-Business Suite to create and maintain contact and person records within the Human Resources (PER) schema. The package body, whose source header identifies the file as peconapi.pkb, exposes a controlled, validated interface over the core person tables so that callers do not write directly to PER_ALL_PEOPLE_F. The package is classified in the ETRM repository as an API owned by APPS, and it is referenced by 23 other packages, indicating that it is a foundational building block relied upon by other Oracle-delivered and customer extensions across the HR, Payroll, and self-service product families.

The primary business purpose is the creation of person records that function either as employees, applicants, or non-employee contacts. The naming of the package reflects the original "contact" use case, but the routines it exposes populate the general person model and therefore influence downstream processing such as assignment creation, payroll eligibility, and person-type reporting.

Key Procedures and Functions

  • CREATE_PERSON — Creates a new person row in the PER_ALL_PEOPLE_F entity, accepting the core biographical and contact attributes required for a person record. Its documented parameter list includes p_validate (allowing the caller to run the procedure in validation-only mode without committing data), mandatory inputs of p_start_date, p_business_group_id, p_last_name, and p_sex, plus an extensive set of optional attributes covering first and middle names, known-as name, previous last name, title, date of birth, marital status, nationality, national identifier, comments, date employee data verified, e-mail address, work telephone, expense check send-to address, registered disabled flag, vendor identifier, person type identifier, and a user-defined attribute category with attribute1 through attribute12. All attributes following p_person_type_id default to null, so the API can be called with only the mandatory values.
  • CREATE_IREC_PERSON — A companion entry point that creates a person record in the iRecruitment context. It reuses the same person model but is tailored to the iRecruitment (external candidate) data requirements. As with CREATE_PERSON, callers should treat the parameter interface as fixed and should not assume undocumented behaviour.

Tables Accessed

  • PER_ALL_PEOPLE_F — The principal target of both creation routines. All insert and update activity is concentrated here, with row-level validation applied against the business group and date-tracked EFFECTIVE_START_DATE and EFFECTIVE_END_DATE columns.
  • PER_PERSON_TYPES — Consulted to validate and resolve the person type supplied through p_person_type_id, and to enforce the correct system person type for the business group.
  • PER_PHONES — Used to persist the work telephone information passed via p_work_telephone.

Access is performed through APPS synonyms, so no direct schema qualification is required by the calling session.

Usage Notes

HR_CONTACT_API is most commonly invoked from custom PL/SQL, from concurrent programs that load person or contact data in bulk, and from other Oracle API packages — the ETRM metadata records 23 referencing packages. The recommended invocation pattern is to call create_person inside a PL/SQL block or a database package, passing p_validate => TRUE first to confirm data validity without side effects, then re-invoking with p_validate => FALSE to perform the actual create. Because the procedure uses BOOLEAN parameters, it cannot be called directly from Oracle Forms or from tools that do not support PL/SQL BOOLEAN semantics; those environments should wrap the call in a stored procedure that accepts a VARCHAR2 validation flag and translates it. Callers are responsible for commit or rollback, and the current date should normally be supplied as p_start_date unless back-dated records are required.

When the goal is iRecruitment rather than general contact creation, create_irec_person should be used, as it applies the appropriate business rules for that population. Because the package writes to date-tracked and multi-org aware tables, all calls must supply a valid p_business_group_id and should be made within a session where the HR security profile is set appropriately. Finally, reliance on the attribute1 through attribute12 columns requires a value in p_attribute_category to make the flexfield descriptive segments meaningful.