Search Results per_vac_upd




Overview
Explore in AI Chat

Overview

PER_VAC_UPD is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the maintenance of vacancy records within the Oracle Human Resources (HR) module. Its name follows the longstanding EBS convention in which an UPD package provides the low-level insert, update, and delete operations underpinning a corresponding public API—in this case PER_VACANCY_API. Vacancies are the requisition-side records used by HR and recruitment to define open positions, their organization, job, and validity dates, and to link applicants and offers against them. PER_VAC_UPD encapsulates the direct row-level manipulation of the vacancy tables so that calling code does not issue DML against the base tables itself.

The package status is VALID in Oracle EBS 12.1.1 and 12.2.2, and it is classified as an "OTHER" API. This classification indicates that it is an internal implementation package rather than a formally published, externally supported interface. Customers and integrators are expected to use PER_VACANCY_API for entry points, with PER_VAC_UPD invoked only transitively by that API or by other product code.

Key Procedures and Functions

The ETRM metadata documents two procedures or functions, both named UPD. This is consistent with the typical layout of an updater package, where an overloaded or paired routine handles the write path. In practice, this pair comprises a procedure that performs the actual insert/update/delete against the vacancy tables, and a companion routine (or overload) that carries the caller's session and business-group context, returning status and error information through standard HR_API error-handling parameters. No parameter signatures are documented in the metadata, and none should be assumed; the routines are addressed by name only. Callers supply vacancy attribute values, row identifiers, and the standard API context arguments, and receive a success or error outcome suitable for message retrieval through HR_API utilities.

Tables Accessed

The documented table reference is PER_ALL_VACANCIES, accessed through an APPS synonym. PER_ALL_VACANCIES is the primary transactional store for vacancy definitions, holding the vacancy identifier, name, business group, organization, job, position, and validity dates. The UPD routines read and write this table to create new vacancy rows, modify existing ones, and retire vacancies that are no longer active.

The dependency metadata further shows that PER_VAC_UPD references PER_VAC_SHD, the shadow (audit) table maintained for the vacancy entity. Writes to PER_ALL_VACANCIES are therefore accompanied by the corresponding date-tracked history rows in PER_VAC_SHD, preserving a full audit trail of changes. The package also depends on HR_API, the shared HR utility package used throughout Oracle HRMS for error stacks, message handling, and date-tracked column maintenance. Dependencies on SYS.STANDARD reflect standard PL/SQL language elements.

Usage Notes

PER_VAC_UPD is not intended for direct invocation from forms, concurrent programs, or custom code. In standard Oracle EBS flow, it is called by PER_VACANCY_API, the sole referenced-by entry in the metadata, which exposes the supported vacancy creation and maintenance operations. Forms in the iRecruitment and HR vacancy flows, and concurrency such as vacancy-related batch processes, reach PER_VAC_UPD through that API. The package also lists itself as a dependent, indicating internal private routine calls within the package body.

Because the interface is undocumented and unsupported, customizations should call PER_VACANCY_API rather than PER_VAC_UPD. Direct calls risk bypassing validation performed at the API layer and may fail on upgrades, since overloads and internal parameters are not guaranteed across releases. When troubleshooting vacancy data issues in 12.1.1 or 12.2.2, PER_VAC_UPD is best used as a diagnostic reference point—locating the DML that produced a given row in PER_ALL_VACANCIES and its corresponding PER_VAC_SHD history—rather than as a programming entry point. All access should respect the package owner APPS and the standard HR_API error-handling contract.