Results for “igs_en_intm_rconds”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGS_EN_INTM_RCONDS is a reference table owned by the IGS schema within the Oracle E-Business Suite Student System (IGS) module. Its documented description is Intermission Return Conditions. The table defines the set of conditions under which a student who has taken an approved intermission (a temporary leave of absence) may return to active study. Each condition is an addressable, reusable code that can be referenced by other student-system entities rather than being hard-coded at the transaction level.

Because the table is small, code-centric, and serves as the target of a foreign key from another table, the heuristic Data Vault classification mined from its foreign-key structure is hub-leaning. In a Data Vault 2.0 model this would be modelled as a hub, with RETURN_CONDITION as the natural business key, and any descriptive attributes carried in a satellite attached to that hub. This is a modelling suggestion rather than a physical implementation statement: in EBS 12.1.1 and 12.2.2 the object is a conventional seeded reference table.

Key Information Stored

The table carries eight documented columns. The most significant are:

• RETURN_CONDITION — the primary key, defined by the unique index IGS_EN_INTM_RCONDS_PK. It is both the surrogate primary key and the business-key candidate; it holds the short code that identifies each intermission return condition.
• DESCRIPTION — the human-readable meaning of the return condition, used in list-of-values displays, enquiry screens, and reports.
• CLOSED_FLAG — an active/inactive indicator. Conditions with the closed flag set are retained for historical integrity but should not be offered for new selections.
• CREATED_BY, CREATION_DATE — standard WHO audit columns recording the user and timestamp that created the row.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns recording the most recent amendment and the login under which it was made.

There is no separate surrogate sequence key documented beyond RETURN_CONDITION; the code itself functions as both the technical and the business identifier.

Common Use Cases and Queries

Typical usage is validation and decoding rather than high-volume transaction processing. A reporting query to list all currently valid intermission return conditions would take the form:

• SELECT return_condition, description FROM igs.igs_en_intm_rconds WHERE NVL(closed_flag,'N') = 'N' ORDER BY return_condition;

A join is used when the condition attached to a specific student intermission record must be resolved to its descriptive text. Because the table is a foreign-key target from IGS_EN_SPI_RCONDS, the pattern joins on RETURN_CONDITION to translate the stored code into a display value.

Other scenarios include building a validation set for an admission or progression process that checks whether a returning student satisfies a permitted condition, populating a list of values in a personalised OAF page or Forms block, and auditing when a condition was introduced or retired using the WHO columns. Because the table is seed/reference data, extraction jobs targeting a warehouse should treat it as a small dimension or hub load rather than a change-data-capture candidate.

Related Objects

The principal documented relationship is the inbound foreign key from the following table:

• IGS_EN_SPI_RCONDS — joins via IGS_EN_SPI_RCONDS.RETURN_CONDITION → IGS_EN_INTM_RCONDS.RETURN_CONDITION. This is the dependent table that consumes the return-condition codes defined here.
• IGS_EN_INTM_RCONDS_PK — the unique index enforcing uniqueness of RETURN_CONDITION and therefore guaranteeing referential integrity for the dependent table.

Beyond the documented foreign key, the table is referenced indirectly by any IGS intermission or student-progression enquiry, list-of-values definition, and concurrent program that resolves an intermission return condition to its description. Because the ETRM metadata documents only a single inbound relationship, integrators should confirm additional dependencies in their specific 12.1.1 or 12.2.2 instance before assuming the relationship set is exhaustive.