Search Results acad_cal_desc

Overview

The view APPS.IGF_GR_PELL_SETUP_V is a reporting and integration construct within the Oracle E-Business Suite Financial Aid module, specifically the Student Financial Aid (Grants) component. It presents a denormalized, employee-facing representation of Pell Grant setup records for a grant award type, joining the underlying Pell Grant configuration table to the academic calendar instance and, where applicable, to the course version definition. In Oracle EBS 12.1.1 and 12.2.2, such _V views are typically exposed to forms, OAF pages, and concurrent reports so that code values (lookups) are resolved to their descriptive meanings without requiring the calling layer to perform additional joins.

The view plays a supporting role for administrators configuring how institution-calculated Pell eligibility is derived relative to a student's enrollment activity. The user search term enr_after_tc_code maps directly to a core column of this view, indicating that the object is most relevant to enrollment-timing calculations used in Pell Grant payment and disbursement logic.

Underlying Base Objects

Although the ETRM metadata records no documented base objects, the view text itself defines the join structure explicitly. Three primary objects participate:

• IGF_GR_PELL_SETUP PELL — the driving table containing the Pell Grant setup definition rows, including enrollment timing codes, funding method, payment method, and version metadata.
• IGS_CA_INST CI — the academic calendar instance, joined on CAL_TYPE and SEQUENCE_NUMBER, supplying alternate code, start date, and end date for the calendar instance.
• IGS_PS_VER PSV — the program version, joined with an outer join ((+)) on COURSE_CD and VERSION_NUMBER, supplying the title used where a course version is referenced.

Lookup descriptions are resolved through the function IGF_AW_GEN.LOOKUP_DESC, which reads Oracle lookup types such as IGF_GR_PELL_CALC_ENR_TYPE, IGF_GR_ACAD_CAL, IGF_GR_PAYMENT_METHOD, IGF_SL_RESP_OPTIONS, and IGF_SL_FUNDING_METHODS.

Key Columns

• ROW_ID, PELL_SEQ_ID, REP_PELL_ID, PELL_ALT_EXP_MAX — identifiers and versioning attributes for the Pell setup record.
• CI_CAL_TYPE, CI_SEQUENCE_NUMBER, ALTERNATE_CODE, START_DT, END_DT — academic calendar instance context.
• ENR_BEFORE_TS_CODE, ENR_IN_MT_CODE, ENR_AFTER_TC_CODE — enrollment timing codes describing enrollment activity before the term start, in mid-term, and after the term close. Descriptions are exposed as ENR_BEFORE_TS_CODE_DESC, ENR_IN_MT_CODE_DESC, and ENR_AFTER_TC_CODE_DESC.
• PAYMENT_METHOD / PYMT_METHOD_DESC, FUNDING_METHOD, ACADEMIC_CAL / ACAD_CAL_DESC, PAYMENT_PERIODS_NUM, WK_INST_TIME_CALC_PYMT, WK_INT_TIME_PRG_DEF_YR, CR_CLK_HRS_PRDS_SCH_YR, CR_CLK_HRS_ACAD_YR — Pell calculation and disbursement parameters.
• USE_CENSUS_DTS, LOW_TUTION_FEE, ALT_COA_LIMIT — calculation flags and limits relevant to award processing.
• COURSE_CD, VERSION_NUMBER, TITLE — course version linkage and descriptive title.
• Standard audit columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

The view is typically queried to validate and report on Pell setup configuration, especially the enrollment timing behavior governed by the ENR_AFTER_TC_CODE family. A representative query to inspect all timing codes for a given calendar instance is:

SELECT PELL_SEQ_ID, CI_CAL_TYPE, CI_SEQUENCE_NUMBER, ENR_BEFORE_TS_CODE_DESC, ENR_IN_MT_CODE_DESC, ENR_AFTER_TC_CODE_DESC, FUNDING_METHOD, PAYMENT_METHOD_DESC FROM APPS.IGF_GR_PELL_SETUP_V WHERE ENR_AFTER_TC_CODE IS NOT NULL ORDER BY CI_CAL_TYPE, CI_SEQUENCE_NUMBER;

A second common pattern joins the view to award data to confirm that awards processed for a term were calculated using the intended enrollment timing rule:

SELECT v.ENR_AFTER_TC_CODE_DESC, v.PYMT_METHOD_DESC, a.AWARD_ID FROM APPS.IGF_GR_PELL_SETUP_V v, APPS.IGF_AW_AWARDS a WHERE v.CI_CAL_TYPE = a.CAL_TYPE AND v.CI_SEQUENCE_NUMBER = a.SEQUENCE_NUMBER;

Administrators also use the view to reconcile the descriptive lookup values against the underlying code values when validating setup migration or data fixes, since the view exposes both the raw code and the resolved description side by side.