Search Results per_assignment_budget_values_s




Overview
Explore in AI Chat

Overview

The APPS.PER_ABV_INS package body is an Oracle E-Business Suite database object that supports insert operations for the Assignment Budget Values entity within the Oracle Human Resources (HR) module. Assignment Budget Values represent the allocation of an employee assignment against one or more budget measurement criteria, which are used by HRMS budgeting functionality to track workforce costs and headcount against defined budgets. The package name follows the standard EBS naming convention: PER identifies the Human Resources (People) product, ABV abbreviates Assignment Budget Values, and INS denotes the "insert" layer of the generated table-handling API stack. In EBS releases 12.1.1 and 12.2.2, this package exists in the APPS schema with a VALID status and is classified under the "OTHER" API category. Its role is to provide the internal insertion entry point that seeds a new assignment budget values row by combining the API validation logic (typically delegated to business-layer objects such as PER_ABV_BUS) with a physical DML write to the underlying table, while also invoking the row-level key information (PER_ABV_RKI) and shadow/audit handling (PER_ABV_SHD) that are standard to the HRMS DT_API generated code framework.

Key Procedures and Functions

The ETRM metadata documents two procedures or functions within the package body: INSERT_DML and INS. Based on standard Oracle HRMS generated API patterns, these correspond to the two-tier insert construction used by DT_API:

  • INSERT_DML — Performs the actual Data Manipulation Language statement against the underlying table. It is the low-level routine responsible for committing the row insert into the Assignment Budget Values table, including the WHO columns and any dependent-key columns needed for multi-tenant or business-group integrity.
  • INS — The higher-level insert procedure that orchestrates the operation. It applies validation and business rules delegated to the *_BUS package, resolves row keys via *_RKI, and then calls INSERT_DML to persist the record. Callers normally invoke INS rather than the DML routine directly.

The metadata does not expose parameter signatures, so no parameter lists are reproduced here. The package depends on HR_API, HR_UTILITY, FND_GLOBAL, FND_MESSAGE, and DT_API for error handling, message resolution, environment context, and generated-API infrastructure.

Tables Accessed

The package accesses two documented tables through APPS synonyms:

  • PER_ASSIGNMENT_BUDGET_VALUES_F — The generated "F" (foreign key/interface-friendly) table form of Assignment Budget Values. It is used by the API to validate foreign keys and expose the row in the standard generated-API view before the DML is applied.
  • PER_ASSIGNMENT_BUDGET_VALUES_S — The primary base table where assignment budget value records are physically stored. This is the object the user searched for, and it is the ultimate destination of the insert performed by INSERT_DML. Each row associates an assignment with a budget measurement criterion and holds the corresponding budgeted value.

In addition to these, the dependency list references DUAL for simple scalar lookups and standard PL/SQL runtime units.

Usage Notes

This package is not intended as a public, directly callable API. It is the insert component of a generated HRMS table-handling layer and is typically invoked in one of three ways:

  • Internal chaining — The sibling package PER_ABV_API (or the corresponding generated API) invokes PER_ABV_INS.INS to satisfy a create request routed through the standard HRMS API surface.
  • Concurrent programs and forms — Oracle HR forms and bulk budget-load concurrent programs that create assignment budget values route their inserts through this package so that validation, row-key generation, and audit shadowing are applied consistently.
  • Custom code — Customers writing extensions should call the supported public API layer rather than PER_ABV_INS directly, since direct invocation bypasses the public validation entry points. The ETRM record notes that this package is referenced by four other database objects, confirming it sits underneath the supported API stack rather than at its top.

Because the package is marked VALID on 12.1.1 and 12.2.2, its behavior is stable across the two releases; the 12.2 online-patching model does not alter its interface. Any invalidation after an upgrade can be resolved by recompiling the dependent API chain.