Search Results credit_value_yop2




Overview
Explore in AI Chat

Overview

The IGS_HE_POOUS view is a reporting and integration object within the Oracle E-Business Suite Student System (IGS) product family. Its formal description in the ETRM repository is "Program Offering Option Unit Set HESA Details," indicating that it exposes Higher Education Statistics Agency (HESA) regulatory attributes associated with program offering option unit sets. The view is owned by the APPS schema and carries a VALID status in both the 12.1.1 and 12.2.2 releases.

Functionally, IGS_HE_POOUS serves as a Multi-Org secured, read-only projection over the underlying IGS_HE_POOUS_ALL table. It presents the institution-specific slice of program offering option unit set records that a session is authorized to see, and it flattens the HESA statutory fields required for regulatory returns—such as credit values, level credits across years of programme (YOP1 through YOP4), fundability, fee band, and funding source—into a single queryable interface. The view is typically consumed by concurrent programs, extracts, and downstream reporting tools that assemble HESA student return data. Because it is a view rather than a table, it holds no data of its own; every column is derived from its base table at query time.

Underlying Base Objects

According to the ETRM metadata, the view is defined exclusively over the base object IGS_HE_POOUS_ALL (alias A). No other documented base objects are referenced. The view text performs a direct column projection with a ROWID-based ROW_ID alias and a Multi-Org filter.

The Multi-Org predicate is applied on ORG_ID using a pattern common to IGS secured views: it evaluates USERENV('CLIENT_INFO'), checks whether the first character is a space (which forces a NULL), otherwise extracts the leading ten characters, converts to a number, and compares the result to ORG_ID via NVL, defaulting to -99 when no organization context is set. This ensures that only records belonging to the caller's current operating unit are returned. Because the filter is enforced in the view definition, consumers cannot bypass organization security through normal querying.

Key Columns

The view exposes the full HESA-relevant column set from its base table. Identification columns include HESA_POOUS_ID (the primary identifier), COURSE_CD, CRV_VERSION_NUMBER, CAL_TYPE, LOCATION_CD, ATTENDANCE_MODE, ATTENDANCE_TYPE, UNIT_SET_CD, and US_VERSION_NUMBER. These establish the program offering option unit set context.

The regulatory credit and level attributes are central. The view exposes CREDIT_VALUE_YOP1 through CREDIT_VALUE_YOP4 and the matching LEVEL_CREDIT1 through LEVEL_CREDIT4. The column CREDIT_VALUE_YOP4, which matches the user's search term, records the credit value for the fourth year of programme. Related HESA fields include TYPE_OF_YEAR, LENG_CURRENT_YEAR, FTE_INTENSITY, FTE_CALC_TYPE, FUNDABILITY_CD, FEE_BAND, FUNDING_SOURCE, LEVEL_APPLICABLE_TO_FUNDING, and PROP_NOT_TAUGHT. Teaching period boundaries appear as TEACH_PERIOD_START_DT and TEACH_PERIOD_END_DT, while OTHER_INSTIT_TEACH1 and OTHER_INSTIT_TEACH2 capture collaborative teaching arrangements. Standard audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) are also projected, plus a synthetic ROW_ID derived from ROWID.

Common Use Cases and Queries

Typical scenarios include HESA return preparation, validation of credit values across years of programme, and reconciliation of fundability and fee band assignments per unit set. The following query retrieves credit value details for a course offering:

  • SELECT COURSE_CD, CRV_VERSION_NUMBER, UNIT_SET_CD, CREDIT_VALUE_YOP1, CREDIT_VALUE_YOP2, CREDIT_VALUE_YOP3, CREDIT_VALUE_YOP4 FROM APPS.IGS_HE_POOUS WHERE COURSE_CD = :course_cd;
  • SELECT HESA_POOUS_ID, LEVEL_CREDIT4, FUNDABILITY_CD, FEE_BAND FROM APPS.IGS_HE_POOUS WHERE CREDIT_VALUE_YOP4 IS NOT NULL;
  • SELECT COURSE_CD, COUNT(*) FROM APPS.IGS_HE_POOUS GROUP BY COURSE_CD HAVING COUNT(*) > 1;

Because the view enforces Multi-Org security internally, no additional ORG_ID predicate is required, though callers should ensure a valid organization context is initialized to avoid the -99 default, which yields no rows.