Search Results delete_requisition

Overview

The APPS.PER_REQUISITIONS_API package body is a public Oracle E-Business Suite API that manages the lifecycle of requisitions within the Oracle Human Resources (HR) module. A requisition, in this context, is the HR requisition record used to authorize and track the recruitment or filling of a position. The package encapsulates the business logic required to insert, amend, and remove these requisition records while enforcing the validation, security, and attribute rules defined by Oracle HRMS. It is classified as an API by ETRM, indicating that it is intended for programmatic invocation by other Oracle EBS components or by custom extensions rather than being called directly from a user interface screen.

The package header begins with the standard header comment ($Header: pereqapi.pkb 115.8 2002/12/10 ... eumenyio ship $), confirming it is a long-standing component of the HRMS core, shipped with the applications since well before the 12.1.1 and 12.2.2 releases. A package-level variable g_package varchar2(33) is used to prefix error messages, which is the customary pattern for Oracle HRMS APIs and supports consistent error reporting through the standard FND_MESSAGE or HR_API error handling mechanisms.

Key Procedures and Functions

The documented metadata lists three procedures exposed by this package:

• CREATE_REQUISITION — Creates a new requisition record. The declaration reveals an extensive parameter list led by p_validate (boolean, default false), p_business_group_id, p_date_from, and p_name, followed by an optional p_person_id, comments, an end date, a description, and a very large block of descriptive flexfield attributes (p_attribute_category and p_attribute1 through p_attribute27). This structure allows callers to populate both the core requisition fields and any customer-defined flexfield segments in a single call.
• UPDATE_REQUISITION — Modifies an existing requisition, applying the same validation and flexfield rules as the create operation.
• DELETE_REQUISITION — Removes a requisition record, subject to HRMS referential and business rule checks.

The p_validate parameter on CREATE_REQUISITION is the standard HRMS convention: when set to true, the procedure performs all validation and rollback without committing, returning errors for the caller to inspect; when false, the operation is applied and committed. This permits callers to pre-check data before performing the permanent write.

Tables Accessed

The ETRM metadata does not enumerate the underlying tables, and no APPS synonyms are listed. Based on the HRMS requisition model, the package operates on the core requisition table, PER_REQUISITIONS (and its associated PER_REQUISITIONS_TL translation table for the name and description columns), together with linked tables that store requisition-related flexfield and recruitment data. Because the package exposes descriptive flexfield attributes directly, it also interacts with the descriptive flexfield definition and value structures at validation time. Read access is required to set up and validate business group, person, and date information before each write.

Usage Notes

PER_REQUISITIONS_API is typically invoked from the Oracle HRMS Requisitions and Vacancies forms, from recruitment-related concurrent programs, and from custom PL/SQL that needs to create or maintain requisitions in bulk. It is referenced by one other package per the ETRM metadata, indicating it forms part of a small dependency chain rather than being a leaf utility. Custom code should always call it in preference to direct DML on the requisition tables, since the API enforces business group security, flexfield validation, and the p_validate pre-check contract. Callers should pass a fully qualified business group context, supply the flexfield category and attribute values appropriate to their configuration, and wrap invocations in standard error handling to capture the messages generated via the package's g_package prefix. Because the interface has been stable since the 115.8 version shipped in 2002, code developed against 12.1.1 remains compatible with 12.2.2.