Results for “oss_fund_code”

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

Overview

The view IGSFV_UK_PRG_OFR_OPT_UNIT_SETS belongs to the IGS – Student System product family within Oracle E-Business Suite, a module now classified as obsolete in the ETRM reference for releases 12.1.1 and 12.2.2. Its documented purpose is to expose a full view of Program Offering Option Unit Set HESA (Higher Education Statistics Agency) details. In practical terms, the object flattens the relationship between a program offering option and the unit set attached to it, enriching the base identifiers with the descriptive and coded values required for UK statutory higher-education reporting.

As a "full view" rather than a maintenance or transactional entity, it serves reporting and integration consumers. Downstream extracts, HESA returns, and institutional data warehouses can read a single row per program-offering-option/unit-set combination without having to join the numerous code and description tables themselves. The ETRM note records that the view is not implemented in the current database, so its primary value is as a documented interface contract describing the shape of the data the obsolete product was expected to deliver.

Underlying Base Objects

ETRM records no documented base objects for this view, and the owner field is blank in the supplied metadata. The embedded view text, however, makes the driving source explicit: the alias POO resolves to the program offering option record that carries the HESA identifier HESA_POOUS_ID and the unit-set columns. The remaining sources are joined or referenced through correlated scalar subqueries rather than declared in a FROM clause, which is why the ETRM base-object list is empty.

• POO – the primary program offering option / unit-set driver, supplying program code, version, calendar type, location, attendance, unit set, funding level, fundability and fee band.
• IGS_AD_LOCATION_ALL – resolves LOCATION_CD to a location description.
• IGS_EN_ATD_MODE_ALL and IGS_EN_ATD_TYPE_ALL – resolve attendance mode and attendance type descriptions.
• IGS_HE_CODE_VALUES – the HESA code-value lookup, used for OSS_LOCSDY, OSS_FUNDLEV, OSS_FUND_CODE and OSS_FEEBAND descriptions.
• IGS_FI_FUND_SRC_ALL – resolves the major source of funding description.

Key Columns

The projection follows a consistent pattern of identifier, abbreviated code and descriptive text, which simplifies report formatting. The PROGRAM_* columns carry title, short title, abbreviation and version; CALENDAR_TYPE, CALENDAR_DESC and CALENDAR_ABBREVIATION describe the reporting calendar. LOCATION_CODE and LOCATION_DESC identify where the offering is delivered, while attendance is surfaced through ATTENDANCE_MODE/ATTENDANCE_TYPE and their _DESC counterparts.

The unit-set identity is expressed by UNIT_SET_CODE, UNIT_SET_TITLE, UNIT_SET_SHORT_TITLE, UNIT_SET_ABBREVIATION and US_VERSION_NUMBER. HESA-specific attributes include LOCATION_OF_STUDY and its OSS_LOCSDY description, LEVEL_APP_TO_FUNDING_COUNCIL decoded through OSS_FUNDLEV (the code type behind the user's search term oss_fundlev), FUNDABILITY_CODE via OSS_FUND_CODE, FEE_BAND via OSS_FEEBAND, and MAJOR_SOURCE_OF_FUNDING.

Common Use Cases and Queries

Typical consumption is a straight projection filtered by offering or funding attributes, for example producing a funding-level report:

SELECT PROGRAM_CODE,
       PROGRAM_TITLE,
       UNIT_SET_CODE,
       LEVEL_APP_TO_FUNDING_COUNCIL,
       LEVEL_APP_FUNDING_COUNCIL_DESC,
       FUNDABILITY_DESC,
       FEE_BAND_DESC
FROM   IGSFV_UK_PRG_OFR_OPT_UNIT_SETS
WHERE  LEVEL_APP_TO_FUNDING_COUNCIL IS NOT NULL;

Extract processes commonly select the descriptive columns only, since the view already resolves the HESA lookups, avoiding repeated joins to IGS_HE_CODE_VALUES. Reconciliation queries compare HESA_POOUS_ID values returned by the view against staging tables to detect missing or mis-coded offerings before submission. Because the view is documented as obsolete and not implemented, such queries should be validated against the customer's actual database before reliance, and any replacement should be confirmed with the current data model.