Search Results appl_submit_date

Overview

IGS_SS_ADM_APPL is an Oracle E-Business Suite view owned by the APPS schema and registered under the FND Design Data object IGS.IGS_SS_ADM_APPL. In the Oracle Student System (formerly Student Systems / OSS) data model, it presents admission applications that were submitted through an online (self-service) channel. The view is classified in the ETRM metadata as a multi-org view, meaning that queries issued against it are automatically filtered to the operating unit of the current session and exclude rows belonging to other operating units.

Because it is a view rather than a base table, IGS_SS_ADM_APPL is not the object into which self-service admission data is written; it is a read-oriented projection intended for inquiry, reporting, and integration. It carries an ORG_ID column that supports the multi-org security predicate, together with the standard WHO audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) that allow change tracking in downstream extracts.

Underlying Base Objects

The ETRM documentation excerpt provided for this object does not enumerate the base tables over which the view is defined; the "Referenced base objects" section is recorded as none documented. The view metadata does, however, expose the full column list and its query text is described as available for inspection in the ETRM Viewer.

In practice, the self-service admission application view is built over the Student System admission application base entities and the associated person, calendar, and application-source tables. The multi-org ORG_ID suggests a dependency on the operating unit–aware admission application table family, and the presence of PERSON_ID, API_PERSON_ID, and RESID_STAT_ID indicates joins into the person and residency entities. Because the documented dependency information is incomplete, the definitive mapping should be confirmed by reading the view source text in the ETRM tool or by querying ALL_DEPENDENCIES for the object in the target instance rather than relying on the abbreviated metadata.

Key Columns

• ORG_ID (NUMBER 15) — Operating unit discriminator that enforces the multi-org filter.
• SS_ADM_APPL_ID (NUMBER 15) — Primary identifier of the self-service admission application record.
• PERSON_ID / API_PERSON_ID — Person identifiers linking the applicant to the person record.
• APPL_STATUS, STATUS, ENTRY_STATUS, ENTRY_LEVEL — Application and entry processing state indicators.
• APPL_SUBMIT_DATE (DATE) — Date the online application was submitted.
• ADMISSION_CAT, ADM_CAL_TYPE, ADM_CAL_SEQ_NUMBER, ACAD_CAL_TYPE, ACAD_CAL_SEQ_NUMBER — Admission and academic calendar context for the application.
• VISA_TYPE, VISA_NUMBER, VISA_ISSUE_DATE, VISA_EXPIRY_DT, ENTRY_DATE — Visa and entry detail, including the visa expiry date sought in this search.
• PASSPORT_NUMBER1, PASSPORT_EXPIRY_DATE1 — Passport identifiers and expiry.
• ALIAS_SURNAME, ALIAS_GIVEN_NAMES, ALIAS_TITLE — Alternate name data supplied by the applicant.
• RESID_STAT_ID, ETHNIC_ORIGIN, MARITAL_STATUS, COUNTRY_CD1/2, PLACE_OF_BIRTH — Residency and personal characteristics.
• ACT_NOTE_TEXT, WE_NOTE_TEXT — Advisory and work-experience notes associated with the application.

Common Use Cases and Queries

Typical uses include tracking visa documentation for international applicants, monitoring online submission volumes by admission calendar, and feeding applicant demographics into downstream reporting. A common query retrieves applicants whose visas are due to expire within a given window:

• SELECT ss_adm_appl_id, person_id, visa_type, visa_number, visa_issue_date, visa_expiry_dt FROM apps.igs_ss_adm_appl WHERE visa_expiry_dt BETWEEN SYSDATE AND SYSDATE + 90;
• SELECT adm_cal_type, adm_cal_seq_number, COUNT(*) FROM apps.igs_ss_adm_appl WHERE appl_status = 'SUBMITTED' GROUP BY adm_cal_type, adm_cal_seq_number;
• SELECT person_id, passport_number1, passport_expiry_date1 FROM apps.igs_ss_adm_appl WHERE passport_expiry_date1 < SYSDATE;

Because multi-org filtering is applied automatically, callers should set the operating unit context (for example, via FND_CLIENT_INFO or MO_GLOBAL) before querying; rows for other operating units will not be returned.