Results for “igs_ad_imp_003”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGS_AD_IMP_003 is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. The IGS prefix designates the Student System (formerly Oracle Student System, now part of the Oracle Higher Education product family), and the AD component identifies the Admissions module. The _IMP_ segment indicates that this is an inbound interface package, one of a numbered family of routines used to load legacy or external data into the admissions staging and base tables.

The package supports the conversion and ongoing integration of applicant admission data, including academic interests, application intents, applicant personal status records, application fees, sponsorship and other-institution details, and split interests and talents. Its classification in the ETRM repository is OTHER, meaning it is not exposed as a public or user-facing API in the same manner as a formal business API. Its status is VALID, and it depends only on the SYS.STANDARD package, confirming that it is a self-contained PL/SQL unit with no reliance on other application logic packages.

In EBS 12.1.1 and 12.2.2 the package resides in the APPS schema and is executed in the context of the Student System responsibility, typically under the credentials of a module-specific Oracle user.

Key Procedures and Functions

The ETRM metadata documents seven procedures within the package. Each is described below by name and purpose.

• PRC_ACAD_INT — Processes academic interest records, loading and validating them from the interface table into the base academic interest table.
• PRC_APCNT_INDT — Handles applicant intent data, reconciling interface rows against the applicant intent base records.
• PRC_APCNT_OTH_INST_APLD — Processes other-institution information associated with an applicant, including institutions previously applied to or attended.
• PRC_APCNT_SPL_INTRST — Loads split interest data for applicants, moving staged rows into the split interests base table.
• PRC_APCNT_SPL_TAL — Loads split talent data for applicants, moving staged rows into the split talents base table.
• PRC_PE_PERSSTAT_DETAILS — Processes person status detail records, transferring applicant personal status data from the interface to the base table.
• PRC_APPL_FEES — Processes application fee records, validating and inserting them into the application fee interface and base structures.

No parameter lists are asserted here; callers should obtain exact signatures from the package specification in the database.

Tables Accessed

The package reads and writes a matching set of interface and base tables accessed through APPS synonyms.

• Interface tables: IGS_AD_ACADINT_INT, IGS_AD_APPINT_INT, IGS_AD_APP_REQ, IGS_AD_FEE_INT, IGS_AD_OTHINST_INT, IGS_AD_PERSTMT_INT, IGS_AD_SPLINT_INT, and IGS_AD_SPLTAL_INT hold staging rows awaiting validation and transfer.
• Base tables: IGS_AD_ACAD_INTEREST, IGS_AD_APP_INTENT, IGS_AD_APPL_PERSTAT, IGS_AD_OTHER_INST, IGS_AD_SPL_INTERESTS, IGS_AD_SPL_TALENTS, and IGS_OR_INST_STAT receive the validated admissions data.

The pattern is the standard interface-to-base model: rows enter through the _INT tables, are validated, and are written to the corresponding permanent admissions entities. IGS_OR_INST_STAT provides institution status reference data used during validation.

Usage Notes

IGS_AD_IMP_003 is normally invoked during data conversion or periodic data load cycles. In a typical implementation, a concurrent program or a controlling driver routine calls each documented procedure in sequence after external data has been loaded into the interface tables. The package is not designed for interactive use from a form; it is a batch-processing component.

The dependency information shows that the package is referenced by IGS_AD_IMP_003 itself (internal calls) and by IGS_AD_IMP_015, indicating that IGS_AD_IMP_015 invokes routines in this package as part of a broader load sequence. Only one other package references it, so it sits at a relatively low level in the admissions interface call hierarchy.

Custom code should call the procedures only after populating the corresponding interface tables and should respect the sequence expected by the controlling process. Because the package depends solely on SYS.STANDARD, it can be invoked without additional application package dependencies, but it should never be modified directly; extensions belong in custom wrapper packages.