Search Results igs_ru_description_pkg




Overview
Explore in AI Chat

Overview

The APPS.IGS_RU_DESCRIPTION_PKG package is a core database component within the Oracle EBS Student Systems / Student Records (IGS) product family, specifically belonging to the "RU" (Result / Rules) functional area. Its primary business function is to manage and maintain the definition of result-related description records stored in the IGS_RU_DESCRIPTION table. These descriptions provide the descriptive text and classification attributes associated with result-processing rules, named rules, return types, and Turin functional definitions. The package encapsulates the standard Oracle Forms table-handling API pattern — a row-level Data Manipulation Language (DML) layer that supports insert, update, delete, locking, and pre-validation of description records. It is classified as an OTHER type API, indicating it is an internal technical support package rather than a public integration API. In Oracle EBS 12.1.1 and 12.2.2, the package resides in the APPS schema with a status of VALID and is a dependency of several higher-level result-processing packages.

Key Procedures and Functions

The package exposes eleven documented procedures and functions, organized around the Oracle EBS forms DML framework:

  • INSERT_ROW — Inserts a new description record into the underlying description table.
  • ADD_ROW — Adds a row via the forms block interface, applying default and derived column values prior to persistence.
  • UPDATE_ROW — Updates an existing description record with modified column values.
  • DELETE_ROW — Removes a description record from the table.
  • LOCK_ROW — Issues a row-level lock to support concurrency control during editing.
  • BEFORE_DML — A trigger-style routine executing validations and audit-column population before any DML operation.
  • CHECK_CONSTRAINTS — Validates that constraint-relevant conditions are satisfied before a DML statement is committed.
  • GET_PK_FOR_VALIDATION — Resolves the primary key used for validation lookups.
  • GET_UK1_FOR_VALIDATION — Resolves the unique key (UK1) used for validation lookups.
  • GET_FK_IGS_RU_RET_TYPE — Retrieves the foreign key value linking to the IGS_RU_RET_TYPE table for referential validation.
  • GET_FK_IGS_RU_TURIN_FNC — Retrieves the foreign key value linking to the IGS_RU_TURIN_FNC table for referential validation.

These routines collectively form the standard "handle row" API paradigm, where validations are centralized in BEFORE_DML, CHECK_CONSTRAINTS, and the GET_*_FOR_VALIDATION helper functions.

Tables Accessed

According to documented dependency information, the package references the following tables through APPS synonyms:

  • IGS_RU_DESCRIPTION — The primary base table holding the description records managed by this package.
  • IGS_RU_ITEM — Referenced for item-level relationships or validation of description-to-item associations.
  • IGS_RU_NAMED_RULE — Referenced to associate descriptions with named rules in the result-processing model.

These represent the key operational tables. The package also depends on the SYS.STANDARD package, which is a standard PL/SQL dependency.

Usage Notes

IGS_RU_DESCRIPTION_PKG is referenced by six other database packages: IGS_RU_CALL_PKG, IGS_RU_DESCRIPTION_PKG (self-reference), IGS_RU_GEN_006, IGS_RU_GROUP_SET_PKG, IGS_RU_NAMED_RULE_PKG, IGS_RU_RET_TYPE_PKG, and IGS_RU_TURIN_FNC_PKG. This dependency footprint demonstrates that the package functions as a supporting entity layer consumed by higher-level result-processing logic. It is typically invoked indirectly through Oracle Forms-based maintenance screens, where the standard forms trigger framework calls ADD_ROW, UPDATE_ROW, DELETE_ROW, and LOCK_ROW as users create or modify description records. Custom code, concurrent programs, or integration routines that need to automate maintenance of result descriptions can call the DML procedures directly, provided the surrounding key-resolution and constraint-validation routines are invoked in the appropriate order. Because the package is an internal helper rather than a public API, direct invocation should follow the same sequence enforced by the forms layer — validation routines first, then BEFORE_DML, then the DML operation.