Search Results create_vacancy

Overview

The APPS.PER_VACANCY_API package body provides the programmatic interface for creating, maintaining, and removing vacancy records within Oracle E-Business Suite Release 12.1.1 and 12.2.2. A vacancy in Oracle Human Resources (and the wider Oracle iRecruitment and Oracle Recruiting footprint) represents an authorized opening that may be associated with a requisition, a position, a job, a grade, or an organization. The package abstracts the underlying persistence logic so that developers and integrators do not write directly against the vacancy tables, ensuring that validation, business-group security, and effective-dating rules are applied consistently.

The package is classified as an API in the ETRM metadata, owned by the APPS schema. It is referenced by one other package, and it in turn relies on a small set of core HR tables exposed through APPS synonyms. Its header comment identifies the source file as pevacapi.pkb and the shipped version as 120.0.12000000.2, dated 12 June 2007, indicating that the interface has been stable across the 12.1 and 12.2 codelines.

Key Procedures and Functions

The package exposes three documented procedures:

• CREATE_VACANCY — Inserts a new vacancy record. The procedure accepts a broad set of attributes covering the owning requisition, the vacancy name and description, effective dates, security method, business group, and optional references to position, job, grade, organization, people group, location, recruiter, manager, posting, and assessment. Descriptive columns include the number of openings, status, budget measurement type and value, vacancy category, and a full set of descriptive flexfield attributes (ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE10). Parameters such as P_VALIDATE and P_EFFECTIVE_DATE control whether validation is performed and the date from which the record takes effect.
• UPDATE_VACANCY — Modifies an existing vacancy. This is the routine most commonly invoked when a recruiter or HR administrator changes vacancy details such as status, number of openings, manager, recruiter, or descriptive flexfield values. It is the procedure associated with the search term "update_vacancy" and forms the standard supported path for programmatic amendment of vacancy data.
• DELETE_VACANCY — Removes a vacancy record, subject to the same effective-dating and referential constraints enforced by the API layer.

All three procedures follow the standard Oracle HR API conventions, including date-tracking and validation parameters. The metadata does not enumerate the full parameter lists for UPDATE_VACANCY and DELETE_VACANCY; consumers should reference the package specification in the target instance.

Tables Accessed

The package operates against the following tables through APPS synonyms:

• PER_ALL_VACANCIES — The primary store for vacancy definitions. CREATE_VACANCY and UPDATE_VACANCY write here; DELETE_VACANCY removes or end-dates rows.
• PER_ALL_ASSIGNMENTS_F — The effective-dated assignment table. It is read to support vacancy-to-assignment relationships and to validate recruiting or managerial context.
• PER_ASSIGNMENT_STATUS_TYPES — Supplies valid assignment status values used when the vacancy interacts with assignment records, ensuring status codes passed or derived during processing are legitimate.

Usage Notes

PER_VACANCY_API is invoked from the Oracle HR and iRecruitment forms whenever a vacancy is maintained through the user interface, and it is the recommended entry point for custom PL/SQL, interfaces, and conversion routines that must insert or amend vacancy data. Because the package enforces business-group security and effective-date logic, direct DML against PER_ALL_VACANCIES should be avoided in favor of these procedures. Custom concurrent programs that load vacancies from external sources typically call CREATE_VACANCY in a loop and use UPDATE_VACANCY for subsequent corrections. Callers should populate the business group identifier correctly and commit or roll back explicitly according to their transaction design, since the API does not manage the surrounding transaction boundary.