Search Results step_override_type




Overview

The IGS_EN_ELGB_OVR_STEP table is a core data structure within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2, specifically for the Oracle Student Management (OSM) product. It functions as the detailed repository for enrollment eligibility overrides applied at the granular level of individual validation steps. When a student's enrollment request is subject to standard eligibility rules—such as prerequisites, co-requisites, or credit limits—an administrator may grant an exception. This table records the specifics of each overridden validation step, linking it to a master eligibility override header. Its primary role is to maintain a precise audit trail of which specific rule checks were bypassed, by whom, and when, ensuring compliance and data integrity within the student enrollment lifecycle.

Key Information Stored

The table's columns capture the override's identity, type, and administrative context. The ELGB_OVR_STEP_ID serves as the primary unique identifier for each override step record. The ELGB_OVERRIDE_ID is a critical foreign key linking the step to its parent override record in the IGS_EN_ELGB_OVR_ALL table. The central column for business logic is STEP_OVERRIDE_TYPE, which defines the category of the eligibility rule being overridden (e.g., a specific prerequisite check). This column is part of a unique index (IGS_EN_ELGB_OVR_STEP_U1), enforcing that a given override type is recorded only once per parent override. Supporting columns include STEP_OVERRIDE_DT (the application date), STEP_OVERRIDE_LIMIT (for credit point overrides), and standard WHO columns for tracking creation and modification. Notably, columns UNIT_CD, VERSION_NUMBER, and UOO_ID are documented as obsolete, indicating their business logic has likely been migrated elsewhere in later releases.

Common Use Cases and Queries

This table is essential for auditing, reporting, and troubleshooting enrollment exceptions. A common operational query involves listing all step-level overrides for a specific student or enrollment attempt, joining to the parent header and person tables. For example, to audit overrides of a specific type, one might use:

SELECT step.step_override_type,
       step.step_override_dt,
       step.step_override_limit,
       header.person_id
FROM   igs.igs_en_elgb_ovr_step step,
       igs.igs_en_elgb_ovr_all header
WHERE  step.elgb_override_id = header.elgb_override_id
AND    step.step_override_type = '&STEP_TYPE';

Reporting use cases include generating compliance reports on the frequency of overrides by type or user, or analyzing the impact of overrides on student progression. Support personnel query this table to verify the existence and details of an override when resolving enrollment errors. The unique constraint on STEP_OVERRIDE_TYPE and ELGB_OVERRIDE_ID ensures data consistency by preventing duplicate overrides of the same step type for a single master override transaction.

Related Objects

The table maintains defined relationships with several other key OSM entities through foreign key constraints, as documented in the ETRM metadata.

  • Primary Key: IGS_EN_ELGB_OVR_STEP_PK on column ELGB_OVR_STEP_ID.
  • Foreign Key (Parent Override): The ELGB_OVERRIDE_ID column references IGS.IGS_EN_ELGB_OVR_ALL.ELGB_OVERRIDE_ID. This is the primary relationship, connecting the step detail to its master override header.
  • Foreign Key (Unit Offering): The obsolete UOO_ID column references IGS.IGS_PS_UNIT_OFR_OPT_ALL (Unit Offering Option).
  • Foreign Key (Unit): The obsolete UNIT_CD column references a unit code, though the specific parent table is not fully named in the provided metadata.

These relationships are crucial for constructing accurate joins in reports that need to combine override details with student, course, or unit offering information.