Search Results hr_assignment_extra_info_bk2




Overview
Explore in AI Chat

Overview

The APPS.HR_ASSIGNMENT_EXTRA_INFO_BK2 package is a PL/SQL database package owned by the APPS schema in Oracle E-Business Suite. It forms part of the Oracle Human Resources (HR) date-tracked ("Datetrack") infrastructure that manages assignment-level extra information — the descriptive, flexfield-based attributes attached to an employee assignment that are not part of the core assignment record. In EBS, changes to date-tracked HR entities are captured through companion tables and processed through a sequence of validation, pre-processing, and post-processing steps. The "BK2" suffix follows the Oracle HRMS naming convention for the second backing/pre-processing routine in this sequence, positioned between the BK1 backing store and the main API logic.

This package exists to support the HR_ASSIGNMENT_EXTRA_INFO_API package, which exposes the public programming interface for maintaining assignment extra information. Because extra information is date-effective, the backing packages capture interim state and stage the data so that the API can apply proper date-track logic, validate the change, and update the entity consistently across the business group and assignment history. The ETRM metadata classifies this object with an API classification of OTHER and status VALID, confirming it is an internally consumed, non-public component of the HR API layer rather than a customer-facing entry point.

Key Procedures and Functions

The documented package exposes two procedures:

  • UPDATE_ASSIGNMENT_EXTRA_INFO_B — the "before" (pre-processing) routine. As the "_B" suffix indicates, this procedure executes before the main update processing. Its purpose is to capture and back up the current state of the assignment extra information rows prior to modification, preserving the values required by the Datetrack mechanism so that the change can be applied or subsequently rolled back or compared.
  • UPDATE_ASSIGNMENT_EXTRA_INFO_A — the "after" (post-processing) routine. The "_A" suffix denotes execution after the primary update logic. This procedure finalizes the update of assignment extra information, typically writing the finished date-tracked rows and reconciling interim state established by the "_B" routine.

No parameter lists are documented in the ETRM metadata; parameter details should be confirmed against the deployed source in the target instance. The procedures are intended strictly for internal invocation by the HR API layer and are not designed for direct external calls.

Tables Accessed

ETRM documents no explicit base tables referenced directly by this package. The dependency listing shows a reference to the SYS.STANDARD package, which is the standard PL/SQL built-in package (providing foundational datatypes and language constructs) rather than an application data table. Consistent with its role as a backing routine, the package operates on the assignment extra information entity in coordination with its parent API, HR_ASSIGNMENT_EXTRA_INFO_API. The actual DML against the underlying extra information tables is driven through that API and the Datetrack infrastructure; the "_B" routine stages the pre-update snapshot while the "_A" routine applies the finalized result.

Usage Notes

This package is not intended for direct invocation by end users, forms, concurrent programs, or custom code. It is called internally by APPS.HR_ASSIGNMENT_EXTRA_INFO_API, which serves as the sanctioned public interface for creating and updating assignment extra information. The dependency metadata confirms this relationship: the API references HR_ASSIGNMENT_EXTRA_INFO_BK2, and the package itself appears in its own referenced-by list, reflecting the paired "_B" and "_A" routines.

Customizations or extensions should always target the public API rather than these backing procedures. Because the "_BK2" layer implements Oracle's internal Datetrack processing sequence, its logic, signatures, and behavior are subject to change between 12.1.1 and 12.2.2 and should be treated as opaque implementation detail. Any customization that bypasses the API and calls the backing package directly risks corrupting the date-effective history of assignment extra information and is unsupported.