Search Results inq_acad_id




Overview
Explore in AI Chat

Overview

The IGS_SS_INQ_ACAD table is a core data structure within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2, specifically for the Oracle Student Systems (OSS) module under the IGS schema. Its primary function is to stage academic history and interest data captured from prospective students (inquiries) via self-service interfaces. The table acts as a temporary holding area for academic information submitted during the inquiry or application process before this data is validated and potentially integrated into the system's formal student records. The provided ETRM metadata explicitly notes the table's purpose as "Holds Self Service Staging Academic Interest" and marks it as "Obsolete," indicating it may have been superseded by a newer data model in later application versions or patches, though it remains a valid object in the specified releases.

Key Information Stored

The table stores a comprehensive set of academic data points for an inquiry. The INQ_ACAD_ID column serves as the unique primary key for each academic record, as enforced by the IGS_SS_INQ_ACAD_U1 index. The INQ_PERSON_ID links the academic data to a specific prospective student record in the broader inquiry system. Key academic details include the institution code (INSTITUTION_CD), attendance dates (START_DATE, END_DATE), and program information (PROGRAM_TYPE_EARNED, COURSE_MAJOR). A significant portion of the table is dedicated to self-reported metrics, such as GPA (SELFREP_INST_GPA), class rank (SELFREP_RANK_IN_CLASS), and earned credits (SELFREP_TOTAL_CP_EARNED), which are typically subject to verification. The table also includes standard Oracle EBS WHO columns (e.g., CREATED_BY, LAST_UPDATE_DATE) for auditing and columns for tracking concurrent program requests.

Common Use Cases and Queries

This table is central to processing and reviewing academic data submitted by prospective students. Common operational and reporting scenarios include validating self-reported information against official transcripts, generating lists of inquiries from specific prior institutions, or analyzing the academic backgrounds of applicant pools. A typical query to retrieve all academic history for a specific inquiry person would leverage the INQ_PERSON_ID foreign key. For reporting on inquiries from a particular institution with planned completion dates in the future, a SQL pattern would join the academic data to the main inquiry person table and filter accordingly.

  • Sample Query: SELECT i.INQ_ACAD_ID, i.INSTITUTION_CD, i.PROGRAM_TYPE_EARNED, i.SELFREP_INST_GPA FROM IGS.IGS_SS_INQ_ACAD i WHERE i.INQ_PERSON_ID = :person_id ORDER BY i.END_DATE DESC;
  • Reporting Use Case: Aggregating the count of inquiries by their reported prior major (COURSE_MAJOR) to inform recruitment marketing strategies for specific academic programs.

Related Objects

The primary relationship for the IGS_SS_INQ_ACAD table is through the INQ_PERSON_ID column, which logically references a master inquiry person table, likely named IGS_SS_INQ_PERSON or similar, within the IGS schema. The unique index IGS_SS_INQ_ACAD_U1 is directly dependent on this table to enforce primary key integrity on the INQ_ACAD_ID column. Given its staging nature and obsolete status, it may be referenced by older interfaces, concurrent programs, or upgrade scripts designed to migrate this legacy data to a successor table. Program-related WHO columns (REQUEST_ID, PROGRAM_ID) suggest integration with specific concurrent request workflows for data processing.