Search Results hr_assignment_extra_info_api




Overview
Explore in AI Chat

Overview

The APPS.HR_ASSIGNMENT_EXTRA_INFO_API package body is the public PL/SQL API that manages "extra information" (descriptive flexfield) records attached to an employee assignment in Oracle E-Business Suite Human Resources. In Oracle HRMS, every assignment can carry one or more rows of user-defined extra information, stored in the descriptive flexfield structure defined for the PER_ASSIGNMENT_EXTRA_INFO entity. This API provides the supported, business-rule-aware entry point for creating, updating, and deleting those extra information rows, rather than allowing direct DML against the underlying table.

The package is owned by the APPS schema, is marked VALID, and is classified as an API in the ETRM repository for both 12.1.1 and 12.2.2. It is a documented, referenced object: ETRM records that it is referenced by 40 other database objects, which confirms its role as a shared, reusable integration point consumed by forms, concurrent programs, and custom extensions.

Key Procedures and Functions

The documented API exposes three public procedures, mirroring the standard Oracle HRMS API pattern of a CREATE / UPDATE / DELETE triplet:

  • CREATE_ASSIGNMENT_EXTRA_INFO — Inserts a new extra information row for a given assignment. It applies the HRMS validation and business rules for the assignment extra information flexfield before the record is persisted, ensuring the descriptive flexfield context and segments are valid for that assignment.
  • UPDATE_ASSIGNMENT_EXTRA_INFO — Modifies an existing extra information row. It re-validates the changed flexfield segments and enforces the same business rules as the create operation, preserving data integrity for previously stored rows.
  • DELETE_ASSIGNMENT_EXTRA_INFO — Removes an extra information row for an assignment, applying the API's deletion rules and maintaining the consistency of the assignment's extra information set.

Each procedure is designed to be called from PL/SQL and returns status through the standard HRMS API error/out parameter convention. Parameter lists are intentionally not reproduced here; callers should consult the package specification, which is the authoritative contract.

Tables Accessed

The documented table accessed through APPS synonyms is PER_ASSIGNMENT_EXTRA_INFO. This is the base table that stores the descriptive flexfield values for assignment-level extra information. The API reads and writes this table on behalf of the calling application, which is why direct DML is discouraged — the package centralizes validation, defaulting, and audit behavior for the flexfield data.

ETRM dependency metadata shows the package body also relies on several supporting objects: the HR_API and HR_UTILITY utility packages (for standard HRMS API processing and error handling), the private helper packages HR_ASSIGNMENT_EXTRA_INFO_BK1, HR_ASSIGNMENT_EXTRA_INFO_BK2, and HR_ASSIGNMENT_EXTRA_INFO_BK3, and the row-level handlers PE_AEI_INS, PE_AEI_UPD, and PE_AEI_DEL, which perform the actual insert, update, and delete operations against PER_ASSIGNMENT_EXTRA_INFO. These internal dependencies are not part of the public contract.

Usage Notes

HR_ASSIGNMENT_EXTRA_INFO_API is the supported programmatic interface for maintaining assignment extra information. It is typically invoked from:

  • The Assignment Extra Information window (and responsive/self-service equivalents) in Oracle HRMS, which calls the API to persist flexfield entries.
  • Concurrent programs and batch interfaces that load or migrate assignment-level descriptive flexfield data.
  • Custom PL/SQL extensions and integrations that must create, change, or remove extra information rows while honoring HRMS validation rules.

Because the package is referenced by 40 other objects and is not itself a dependent of any object, it sits near the base of the HRMS assignment extra information stack. Developers should call these procedures rather than issuing direct DML on PER_ASSIGNMENT_EXTRA_INFO, and should initialize the HRMS environment (for example, via the standard HR_API / HR_UTILITY session setup) before invocation. In 12.2.2 the package remains VALID and functionally consistent with its 12.1.1 behavior, so existing customizations that reference it continue to work across both releases.