Search Results check_term_exists




Overview
Explore in AI Chat

Overview

IGS_EN_SPA_TERMS_API is a PL/SQL application programming interface owned by the APPS schema and classified as a public API within the Oracle Student System (formerly Oracle iLearning/Student Administration) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. The package encapsulates the business logic governing Student Program Attempt (SPA) term-level attributes — the enrollment and registration characteristics that a student carries for a specific program within a specific academic term. These attributes include attendance type, attendance mode, location, and related descriptive values drawn from the institutional reference data maintained in the Student System.

The central purpose of the package is to expose a stable, callable interface that other application modules and custom extensions can use to retrieve and validate SPA term data without directly querying the underlying base tables. The API is heavily reused: ETRM metadata records that it is referenced by 23 other packages, indicating it functions as a foundational dependency for term-related processing across enrollment, progression, and program administration flows.

The package maintains two package-level global variables, g_spa_term_cal_type and g_spa_term_sequence_number, which are typed against the CAL_TYPE and SEQUENCE_NUMBER columns of IGS_CA_INST, together with a record variable EN_SPAT_REC_TYPE declared against the IGS_EN_SPA_TERMS%ROWTYPE. The two SET_ procedures allow callers to populate these globals so that subsequent lookups default to the caller-supplied term context.

Key Procedures and Functions

The documented interface comprises 26 procedures and functions. Two updater procedures set the package-level term context:

The remaining members are retrieval and validation functions. Attribute getters return specific SPA term characteristics keyed on person, program, term calendar type, and term sequence: GET_SPAT_ATT_TYPE and GET_SPAT_ATT_TYPE_DESC (attendance type and its description); GET_SPAT_ATT_MODE and GET_SPAT_ATT_MODE_DESC (attendance mode and its description); GET_SPAT_LOCATION and GET_SPAT_LOCATION_DESC (location and its description); GET_SPAT_COO_ID (the country of origin identifier); GET_SPAT_PROGRAM_VERSION; GET_SPAT_ACAD_CAL_TYPE; GET_SPAT_KEY_PROG_FLAG; GET_SPAT_FEE_CAT; GET_SPAT_CLASS_STANDING; and GET_SPAT_PRIMARY_PRG. Term-sequencing helpers GET_CURR_TERM, GET_PREV_TERM, and GET_NEXT_TERM resolve the current, preceding, and following terms respectively. Validation routines VALIDATE_TERMS and CHECK_TERM_EXISTS confirm that a term context is valid and that a term record exists before downstream processing proceeds.

The user search term "get_miss_char" does not correspond to any documented member of this package; the closest documented functions are the GET_SPAT_* family listed above.

Tables Accessed

The package reads and writes the following base tables through APPS synonyms:

  • IGS_EN_SPA_TERMS — the primary entity table holding Student Program Attempt attributes per term; source of most EN_SPAT_* values.
  • IGS_CA_INST_REL — calendar instance relationships used to derive predecessor and successor terms for GET_PREV_TERM and GET_NEXT_TERM.
  • IGS_CA_STAT — calendar instance statuses, used to filter active versus inactive calendar instances.
  • IGS_CA_TYPE — calendar type definitions backing the calendar type validation and descriptor lookups.
  • IGS_EN_PLAN_UNITS — program plan unit data supporting program version, fee category, and class standing resolution.

Usage Notes

IGS_EN_SPA_TERMS_API is typically invoked from Oracle Forms-based Student System windows during student program and enrollment maintenance, from concurrent programs that process term-based enrollment or progression data, and from custom PL/SQL extensions requiring validated SPA term attributes. Callers should first invoke the SET_ procedures (or pass explicit term parameters where supported) to establish context, then call the appropriate getter or validation function. Because the package is referenced by 23 dependent packages, changes to its behavior or signatures can propagate widely; extensions should treat it as a read-oriented API and avoid bypassing its validation logic with direct table access.