Search Results def_acad_cal_type




Overview

IGS_AD_PS_APLINSTHST is an Oracle E-Business Suite 12.1.1 / 12.2.2 view owned by the APPS schema and registered as VALID within the IGS – Student System product family. In ETRM terminology the suffix "HST" denotes a historical (or instance-history) construct. The view exposes admissions application-instance history records for prospective and admitted students, providing a reporting and integration surface over the applicant's admission processing lifecycle — from document and entry-qualification status through offer, response, deferment, and outcome status.

The view is significant because it surfaces the assignment ranking columns (ASS_RANK and SECONDARY_ASS_RANK) that underpin admission selection and, by extension, the waitlist ordering used by institutions that manage competitive or quota-based admission. Users searching for "waitlist_rank" typically reach this view because the admission assessment rank columns govern the ordered position of an applicant against a nominated course, which is the functional equivalent of a waitlist position in ETRM's admissions processing model.

Underlying Base Objects

The view is defined over a single underlying entity referenced in the view text as TAB, which the Data Implementation section exposes through SELECT TAB.ROWID ROW_ID, TAB.ORG_ID, TAB.PERSON_ID, TAB.ADMISSION_APPL_NUMBER, TAB.NOMINATED_COURSE_CD, TAB.SEQUENCE_NUMBER, and the remaining admission status and ranking columns. The ETRM documented metadata lists no additional referenced base objects, so the view behaves as a projection of one principal base table (the applicant admission-instance history store) selected by ROWID and keyed by ORG_ID, PERSON_ID, ADMISSION_APPL_NUMBER, NOMINATED_COURSE_CD, and SEQUENCE_NUMBER.

Because no join or filter predicate is documented, the view can be treated as an essentially thin, denormalized projection. Developers should not assume additional lookup joins for meaning; descriptive values (for example calendar types, fee categories, funding sources) are carried as coded columns on the base record itself.

Key Columns

Common Use Cases and Queries

Reporting on applicant ranking and selection status for a nominated course is the most frequent use. A typical query returns ranks and current outcome per applicant:

  • Producing ranked applicant lists for a course offering, ordered by ASS_RANK, to model admission selection and waitlist positioning.
  • Monitoring conditional-offer satisfaction and offer-response compliance for a given admission period.
  • Feeding integration extracts where downstream systems require the applicant's assessment rank and admission outcome status.

Sample SQL:

  • SELECT a.PERSON_ID, a.ADMISSION_APPL_NUMBER, a.NOMINATED_COURSE_CD, a.SEQUENCE_NUMBER, a.ASS_RANK, a.SECONDARY_ASS_RANK, a.ADM_OUTCOME_STATUS FROM APPS.IGS_AD_PS_APLINSTHST a WHERE a.NOMINATED_COURSE_CD = :course AND a.ORG_ID = :org ORDER BY a.ASS_RANK;
  • SELECT a.PERSON_ID, a.ADMISSION_APPL_NUMBER, a.OFFER_DT, a.ADM_OFFER_RESP_STATUS, a.CNDTNL_OFFER_SATISFIED_DT FROM APPS.IGS_AD_PS_APLINSTHST a WHERE a.CNDTNL_OFFER_SATISFIED_DT IS NULL AND a.OFFER_DT IS NOT NULL;

Because the view is read-only in practice (defined over a base table by ROWID), all DML should target the base object; the view is intended for query and extraction only.