Search Results eps_code

Overview

The view IGS_OR_INST_HIST belongs to the IGS — Student System product family within Oracle E-Business Suite. The IGS module, which underpins the Oracle Student System, is documented as obsolete in ETRM for releases 12.1.1 and 12.2.2, and the metadata explicitly records that this object is not implemented in this database. Despite that fact, the view definition remains catalogued and is valuable as a reference object for administrators and technical consultants who must interpret legacy SQL, migrate historical integrations, or reconcile data retained from earlier IGS deployments.

Functionally, IGS_OR_INST_HIST presents a historical (date-effective) perspective on institution records maintained by the IGS organization/reference data model. The object name decomposes into an IGS prefix, an Organizational Reference (OR) subject area, an "INST" (institution) entity, and a "HIST" suffix denoting history. Each row represents an institution as it existed between a start and end date, preserving the audit-surrogate identifiers and descriptive operational attributes attached to that institution during the effective window. In reporting and integration terms, the view supports point-in-time institution reporting, institution-change auditing, and reference lookups for historical extract programs that would otherwise require manual assembly of history and current records.

Underlying Base Objects

The view is defined over a single underlying table, IGS_OR_INST_HIST_ALL, which is the multi-organization (Organization ID restricted) history table for institutions. The view exposes TAB.ROWID as ROW_ID and passes through ORG_ID for organization-level filtering, consistent with the _ALL naming convention used throughout EBS for partitioned reference tables.

No other base objects are documented in the ETRM metadata; the referenced base objects list is empty, and the SELECT is a straightforward projection of the _ALL table. Because IGS_OR_INST_HIST_ALL is not implemented in the documented database, no physical rows are returned by this view in the standard 12.1.1/12.2.2 install. Any column-level or row-level access is therefore limited to environments where the IGS history schema was separately installed or where the object is being examined strictly as metadata.

Key Columns

• ROW_ID – the ROWID of the underlying history row; useful for identifying and mutating the specific stored record.
• ORG_ID – owning operating unit / organization, supporting multi-org security and filtering.
• INSTITUTION_CD – the business key identifying the institution.
• HIST_START_DT / HIST_END_DT / HIST_WHO – the date-effective window and the user or process responsible for the historical record.
• NAME – the institution's descriptive name.
• INST_PHONE_COUNTRY_CODE, INST_PHONE_AREA_CODE, INST_PHONE_NUMBER – contact telephone attributes.
• INST_PRIORITY_CD, EPS_CODE, GOVT_INSTITUTION_CD – classification and priority reference codes.
• INSTITUTION_STATUS, LOCAL_INSTITUTION_IND, OS_IND – institution status, local flag, and the OS_IND attribute flagged in the user's search. OS_IND is a Yes/No style indicator carried on the institution record.
• INSTITUTION_TYPE, INST_CONTROL_TYPE, DESCRIPTION – type and control classifications plus free-text description.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – standard EBS audit columns.

Common Use Cases and Queries

Typical uses include reconstructing the institution list as it stood on a given date and validating OS_IND classification values:

SELECT institution_cd, name, institution_status, os_ind,
       hist_start_dt, hist_end_dt
  FROM igs_or_inst_hist
 WHERE os_ind = 'Y'
   AND hist_start_dt <= SYSDATE
   AND (hist_end_dt IS NULL OR hist_end_dt > SYSDATE);

A history audit of a named institution lists all effective versions:

SELECT institution_cd, name, os_ind, hist_start_dt, hist_end_dt, hist_who
  FROM igs_or_inst_hist
 WHERE institution_cd = :institution_cd
 ORDER BY hist_start_dt;

Because the object is obsolete and not implemented, these queries are primarily relevant to migration scripts, documentation, or environments where the IGS history tables were retained. Consultants should verify table existence before relying on the view at runtime.