Search Results stud_rec_count

Overview

IGF_AP_ISIR_BATCHES is a Financial Aid (IGF) reporting view shipped with Oracle E-Business Suite that exposes batch-level processing metadata for ISIR (Institutional Student Information Record) imports originating from the U.S. Department of Education's Application Processing (AP) system. The view presents one row per ISIR batch processed through the institution's financial aid pipeline, capturing identifiers, counts, and audit attributes used by financial aid administrators to monitor inbound student aid records. In EBS 12.1.1 and 12.2.2 the object resides within the IGF – Financial Aid product family, a module that Oracle has classified as obsolete, meaning it is retained for historical reporting and upgrade continuity rather than active development or new implementations.

The view's principal role is multi-org reporting and integration. It presents batch data filtered by the current operating unit, allowing institutions to report on ISIR processing activity within the correct organization context. Because ISIR batches often feed downstream eligibility, packaging, and disbursement processes, this view serves as a lightweight summary layer over the underlying transaction table without requiring callers to manage multi-org predicates manually.

Underlying Base Objects

The view is defined over IGF_AP_ISIR_BATCHES_ALL, the multi-organization base table that stores the authoritative batch rows. The view applies a row-level organization filter drawn from the session's CLIENT_INFO value:

• Filtering logic: The ROWID of the base table is selected alongside all business columns, with a WHERE clause comparing NVL(ORG_ID, -99) to the operating unit derived from USERENV('CLIENT_INFO').
• Session dependence: Because the predicate depends on CLIENT_INFO, queries must be executed from a session where the Multi-Org initialization has set the correct org context (typically via FND_GLOBAL or the standard EBS forms/ concurrent manager setup).
• Documentation caveat: ETRM metadata for 12.2.2 lists no separately documented base objects; IGF_AP_ISIR_BATCHES_ALL is inferred from the view text itself.

In practice, administrators should expect the ALL-suffixed table and its synonym/table structure to be the true maintenance point, with the view providing the filtered presentation layer.

Key Columns

• BATCH_NUMBER – Identifier of the ISIR batch as received or created.
• BATCH_YEAR – The award/processing year to which the batch belongs; the column surfaced by the "batch_year" search and central to year-over-year aid reporting.
• BATCH_TYPE – Classification of the batch (e.g., original, correction, or subsequent ISIR submissions).
• BATCH_COUNT – Number of records expected in the batch.
• TRAN_SOURCE_SITE – Origin site of the transmission.
• STUD_REC_COUNT – Successfully loaded student records.
• ERR_REC_COUNT – Records rejected during load.
• NOT_ON_DB_COUNT – Records not matched to existing student/DB records.
• BATCH_CREATION_DATE – Date the batch was created at source.
• CREATION_DATE, CREATED_BY, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard audit columns; LAST_UPDATE_LOGIN is populated on updates only.
• ORG_ID – Operating unit identifier; the multi-org discriminator.
• ROW_ID – ROWID of the underlying base table row, useful for joins or row identification.

Common Use Cases and Queries

Typical scenarios include monitoring ISIR load health, reconciling expected versus loaded counts, and reporting batch activity by award year.

List batches for a given year:

SELECT batch_number, batch_year, batch_type, stud_rec_count, err_rec_count
FROM   igf_ap_isir_batches
WHERE  batch_year = '2023'
ORDER  BY batch_creation_date DESC;

Identify batches with load errors:

SELECT batch_number, batch_year, err_rec_count, not_on_db_count
FROM   igf_ap_isir_batches
WHERE  err_rec_count > 0 OR not_on_db_count > 0;

Summarize batch counts by type and year:

SELECT batch_year, batch_type, COUNT(*) batches, SUM(batch_count) total_records
FROM   igf_ap_isir_batches
GROUP  BY batch_year, batch_type;

Because the view enforces operating unit security through CLIENT_INFO, these queries return only batches visible to the initialized organization. Analysts should therefore confirm org context before relying on totals, and should note that the obsolescence of the IGF Financial Aid module means ongoing support and future compatibility are limited.