Results for “adm_code_classes”

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

Overview

IGS_AD_ACT_ASSESSMENTS_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Student System (IGS) product family, specifically the Admissions (IGS_AD) module, and supports the processing of prior academic assessments and academic history data within the admissions admissions/recruitment datamart. The package is classified as an OTHER API in the ETRM repository, meaning it is not a formally published public API but is nevertheless a stable, valid database object referenced internally by Oracle's Admissions components.

The package provides the technical infrastructure that moves external assessment records — for example, test scores, prior qualifications, or externally validated academic achievements — into the Admissions interface tables and, ultimately, into the base assessment tables. It acts as the bridge between applicants' academic assessment data captured during admission and the persistent assessment, statistics, address usage, and person identification structures used by Oracle Student System.

Key Procedures and Functions

The documented metadata identifies three procedures within the package. Parameter lists are not published in the ETRM extract and should not be assumed; the descriptions below reflect documented purpose only.

• GET_BATCH_ID — Returns the batch identifier used to group a set of assessment or interface rows being processed together. Batch identifiers are typically used by concurrent programs and interface loaders to isolate one run's data from another, ensuring that partial or failed loads can be identified and reprocessed without affecting other concurrent batches.
• CHECK_SETUPS — Performs validation of the setup and configuration data required before assessment records can be inserted or processed. This may include verifying code classes, person identifier types, or other reference data held in the IGS_AD_CODE_CLASSES and IGS_PE_PERSON_ID_TYP tables, thereby preventing interface inserts when foundational configuration is missing or inconsistent.
• INSERT_ACT_TO_INTERFACE — Inserts assessment records into the corresponding Admissions interface tables. This is the principal write operation of the package, taking assessment data and populating the interface staging structures so that subsequent processes can validate and transfer the rows into the base admissions tables.

Tables Accessed

The package references a broad set of APPS synonyms, reflecting its role as an interface and validation utility across admissions and person data. The documented references include:

• IGS_AD_ACT_ASSESSMENTS and its sequence IGS_AD_ACT_ASSESSMENTS_S — the base assessment records that the interface ultimately feeds.
• IGS_AD_ACT_STATISTICS — consolidated statistical information derived from assessment data.
• IGS_AD_CODE_CLASSES — validation reference data such as assessment code classifications.
• IGS_PE_PERSON_ID_TYP — person identifier type definitions used to resolve and validate person identifiers.
• IGS_AD_ADDRUSAGE_INT_ALL / IGS_AD_ADDRUSAGE_INT_S — address usage interface tables, supporting the capture of assessment-related address usage.
• Additional interface tables including IGS_AD_ACADHIS_INT_ALL, IGS_AD_ACADHIS_INT_S, IGS_AD_ADDR_INT_ALL, IGS_AD_ADDR_INT_S, IGS_AD_API_INT_ALL, IGS_AD_API_INT_S, IGS_AD_CONTACTS_INT_ALL, and IGS_AD_CONTACTS_INT_S — staging structures for academic history, addresses, API data, and contacts associated with the applicant record being assessed.

Usage Notes

Because this package is classified as OTHER rather than a published public API, Oracle does not formally guarantee its signature across releases; nonetheless, it is a stable object in both 12.1.1 and 12.2.2 where the IGS_AD schema is present. It is typically invoked indirectly by Admissions concurrent programs, interface loaders, or internal Oracle Admissions code rather than being called directly from custom forms.

Customers writing custom extensions should treat the package as subject to change, avoid hard-coding assumptions about procedure parameters, and validate the package version against the target instance before relying on it. The package is referenced by zero other packages in the documented dependency list, so its callers are expected to be external programs or Oracle internal components. Its dependency on APPS synonyms and STANDARD confirms that it executes in the standard APPS runtime context with the usual toolset.