Search Results igs_uc_app_cho_cnds_pkg

Overview

The APPS.IGS_UC_APP_CHO_CNDS_PKG package is a PL/SQL stored program in the Oracle EBS Applications schema that supports the UCAS (Universities and Colleges Admissions Service) interface within the Oracle Student System / Student Records (IGS) product family. Its business function is the maintenance of application choice conditions — the qualifying conditions attached to an applicant's course choices submitted through the UCAS admissions process. In this model, an applicant's choices are held in the application choices entity, and each choice may carry one or more associated conditions (for example, grade or qualification requirements imposed by the admitting institution). This package encapsulates the data-access and DML logic for the IGS_UC_APP_CHO_CNDS table and its corresponding _S (translation/description) table, providing a controlled, reusable interface for inserting, updating, locking, and deleting condition records rather than allowing direct table manipulation.

The package is classified as an OTHER API in the ETRM repository, indicating that it is an internal utility package rather than a formally published public API. Its status is VALID, and it records dependencies on the SYS STANDARD package as well as the documented procedures below.

Key Procedures and Functions

The package exposes nine documented program units, which together implement a standard table-handler pattern:

• INSERT_ROW — Inserts a new application choice condition record into the base table.
• LOCK_ROW — Obtains a row-level lock on an existing condition record, typically to serialize concurrent modification.
• UPDATE_ROW — Applies changes to an existing condition record.
• ADD_ROW — Adds a row, typically coordinating insertion across the base and translation tables.
• DELETE_ROW — Removes a condition record.
• GET_PK_FOR_VALIDATION — Retrieves or validates the primary key for a condition row, supporting referential integrity checks.
• GET_UK_FOR_VALIDATION — Retrieves or validates the unique key for a condition row.
• GET_FK_IGS_UC_APP_CHOICES — Returns the foreign key linking a condition to its parent application choice record.
• BEFORE_DML — A pre-DML trigger-style procedure that enforces standard WHO-column and key-population logic before insert, update, or delete operations.

These routines follow Oracle EBS conventions for maintaining surrogate keys, descriptive flexfields, and translation rows consistently.

Tables Accessed

The package operates on the following documented objects, accessed through APPS synonyms:

• IGS_UC_APP_CHO_CNDS — The base table storing application choice condition records. All insert, update, lock, and delete activity targets this table.
• IGS_UC_APP_CHO_CNDS_S — The translation/description table holding language-specific or descriptive attributes for each condition, maintained alongside the base row.
• DUAL — Used for single-row evaluations, key lookups, and validation queries that do not require a physical table.

These reads and writes support the linkage between individual conditions and their parent application choices, as reflected in the foreign-key accessor GET_FK_IGS_UC_APP_CHOICES.

Usage Notes

IGS_UC_APP_CHO_CNDS_PKG is typically invoked indirectly rather than called directly by end users. The ETRM dependency data shows it is referenced by IGS_UC_APP_CHOICES_PKG, IGS_UC_EXPUNGE_APP, and by itself (recursive or internal reference), and it in turn is called by those packages to maintain condition data during UCAS choice processing and application expunge/purge operations. In Oracle EBS 12.1.1 and 12.2.2, such packages are commonly reached from the UCAS inbound interface forms or concurrent programs that load and reconcile choice and condition data, as well as from the application expunge concurrent program. Because it is classified as OTHER rather than a public API, customizations should avoid calling it directly; developers should instead call the higher-level IGS_UC_APP_CHOICES_PKG routines that wrap it, ensuring that WHO columns, translations, and foreign keys remain consistent. Any direct use should be limited to controlled data-fix scripts and must respect the BEFORE_DML validation logic.