Search Results igs_ps_unit_lvl_pkg




Overview
Explore in AI Chat

Overview

The APPS.IGS_PS_UNIT_LVL_PKG package body is a core program unit within the Oracle E-Business Suite Student System (IGS) schema. It provides the underlying transactional logic that manages unit level records associated with academic units of study — specifically the relationship between a unit version and the level at which that unit is offered or classified. In Oracle EBS 12.1.1 and 12.2.2, unit levels form part of the academic structure used by institutions to categorise units (for example, introductory, intermediate, or advanced levels) and to drive validation, progression, and reporting rules. The package encapsulates the insert, update, delete, lock, and constraint-checking behaviour that the Oracle Forms-based Units of Study setup screens invoke indirectly through the table-level API. It is classified under the generic API category (OTHER) rather than as a public, fully supported open interface, meaning it is intended primarily to support the delivered application UI and internal processing.

Key Procedures and Functions

The metadata documents ten procedures and functions that constitute the package's #API-style surface:

  • INSERT_ROW — Performs the physical insert of a new unit level row into the base table, applying defaulting and mandatory column population.
  • UPDATE_ROW — Applies changes to an existing unit level record.
  • LOCK_ROW — Obtains a row-level lock on the target unit level record, enforcing optimistic concurrency control during a form transaction.
  • ADD_ROW — Higher-level entry point that orchestrates the creation of a new record, typically combining validation and insertion steps.
  • DELETE_ROW — Removes a unit level record, subject to referential and business-rule checks.
  • GET_PK_FOR_VALIDATION — Derives or confirms the primary key values required when validating the current record.
  • GET_FK_IGS_PS_UNIT_VER — Resolves the foreign key relationship to the unit version entity, confirming that the parent unit version exists and is valid.
  • GET_FK_IGS_PS_VER — Resolves the foreign key relationship to the version entity, validating the associated version context.
  • CHECK_CONSTRAINTS — Evaluates business and database constraints (uniqueness of the unit-version/level combination, mandatory attributes, and related validity rules) before a DML operation is committed.
  • BEFORE_DML — The pre-DML hook invoked ahead of insert, update, or delete to run standard validation, message stacking, and defaulting logic.

Tables Accessed

The package operates against the IGS_PS_UNIT_LVL_ALL table, accessed via the APPS synonym, which is the primary store for unit level records across the unit version hierarchy. The DUAL table is referenced for single-row value selection and validation expressions. Dependency metadata also indicates interaction with related packages rather than direct table DML, including IGS_PS_UNIT_LEVEL_PKG, IGS_PS_UNIT_VER_PKG, IGS_PS_VAL_UNIT, IGS_PS_VAL_UV, IGS_PS_VER_PKG, and generation routines IGS_PS_GEN_007 and IGS_GE_GEN_003. These relationships confirm that unit level maintenance is tightly coupled to unit version validation and to the standard EBS error-handling framework.

Usage Notes

IGS_PS_UNIT_LVL_PKG is normally invoked indirectly from the Oracle Forms-based Units of Study maintenance screens, where row-level triggers fire the BEFORE_DML, ADD_ROW, UPDATE_ROW, and DELETE_ROW procedures during user transactions. It is referenced by three other database objects, confirming its role as a dependent library within the IGS package family. Direct invocation from custom code is possible but not recommended, since the package is documented as a generic API rather than an open, supported interface. Errors raised during execution are propagated through APP_EXCEPTION, FND_MESSAGE, and IGS_GE_MSG_STACK, so administrators reviewing failures should inspect the EBS message stack and concurrent request logs rather than the package output directly. Because it references IGS_PS_UNIT_LVL_ALL through an APPS synonym, any custom extension should observe the same multi-org and business-group security context used by the delivered forms.