Search Results load_description




Overview

The view IGS_AS_USEC_GRADE_ENTRY_V belongs to the IGS — Student System product family within Oracle E-Business Suite. It is documented in the ETRM repository as obsolete and is flagged as not implemented in the reference database. The view is designed to expose unit section (USEC) records that are relevant to grade entry processing, joining scheduling, location, instructor, and grading schema information into a single denormalized projection.

Its role in Oracle EBS reporting and integration is to provide a consolidated read model for downstream grade-entry screens, extracts, and interface programs that require both the teaching (delivery) context and the load (teaching assignment) context of a unit offering option. Because the view exposes surrogate identifiers such as UOO_ID alongside human-readable attributes, it supports both display reporting and programmatic joins back into the underlying transactional tables.

Underlying Base Objects

The view text is defined over the following base objects:

Joins are enforced on UOO_ID, calendar type and sequence number, location code, unit code and version number, and instructor party identifier. Unit section status is filtered to OPEN, CLOSED, HOLD, or FULLWAITOK.

Key Columns

Common Use Cases and Queries

Typical scenarios include grade-entry roster preparation, instructor workload reporting keyed on load descriptions, and integration extracts feeding external grade capture systems. A representative query retrieving grade-entry context by load description is:

  • SELECT uoo_id, unit_cd, call_number, load_description, instructor_name, grading_schema_code, grd_schm_version_number FROM igs_as_usec_grade_entry_v WHERE load_description LIKE :p_load_desc;
  • SELECT unit_cd, location, title, instructor_name FROM igs_as_usec_grade_entry_v WHERE owner_org_unit_cd = :p_org AND teach_cal_type = :p_cal_type;

Because the object is documented as obsolete and not implemented in the reference database, implementations on 12.1.1 or 12.2.2 should validate its availability against the local database before relying on it, and consider substituting direct queries against the base tables where the view is absent.