Search Results create_hu_assign_extra_info




Overview
Explore in AI Chat

Overview

PER_HU_ASSIGN_EXTRA_INFO is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that provides the application programming interface for maintaining assignment-level extra information records in Oracle Human Resources. In the EBS data model, the PER_ASSIGNMENT_EXTRA_INFO table stores flexible, descriptive attributes attached to an employee assignment; these records are keyed by assignment, by the developer-defined information type, and by a DFF context (the information category). This package encapsulates the insert and update logic required to create and maintain those rows consistently, shielding callers from the underlying table structure and from any validation, defaulting, or session-audit handling that the API performs. It is classified in the ETRM repository as an OTHER API, meaning it is a supporting programmatic interface rather than one of the principal datetracked HR APIs such as PER_ASSIGNMENT_API. The package declares AUTHID CURRENT_USER, so its unqualified references resolve through the invoker's schema and APPS synonyms, which is the standard pattern for EBS PL/SQL APIs of this vintage. The dated header comment (pehuaeip.pkh 120.0.12000000.1, 2007) indicates the package body has remained stable across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The package exposes two documented procedures, both operating on assignment extra information.

  • CREATE_HU_ASSIGN_EXTRA_INFO — Creates a new assignment extra information record. The caller supplies the target assignment identifier, the information type that determines which descriptive flexfield applies, the extra information category (the DFF context), and the two attribute columns used to hold the extra information values. This is the entry point used whenever a new set of extra attributes must be attached to an existing assignment.
  • UPDATE_HU_ASSIGN_EXTRA_INFO — Modifies an existing assignment extra information record. Rather than taking an assignment identifier, it is keyed by the primary key of the extra information row itself (the assignment extra information identifier), together with the information category and the two information attribute values. It is therefore used to change the category or the stored values of a record already created by the create procedure.

No functions, and no additional public procedures beyond these two, are documented in the ETRM metadata.

Tables Accessed

The documented table references, resolved through APPS synonyms, are:

  • PER_ASSIGNMENT_EXTRA_INFO — The primary target of both procedures; rows are inserted by CREATE_HU_ASSIGN_EXTRA_INFO and amended by UPDATE_HU_ASSIGN_EXTRA_INFO.
  • PER_ALL_ASSIGNMENTS_F — The datetracked assignment entity. The package references it to validate that the supplied assignment exists and is valid for the effective date on which the extra information is being written.
  • FND_SESSIONS — The Oracle Application Object Library session table, used to derive the current runtime session context, which underpins who-column and audit-trail population on the affected rows.

Usage Notes

Because this is a low-level interface to a single HR table, it is not normally exposed directly to end users. It is invoked from custom PL/SQL that must attach or revise assignment-level DFF data, from forms-based personalizations or custom forms that manage assignment extra information, and from concurrent programs or interfaces loading assignment data from external or legacy systems. Two other packages in the ETRM repository are documented as referencing PER_HU_ASSIGN_EXTRA_INFO, which confirms its role as a shared building block rather than a standalone entry point. When calling these procedures, developers should supply a valid assignment id and a correctly defined information type/context pair, and should perform the call within a properly initialized EBS session so that FND_SESSIONS context and audit columns are populated as expected. Direct DML against PER_ASSIGNMENT_EXTRA_INFO should be avoided in favour of these procedures, and any call should be followed by an explicit commit or rollback as part of the caller's transaction.