Search Results ghr_employee_api




Overview
Explore in AI Chat

Overview

GHR_EMPLOYEE_API is a public PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Oracle Human Resources (HR) product family; the "GHR" prefix denotes the Global Human Resources schema, which underpins the core HRMS datetracked entity model. The package is classified as an API in the E-Business Suite Technical Reference Manual (ETRM), indicating that it is a supported, programmatic entry point intended for external invocation rather than an internal helper unit.

The business purpose of the package is to provide a supported interface for creating employee records in the PER (People) schema while preserving the integrity rules enforced by the HR datetrack and business-group security model. Direct inserts into the underlying PER tables bypass validation, datetrack bookkeeping, and Business Group / security profile enforcement, and are therefore unsupported. GHR_EMPLOYEE_API exists so that callers can create a fully validated, datetracked employee row through a single supported call.

The ETRM record confirms the object status as VALID in the APPS schema. The package resolves its dependencies through the SYS schema and the STANDARD package, which is the usual footprint of a compiled PL/SQL unit whose body is not exposed in the published dependency list.

Key Procedures and Functions

The documented ETRM metadata for GHR_EMPLOYEE_API lists a single public procedure or function:

  • CREATE_US_EMPLOYEE — As its name indicates, this routine creates an employee. The "US" designation reflects United States localization behaviour: the routine is designed for Oracle HRMS installations operating under the US (or a compatible) business group, and it applies the employee-number, national identifier, and datetrack conventions expected in that legislative context. In practical use it returns the new employee's PERSON_ID (and, in typical HRMS API signatures, a status/success indicator) to the caller.

The ETRM entry documents only this one program unit on the package specification. Additional helper routines may exist in the package body, but they are not part of the published API surface and must not be relied upon. Callers should treat CREATE_US_EMPLOYEE as the sole supported entry point. Parameter lists are intentionally not reproduced here; developers must obtain the authoritative signature from the package specification in their own environment, since parameter sets vary between point releases and patches.

Tables Accessed

The supplied metadata records the tables referenced through APPS synonyms but lists no DML table names explicitly. Based on the documented function of CREATE_US_EMPLOYEE and the standard HRMS employee-creation path, the package is understood to read and write the core PER entities: PER_PEOPLE_F (the datetracked person row), PER_ASSIGNMENTS_F (the employee assignment), PER_EMPLOYEES, and the associated PER_PERIODS_OF_SERVICE record that supplies the hire and termination dates. It also consults setup and validation entities such as FND_LOOKUPS and the Business Group configuration to enforce US-specific person-type and employee-number rules. Because these accesses occur through APPS synonyms, the package must be compiled and executed with the APPS schema's synonym privileges; no additional grants to the PER schema are required of the caller.

Usage Notes

CREATE_US_EMPLOYEE is typically invoked from three contexts. First, from custom concurrent programs or PL/SQL scripts during data conversion and mass onboarding, where a loop wraps each call with explicit savepoints and error handling, since a failure raises the standard HRMS API exceptions. Second, from form-based personalizations, most commonly on the People and Assignment windows, to enforce site-specific defaults after native creation. Third, from integration layers such as SOA Suite BPEL processes or Oracle Integration Cloud flows performing employee synchronization from an external HCM or payroll system.

Callers should invoke the routine inside a single transaction, commit only after all related assignments and periods of service are created, and use the returned identifier to chain subsequent Address, Contact, and Assignment API calls. Because the package depends on HR datetrack, the effective date passed to the routine determines the row's start date; back-dated creation should be tested carefully against existing future-dated rows. As with all supported EBS APIs, the underlying tables must never be modified directly alongside this call. Finally, the ETRM records zero dependent packages referencing GHR_EMPLOYEE_API, confirming that it is a top-level API intended for external consumers rather than an internal dependency of other delivered code.