Search Results isir_transaction_type




Overview
Explore in AI Chat

Overview

IGF_AP_ISIR_MATCHED_ALL is a Financial Aid (IGF) module table in Oracle E-Business Suite, documented in the ETRM for releases 12.1.1 and 12.2.2. Its stated purpose is to hold the complete ISIR record of matched students. An ISIR (Institutional Student Information Record) is the output produced by the U.S. Department of Education's Central Processing System (CPS) after processing a student's FAFSA, and this table acts as the staging and archival repository for the full institutional copy of that record once a student has been matched to an existing financial aid applicant or person record. The table is flagged as belonging to an obsolete area of IGF, and the ETRM notes it is not implemented in this database; consequently, in many environments the object will exist only in older installations where the legacy Financial Aid product was licensed and configured. It should not be treated as a supported extension point.

The 311-column footprint reflects the breadth of the ISIR payload, which carries student, parent, need-analysis, verification, and match-result data. Under a heuristic Data Vault classification derived from the foreign key structure, the object leans toward a hub role: its primary key ISIR_ID is a surrogate identifier, and several satellite-like detail tables in the surrounding model reference it. This is a modeling suggestion rather than a documented Data Vault implementation, and the table's denormalized shape does not conform strictly to hub/satellite separation.

Key Information Stored

The table's integrity is anchored by the primary key IGF_AP_ISIR_MATCHED_ALL_PK on the column ISIR_ID, which is the surrogate identifier for a single ISIR transaction. The ETRM lists no additional unique index; the business-key candidates are therefore carried within the record itself rather than enforced as alternate keys, for example the combination of BATCH_YEAR, TRANSACTION_NUM, and DRN, along with identifiers such as SERIAL_NUMBER and BATCH_NUMBER. The most consequential stored attributes include:

Common Use Cases and Queries

Historically this table supported ISIR load and match processing, verification tracking, need-analysis comparison, and financial aid reporting. A typical query retrieves the active ISIR for an applicant by joining to the base record:

SELECT m.ISIR_ID, m.TRANSACTION_NUM, m.PRIMARY_EFC
FROM   IGF_AP_ISIR_MATCHED_ALL m, IGF_AP_FA_BASE_REC_ALL b
WHERE  m.BASE_ID = b.BASE_ID
AND    m.ACTIVE_ISIR = 'Y'
AND    m.BATCH_YEAR = :p_award_year;

Verification reporting commonly filters on VERIFICATION_FLAG, while EFC trending compares PRIMARY_EFC and PAID_EFC across TRANSACTION_NUM values. Correction history is examined through the related IGF_AP_ISIR_CORR_ALL table keyed by ISIR_ID.

Related Objects

The following objects are documented as directly related through foreign keys:

  • IGF_AP_FA_BASE_REC_ALL — parent base record referenced via BASE_ID.
  • IGF_AP_EFC_DET — Expected Family Contribution detail, referencing CONTEXT_ISIR_ID.
  • IGF_AP_ISIR_CORR_ALL — ISIR correction records, referencing ISIR_ID.
  • IGF_AP_NSLDS_DATA_ALL — NSLDS match data, referencing ISIR_ID.
  • IGF_AW_FISAP_REP — Financial Aid reporting structure, referencing ISIR_ID.

Together these define the legacy ISIR processing constellation within the obsolete IGF Financial Aid module.