Search Results admp_val_stsfd_dt

Overview

IGS_AD_VAL_ACAI is an Oracle EBS Advanced Development (Student Systems / Admissions) validation package owned by the APPS schema. Its name reflects its role as the "Admissions Validation — ACAI" (Application Confirmation, Acceptance and Intention) routine set. The package centralizes the business rules that determine whether a prospective student's admission record satisfies institutional, regulatory, and internal criteria before an offer of admission is created, confirmed, or accepted. In the broader IGS (Student Systems) architecture, validation packages such as IGS_AD_VAL_ACAI act as the gatekeeping layer between the application data model (IGS_AD_*) and downstream processes such as offer generation, encumbrance, enrollment, and correspondence. Because it is a VALID object in both 12.1.1 and 12.2.2 installations, it is expected to be present and compilable in standard environments, though it is not documented as a public API — its classification is OTHER rather than a supported open interface.

Key Procedures and Functions

The package exposes approximately forty documented procedures and functions. The core ACAI validation routines operate on the application record and its associated confirmation/acceptance attributes:

• ADMP_VAL_ACAI_INSERT / _UPDATE / _DELETE — validate the creation, modification, and removal of the ACAI record itself.
• ADMP_VAL_ACAI_COURSE / _ENCMB / _LATE / _OPT / _US — validate course selection, encumbrance, late responses, options, and US-specific (or unit-set) conditions tied to the ACAI record.
• ADMP_VAL_ACA_SCA / _COP / _COO — validate school/campus, conditional offer particulars, and conditional offer outcome details.
• ADMP_VAL_CHG_OF_PREF — validate changes to the application preference ordering.
• CRSP_VAL_CACUS_SUB — validate the customer/subject linkage used during the confirmation process.
• ADMP_VAL_US_ENCMB — validate US-specific encumbrance rules.
• Date validators: ADMP_VAL_OFFER_DT, ADMP_VAL_OFF_RESP_DT, ADMP_VAL_ACT_RESP_DT, ADMP_VAL_STSFD_DT — enforce offer date, offer response date, actual response date, and satisfied-date rules.
• ADMP_VAL_OFFER_CNDTN / ADMP_VAL_ACPT_CNDTN — validate offer conditions and acceptance conditions respectively.

All routines are named by convention to validate a specific field or condition, returning a success/failure indicator rather than raising unhandled exceptions.

Tables Accessed

The package reads and writes through APPS synonyms of the IGS_AD_* and related tables. Documented dependencies include:

• IGS_AD_APPL_LTR, IGS_AD_APPL_STAT — application letters and application status history, consulted for current application state.
• IGS_AD_CAL_CONF, IGS_AD_OFR_RESP_STAT, IGS_AD_CNDNL_OFRSTAT — offer response status, conditional offer status, and calendar/call configuration.
• IGS_AD_CODE_CLASSES, IGS_AD_CT_HECS_PAYOP, IGS_AD_OTHER_INST, IGS_AD_OU_STAT, IGS_AD_UNIT_OU_STAT, IGS_AD_PANEL_DTLS — classification codes, HECS payment options, other institution data, organisational unit status, and panel details.
• IGS_AS_SC_ATMPT_ENR, IGS_CO_CAT, IGS_CO_CAT_MAP, IGS_EN_CAT_MAPPING — prior attempt/enrollment, category, and category-mapping data used for validation of entry criteria and encumbrance.

Usage Notes

IGS_AD_VAL_ACAI is not typically called directly by end users. It is invoked from within higher-level Admissions packages — the ETRM dependency list shows it is referenced by 29 packages including IGS_ADMAPPLICATION_PUB, IGS_AD_GEN_008/012/013/014, IGS_AD_PRC_TAC_OFFER, IGS_AD_PS_APPL_INST_PKG, IGS_AD_PS_APPL_PKG, IGS_AD_SS_APPL_UPD_PAGE, IGS_AD_IMP_OFF_RESP_DATA, IGS_PRECREATE_APPL_PUB, and various IGS_AV and IGS_EN validation packages. In practice it is triggered during offer creation, confirmation, acceptance processing, encumbrance updates, and admissions self-service (SS) page submissions. Customizations should call validation through the calling public packages rather than invoking IGS_AD_VAL_ACAI routines directly, since the package body may change between patch levels and is not a supported extension point. In 12.1.1 and 12.2.2 the object is expected to be VALID; if invalidated, dependent admissions processes will fail at runtime.