Results for “igs_as_suah_load_v”

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

Overview

IGS_AS_SUAH_LOAD_V is a PL/SQL-backed Oracle EBS view owned by the APPS schema within the IGS (Student System) product family. It is delivered with a status of VALID and is documented in the ETRM reference for EBS 12.1.1 and 12.2.2. The view is designed to create effective student unit attempt history records, specifically to accommodate back-dating of enrollment and discontinuation dates.

Institutions frequently need to record a student's unit attempt history after the fact—for example, when a discontinuation is reported late or an enrollment is retroactively corrected. Rather than forcing a user to manipulate effective-dated rows directly, this view presents a consolidated, function-driven projection that resolves what the "load" (assessment) treatment should be for a given unit attempt history record. It combines person, course, unit, calendar, and status attributes with derived assessment indicators, making it suitable for downstream reporting, integration loads, and internal processing that must reconstruct or validate effective-dated unit attempt history.

Because the view calls several IGS package functions, it is an active calculation surface rather than a simple read-only join. Consumers should treat it as a computational view whose results depend on current calendar, enrollment, and fee-assessment configuration data.

Underlying Base Objects

The view text references the following objects: SUAEHV (student unit attempt history), SUAS (student unit attempt status), CI (calendar instance), and SCA (course version/attempt context), together with the PL/SQL packages IGS_EN_PRC_LOAD, IGS_EN_GEN_014, IGS_PS_GEN_006, and IGS_EN_GEN_014's ENRS_CLC_SUA_CP routine. ETRM documentation lists no separately documented base objects for this view, so the relationships must be inferred from the view definition: SUAEHV supplies the effective-dated attempt history rows, SUAS supplies fee-assessment indicators, CI supplies the load calendar type and sequence, and SCA supplies the version number used in the EFTSUT calculation. The functions then evaluate whether assessment applies and return the corresponding effective full-time student unit value or credit point value.

Key Columns

• PERSON_ID, COURSE_CD, UNIT_CD, VERSION_NUMBER – identify the student, course, and unit attempt being evaluated.
• CAL_TYPE, CI_SEQUENCE_NUMBER – the calendar and calendar instance the attempt belongs to.
• EFFECTIVE_START_DT, EFFECTIVE_END_DT – effective dating of the history row, central to back-dating.
• UNIT_ATTEMPT_STATUS, ADMINISTRATIVE_UNIT_STATUS, NO_ASSESSMENT_IND – status flags that feed ENRP_GET_LOAD_APPLY to determine whether load applies.
• ENROLLED_DT, DISCONTINUED_DT – the backdated enrollment and discontinuation dates.
• LOAD_CAL_TYPE, LOAD_CI_SEQUENCE_NUMBER – the calendar instance used for load assessment.
• FEE_ASS_IND – fee-assessment indicator from SUAS.
• Derived load/eFTSUL columns – computed via IGS_EN_GEN_014.ENRS_CLC_SUA_EFTSUT and ENRS_CLC_SUA_CP, returning either the effective full-time student unit load or credit points, and zero when assessment does not apply.
• Audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) – standard EBS who-columns.

Common Use Cases and Queries

Typical scenarios include reconciling load after a late discontinuation, verifying effective full-time status for a backdated period, and feeding external reporting extracts.

SELECT person_id, unit_cd, cal_type, ci_sequence_number,
       unit_attempt_status, enrolled_dt, discontinued_dt
FROM   apps.igs_as_suah_load_v
WHERE  person_id = :p_person_id
AND    cal_type  = :p_cal_type;

To inspect the calculated load result for assessment-applicable attempts:

SELECT person_id, course_cd, unit_cd,
       load_cal_type, load_ci_sequence_number
FROM   apps.igs_as_suah_load_v
WHERE  fee_ass_ind = 'Y'
AND    discontinued_dt IS NOT NULL;

Because the view invokes PL/SQL functions, queries should be restricted by person, calendar, or date range to avoid full scans and per-row function execution across large volumes.