Results for “igf_ap_isir_corr”

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

Overview

IGF_AP_ISIR_CORR is an Oracle E-Business Suite self-service view owned by the APPS schema and registered as VALID in both EBS 12.1.1 and 12.2.2, where it is catalogued under the IGF - Financial Aid product family. The object exposes student ISIR (Institutional Student Information Record) correction data captured for financial aid processing. Conceptually it is a secured, organization-striped wrapper placed over the underlying correction table, presenting one row per SAR field correction alongside its original and corrected values.

Its principal architectural role is to enforce Multi-Org Access Control at query time. Rather than exposing the base table directly to forms, concurrent programs, or ad hoc reporting, EBS directs access through this view, which filters rows by the operating unit derived from the session's CLIENT_INFO context. This means a query executed in one operating unit returns only corrections belonging to that unit, satisfying the row-level security model expected by Financial Aid self-service pages and by seeded reports. The view is a read-only projection; DML against ISIR correction data is performed against the base table, not through IGF_AP_ISIR_CORR.

Underlying Base Objects

The view is defined over the table IGF_AP_ISIR_CORR_ALL, the "_ALL" table that physically stores correction rows for every operating unit. No other base objects are documented in the ETRM metadata; specifically, the definition does not join to ISIR master, person, or calendar tables, so all descriptive context for a correction must be obtained by joining outward from this view.

The defining predicate compares the ORG_ID of IGF_AP_ISIR_CORR_ALL with the operating unit parsed from USERENV('CLIENT_INFO'). The expression takes the first ten bytes of CLIENT_INFO, converting to a number, and substitutes -99 when the context is blank or the first character is a space. The same NVL/DECODE logic is applied to both sides of the equality, so ORG_ID values of NULL and -99 are treated as equivalent. The net effect is that rows are visible only when their organization matches the current session context, which is how the "_ALL" table is partitioned logically across operating units.

Key Columns

• ROWID — the physical row identifier of the underlying correction record, useful for direct lookups against the base table.
• ISIRC_ID — the primary key of the individual correction row; use this as the join key when relating corrections to other ISIR data.
• ISIR_ID — foreign reference to the parent ISIR transaction to which the correction belongs.
• CI_SEQUENCE_NUMBER, CI_CAL_TYPE — sequence number and calendar type identifying the ISIR cycle or aid year context in which the correction was received.
• SAR_FIELD_NUMBER — the SAR field position being corrected, mapping the correction to the corresponding element on the student's ISIR.
• ORIGINAL_VALUE, CORRECTED_VALUE — the value as originally reported and the value the correction substitutes, enabling side-by-side audit of the change.
• CORRECTION_STATUS — processing state of the correction, used to identify pending, applied, or rejected corrections.
• BATCH_ID — the batch in which the correction was loaded or submitted, supporting reconciliation of inbound correction files.
• ORG_ID — the operating unit that governs row visibility through the view's security predicate.
• WHO columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN provide standard audit trail information.
• Concurrent request columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE identify the concurrent program that created or last processed the row.

Common Use Cases and Queries

The view is typically used to audit ISIR correction activity for an operating unit, to trace which SAR fields were amended and what the original values were, and to reconcile corrections processed by inbound batch loads. The following query lists corrections with their status and the original versus corrected values:

SELECT isirc_id, isir_id, ci_cal_type, ci_sequence_number,
       sar_field_number, original_value, corrected_value, correction_status
FROM   igf_ap_isir_corr
WHERE  correction_status = 'P'
ORDER BY isir_id, sar_field_number;

To identify corrections produced by a specific concurrent process, filter on the request attribution columns:

SELECT isirc_id, isir_id, batch_id, sar_field_number, corrected_value
FROM   igf_ap_isir_corr
WHERE  request_id = :request_id;

Because the view carries only correction attributes, reporting that requires student or aid-year descriptions must join to the ISIR and person entities using ISIR_ID and the calendar identifiers. Practitioners should also note that successful results depend entirely on a correctly initialized CLIENT_INFO operating unit context; queries run without that context fall back to -99 and may return no rows or the default-organization set.