Search Results interface_inst_notes_id

Overview

The IGS_OR_INST_NTS_INT table is a staging (interface) table in the Oracle E-Business Suite Student System (IGS) product family, documented as Interface Institution Notes Details. In Oracle EBS 12.1.1 and 12.2.2, IGS objects belong to the legacy Student System module, which is flagged as obsolete in current documentation and, per the ETRM metadata, is not implemented in this database. The table therefore exists as a documented physical schema definition rather than an active runtime structure in a standard installation, and it would only be populated in environments that historically licensed or upgraded the Student System.

Functionally, interface tables such as this one act as a landing zone where external or feeder applications deposit institutional note records before a concurrent program or API validates and migrates them into the permanent institution-notes entity. The row carries both the descriptive note payload and the standard EBS concurrent-manager control columns used to audit and manage the load. From a heuristic Data Vault modeling perspective, the metadata classifies this object as standalone, suggesting it is best treated as an independent structure rather than a hub, link, or satellite within a modeled warehouse — consistent with its short-lived, batch-oriented staging role.

Key Information Stored

The table is documented with 18 columns. The surrogate primary key is INTERFACE_INST_NOTES_ID, enforced by the unique index IGS_OR_INST_NTS_INT_PK. No separate business-key candidate is documented beyond this single unique index, so the surrogate identifier also serves as the interface row identifier.

• INTERFACE_INST_NOTES_ID — surrogate primary key uniquely identifying each interface record.
• INTERFACE_ID — groups related rows into a single interface batch or run.
• ORG_NOTE_SEQUENCE — sequencing value for ordering multiple notes against the same institution.
• ORG_NOTE_TYPE — classification of the note (e.g., type code governing how the note is interpreted).
• START_DATE / END_DATE — effective date range during which the note is valid.
• NOTE_TEXT — the actual free-text content of the institution note.
• STATUS — processing state of the interface row (e.g., pending, processed, error).
• ERROR_CODE — populated when validation or migration fails, indicating the reason.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent-manager lineage identifying the request and program that last touched the row.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit columns.

Common Use Cases and Queries

The primary use case is error diagnosis during an institution-notes load. A typical query inspects rows that failed validation:

• SELECT INTERFACE_INST_NOTES_ID, INTERFACE_ID, ORG_NOTE_TYPE, STATUS, ERROR_CODE FROM IGS_OR_INST_NTS_INT WHERE STATUS = 'ERROR';
• Trace a batch by requesting all rows belonging to one interface run: ... WHERE INTERFACE_ID = :batch_id ORDER BY ORG_NOTE_SEQUENCE;
• Audit concurrent activity using REQUEST_ID joined to the concurrent requests view to identify which program produced the rows.
• Reconciliation reporting: count rows by STATUS and ORG_NOTE_TYPE to confirm intended versus processed volumes.

Because the object is obsolete and unimplemented, these patterns apply primarily to historical or migration data extraction rather than day-to-day production reporting.

Related Objects

The metadata records no foreign-key relationships, characterizing the table as standalone. Consequently, joins are logical rather than enforced. The most significant related objects are the institution-notes interface and base entities within the IGS schema, the concurrent-manager tables referenced by REQUEST_ID, and the standard EBS lookup and audit views. Integration points include the concurrent program that consumes this interface table, the destination institution-notes table it feeds, and the FND concurrent requests view used for lineage. Administrators should consult the IGS schema documentation for the specific consuming program, as no enforced dependencies are declared in ETRM.