Search Results apply_for_job_anytime

Overview

HR_APPLICANT_API is the Oracle Applications public API package that encapsulates the core business rules governing the recruitment lifecycle within Oracle E-Business Suite. Its responsibility is to create, hire, convert, and terminate applicants for the iRecruitment and Human Resources modules, ensuring that the underlying person, assignment, application, and vacancy records are maintained in a consistent and validated state. The package forms part of the HR family of APIs under the APPS schema and is classified as an API, meaning its documented procedures constitute a supported interface for external callers. The header identifies the current packaged source as peappapi.pkb, version 120.18.12010000.7, last shipped in 2008. The body declares package-level constructs including a debug flag derived from HR_UTILITY.DEBUG_ENABLED and a cursor, csr_future_asgs, that selects assignment identifiers and object version numbers from PER_ASSIGNMENTS_F for a given person from a supplied effective date forward. An internal helper function, future_asgs_count, uses that cursor to determine how many assignments a person holds on or after a specified effective date, a check that underpins the assignment-management logic in the public entry points. The package is referenced by 34 other packages, confirming its central position in recruitment-related processing.

Key Procedures and Functions

The documented API comprises fourteen procedures and functions. Their purposes are as follows:

• CREATE_APPLICANT — the generic entry point that creates an applicant record, applying the standard validation and derivation logic regardless of legislation.
• CREATE_GB_APPLICANT — a United Kingdom localisation variant of applicant creation that accommodates UK-specific regulatory and data requirements.
• CREATE_US_APPLICANT — the United States localisation counterpart of applicant creation.
• HIRE_APPLICANT — transitions an existing applicant into an employee or contingent worker by creating the associated assignment and person-type data.
• TERMINATE_APPLICANT — ends an applicant's active status, updating application and assignment status records accordingly.
• CONVERT_TO_APPLICANT — converts an existing person into an applicant, typically used when moving existing workers into a recruitment pipeline.
• APPLY_FOR_JOB_ANYTIME — allows an applicant to apply for a vacancy at any time, independent of any open recruitment window, by creating the corresponding application record.

The remaining seven documented routines are internal supporting elements, such as future_asgs_count, which is explicitly marked "Internal Development Use Only" in the source comments and returns the count of assignments beginning on or after a supplied effective date.

Tables Accessed

The package reads and writes a broad set of recruitment and HR tables through APPS synonyms. PER_ALL_PEOPLE_F stores the person and applicant identities, and PER_ALL_ASSIGNMENTS_F holds the assignment rows created during hiring or conversion. PER_APPLICATIONS and PER_APPLICATIONS_S capture the application made against a vacancy, while PER_ALL_VACANCIES supplies the vacancy definition targeted by APPLY_FOR_JOB_ANYTIME. PER_PERSON_TYPES and PER_ASSIGNMENT_STATUS_TYPES validate and classify the person and assignment states. IRC_ASSIGNMENT_STATUSES supports iRecruitment-specific status tracking, and PER_ESTABLISHMENT_ATTENDANCES links applicants to establishment funding and headcount. Address data is maintained in PER_ADDRESSES, comments in HR_COMMENTS, and organisation context in HR_ALL_ORGANIZATION_UNITS, HR_ORGANIZATION_INFORMATION, and HR_SOFT_CODING_KEYFLEX. PAY_PEOPLE_GROUPS provides payroll grouping for hires.

Usage Notes

HR_APPLICANT_API is invoked from the iRecruitment and HR forms, from concurrent programs that process recruitment transactions in batch, and from custom PL/SQL that must create or modify applicants in a supported manner. Because the procedures enforce the same validation applied by the standard product, direct DML against the underlying tables should be avoided in favour of these APIs. Callers should supply a valid effective date, since the assignment checks performed by the internal helpers are effective-dated, and should expect the standard error-raising behaviour on validation failure.