Search Results hire_applicant

Overview

APPS.HR_APPLICANT_BK2 is a generated PL/SQL package body that forms part of the Oracle HRMS Applicant API layer in Oracle E-Business Suite 12.1.1 and 12.2.2. Its principal responsibility is to serve as the hook-processing bridge for the Hire Applicant business event, the operation that converts an existing applicant record into an active employee, contingent worker, or other person type within Oracle Human Resources.

The package is machine-generated. The source header identifies it as output from the "Oracle HRMS API Hook Pre-processor," and the content was generated on 2013/08/13 from the base library file peappapi.pkb (version 120.39.12020000.6, shipped 2013/02/27). This lineage places the object within the standard HRMS API stack rather than in customer extension code. The suffix "BK2" denotes the back-end, second-generation hook variant of the applicant API, so the object sits beneath the public API entry points that forms and external interfaces call.

Key Procedures and Functions

• HIRE_APPLICANT_A — The primary hook procedure for the hire-applicant operation. It accepts the full parameter set needed to create or update the resulting person and assignment records, including hire date, person identifier, assignment identifier, person type, national identifier, object version number, employee number, effective start and end dates, plus warning and validation flags (unaccepted assignment deletion warning, payroll assignment warning, oversubscribed vacancy identifier, and original date of hire). Internally it records the commit unit via hr_api.return_commit_unit, conditionally delegates to the business-rule hook hr_applicant_be2.HIRE_APPLICANT_A when hr_api.call_app_hooks is true, closes the validation set through hr_multi_message.end_validation_set, validates the commit unit with hr_api.validate_commit_unit under the identifier 'HIRE_APPLICANT' and module 'AP', and traces entry and exit points using hr_utility.set_location.
• HIRE_APPLICANT_B — The companion "before" (pre-processing) procedure for the same business event. It provides the corresponding hook invocation point in the API execution sequence, paired with HIRE_APPLICANT_A to bracket the core hire logic. Both procedures are classified under the ETRM API classification "OTHER."

Tables Accessed

The ETRM metadata for this object does not enumerate base tables referenced through APPS synonyms; the documented behavior is expressed entirely in terms of API calls and hook delegation. Indirectly, the hire-applicant event operates on the core HRMS person and assignment entities — principally PER_ALL_PEOPLE_F, PER_ALL_ASSIGNMENTS_F, and PER_PERSON_TYPES — which the parameters (person id, assignment id, person type id, effective dates, employee number) exist to populate and validate. Warning and vacancy parameters indicate interaction with recruitment and payroll validation data. Because access is mediated by the HRMS business-rule layer (HR_APPLICANT_BE2) and the HR API utility packages, direct SQL against these tables is not present in this package body.

Usage Notes

HR_APPLICANT_BK2 is not intended for direct invocation by custom code. It is called by the HRMS API framework as part of the layered sequence that surrounds the applicant hire transaction, and the ETRM metadata records it as referenced by one other package. Typical entry points that ultimately drive this code include the Oracle Forms-based applicant and recruitment windows, the Hire Applicant flow in the People/Recruitment responsibility, and any concurrent or interface process that calls the public HR_APPLICANT_API hire procedures. The commit unit handling and validation-set management mean the procedure expects to run inside the standard HR API transaction context; calling it in isolation would bypass multi-message error collection and commit-unit validation.

For diagnostics, the hr_utility.set_location markers at locations 10 and 20 allow the hire event to be traced during debugging. The "BK2" generation also signals that customer-defined business rules are invoked through the HR_APPLICANT_BE2 hook, so extensions should be registered against that business-rule package rather than modifying HR_APPLICANT_BK2 itself, which is regenerated on patch application.