Results for “date_run”

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

Overview

The IGF_AP_REVIEW_DET_V view is a seeded database object in the Oracle E-Business Suite Financial Aid (IGF) product, owned by the APPS schema. Its purpose is to present a consolidated list of person-match records that are pending staff review during the financial aid need-analysis and ISIR/CSS profile processing cycle. In the ETRM metadata for 12.1.1 and 12.2.2 the object is recorded with a status of VALID and its view text is fully documented, allowing administrators and developers to understand its exact definition without reverse engineering.

The view is a UNION of two independent queries. The first half joins IGF_AP_PERSON_MATCH to IGF_AP_ISIR_INTRFACE for records flagged RECORD_TYPE = 'ISIR'; the second half joins IGF_AP_PERSON_MATCH to IGF_AP_CSS_INTERFACE for records flagged RECORD_TYPE = 'PROFILE'. Both branches restrict output to RECORD_STATUS = 'REVIEW', so the view intentionally surfaces only records that require human intervention. Because it abstracts two source systems behind one uniform column list, downstream reports and concurrent programs can treat ISIR and CSS profile reviews identically.

As a reporting and integration object, the view is typically consumed by Financial Aid staff inquiries, exception dashboards, and any custom extract that must enumerate unresolved matches. It exposes no DML; it is read-only by definition.

Underlying Base Objects

The documented view text references three base tables, all in the APPS schema:

• IGF_AP_PERSON_MATCH (PM) — the driving table. It holds one row per attempted match between an applicant and a person record, carrying SI_ID, CSS_ID, RECORD_STATUS, RECORD_TYPE, DATE_RUN, and calendar identifiers.
• IGF_AP_ISIR_INTRFACE (SI) — the staging interface for ISIR (Institutional Student Information Record) data received from the federal processor; contributes CURRENT_SSN, name, and SI_ID.
• IGF_AP_CSS_INTERFACE (CI) — the staging interface for CSS Profile data; contributes SOCIAL_SECURITY_NUMBER, name, and CSS_ID.

The join predicates are PM.SI_ID = SI.SI_ID and PM.CSS_ID = CI.CSS_ID respectively. No additional documented referenced base objects exist beyond these three, and the UNION (not UNION ALL) implies duplicate elimination across the two branches.

Key Columns

• SSN — the applicant's Social Security Number, sourced from SI.CURRENT_SSN for ISIR rows and CI.SOCIAL_SECURITY_NUMBER for CSS rows.
• SI_ID — the identifier of the originating interface record, populated with SI.SI_ID or CI.CSS_ID; the alias name normalises the two source IDs into a single column.
• APM_ID — primary identifier of the person-match row in IGF_AP_PERSON_MATCH; the key used to navigate to the review transaction.
• STUDENT_NAME — concatenation of last name, comma, and first name from the respective interface table.
• DATE_RUN — the date the matching process produced or last processed the row.
• CI_SEQUENCE_NUMBER and CI_CAL_TYPE — the sequence and calendar type/period identifying the aid cycle against which the record was run.
• RECORD_TYPE — discriminates between 'ISIR' and 'PROFILE' source records, and effectively identifies which branch produced the row.

Common Use Cases and Queries

Typical scenarios include producing a worklist for financial aid officers resolving ambiguous applicant matches, reconciling staging interface records awaiting review, and driving automated notifications when unresolved matches exceed a threshold.

• Listing all pending reviews with cycle information returned by CI_CAL_TYPE.
• Counting outstanding reviews by RECORD_TYPE to balance ISIR against CSS workload.
• Extracting SSN and names for a reviewer-facing spreadsheet.

A representative query:

SELECT record_type, student_name, ssn, date_run, ci_cal_type, apm_id
FROM apps.igf_ap_review_det_v
WHERE date_run >= :p_from_date
ORDER BY date_run, student_name;

For cycle-specific counts:

SELECT record_type, ci_cal_type, COUNT(*)
FROM apps.igf_ap_review_det_v
GROUP BY record_type, ci_cal_type;

All such queries should be run with the APPS schema or a synonym enabling read access to the underlying IGF interface tables.