Search Results drop_selected_units
Overview
IGS_SS_EN_WRAPPERS is a PL/SQL package owned by the APPS schema within the Oracle E-Business Suite Student System (formerly Oracle Student System, now part of Oracle Higher Education). Its name and dependency footprint place it in the enrollment processing layer of the product, where it functions as a self-service (SS) wrapper that mediates between the enrollment APIs and the underlying student unit attempt, catalog, and offering tables. The object is documented as VALID in the ETRM repository and is classified as OTHER rather than as a public API.
The package encapsulates the business logic required to validate, insert, modify, and drop student unit attempts in a self-service or web-registration context. Rather than exposing the base enrollment tables directly, callers — chiefly the IGS_EN_* family of APIs and concurrent programs — invoke wrapper procedures here so that eligibility checks, plan status updates, fee assessment, workflow transitions, and worksheet manipulation are performed consistently across channels.
Key Procedures and Functions
The ETRM 12.1.1 metadata documents approximately thirty procedures and functions. They cluster into several functional groups:
- Enrollment and cart processing: ENROLL_CART_UNIT, GET_CART_DETAILS, INSERT_INTO_ENR_WORKSHEET, and VALIDATE_ENROLL_VALIDATE manage the shopping-cart style workflow — retrieving cart contents, validating whether a selected unit may be enrolled, and persisting the resulting student unit attempt record.
- Validation: VALIDATE_PROG_PRO, VALIDATE_UNIT_STEPS, VALIDATE_UPD_CP, and ENRP_CHK_DEL_SUB_UNITS perform program-level, unit-step, update, and sub-unit deletion checks before a transaction is committed.
- Unit drop and transfer: DROP_SELECTED_UNITS, DROP_ALL_WORKFLOW, DROP_NOTIF_VARIABLE, and BLK_DROP_UNITS handle the removal of enrolled units, including bulk or block drops.
- Workflow and status: TRANSFER_WORKFLOW, UPDATE_SPA_PLAN_STS, GET_UNIT_INT_STATUS, and ENRP_SWITCH_CORE_SECTION manage progression between workflow states, plan status updates, and internal unit status retrieval.
- Person and eligibility: ENRP_SS_VAL_PERSON_STEP, GET_PERSON_TYPE_BY_RANK, and ENRP_SS_VAL_PERSON_STEP support person-level validation and ranking during self-service enrollment.
- Fees and miscellaneous: CALL_FEE_ASS invokes fee assessment for the affected enrollment, while DROP_NOTIF_VARIABLE and related routines manage notification variables.
Tables Accessed
The package reads and writes a broad set of enrollment and student records through APPS synonyms. Core student data resides in IGS_EN_SU_ATTEMPT_ALL and IGS_EN_STDNT_PS_ATT_ALL, which store unit attempts and program-of-study attempts respectively. Catalog and offering structures are accessed through IGS_EN_CAT_PRC_DTL, IGS_EN_PLAN_UNITS, and IGS_PS_UNIT_OFR_OPT (referenced in the dependency listing). Calendar and instance data come from IGS_CA_INST and IGS_CA_INST_ALL, with relationships in IGS_CA_INST_REL and type definitions in IGS_CA_TYPE.
Eligibility and override logic uses IGS_EN_ELGB_OVR_STEP, IGS_EN_METHOD_TYPE, and IGS_EN_SPL_PERM. Plan and terms data are held in IGS_EN_SPA_TERMS and IGS_EN_PLAN_UNITS. Notification requirements are read from IGS_EN_STATUS_MAIL_REQ_S and FND_NEW_MESSAGES, while user and party context is drawn from FND_USER and HZ_PARTIES.
Usage Notes
IGS_SS_EN_WRAPPERS is not intended as a public API. It is referenced by sixteen other packages, including IGS_EN_ADD_UNITS_API, IGS_EN_DROP_UNITS_API, IGS_EN_SU_ATTEMPT_PKG, IGS_EN_VAL_SUA, IGS_EN_PLAN_UTILS, IGS_EN_IVR_PUB, IGS_EN_OFR_WLST_OPT, and multiple IGS_EN_GEN_* and IGS_PR_GEN_004 programs. This indicates that the package is invoked from self-service enrollment forms, batch enrollment generation programs, IVR interfaces, and the standard add/drop unit APIs.
Developers extending enrollment functionality should call the higher-level IGS_EN_ADD_UNITS_API or IGS_EN_DROP_UNITS_API rather than IGS_SS_EN_WRAPPERS directly, since the wrapper assumes session and context state established by those callers. Because the package touches core student attempt tables, any customization must respect existing validation, workflow, and fee-assessment sequencing to avoid inconsistent enrollment records. As with all APPS-owned packages, modifications should be confined to supported extension points.