Search Results igs_ad_batc_def_det_all




Overview
Explore in AI Chat

Overview

The IGS_AD_BATC_DEF_DET_ALL table is a core component of the Oracle EBS IGS — Student System product family, which supports the admissions and recruitment lifecycle in higher-education implementations. According to the Oracle ETRM (12.1.1 / 12.2.2) metadata, this table stores batch default decision detail information. In practical terms, it captures the pre-configured decision outcomes that the system applies when processing admissions applications in bulk via a batch defaulting process.

The table is owned by the IGS schema and is marked VALID in the data dictionary. Its documented physical schema includes 20 columns and a single-row-per-batch granularity dictated by the primary key. From a Data Vault modeling perspective, the metadata classifies this object as standalone, meaning no foreign-key relationships were mined from its constraint structure. A heuristic modeling suggestion would therefore treat it as a satellite-like table keyed on BATCH_ID, describing decision-default attributes rather than participating as a hub or link. Designers should note this is a modeling heuristic, not a documented Data Vault definition.

Key Information Stored

The 20 documented columns can be organized into several logical groupings:

The remaining columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, ORG_ID) provide standard EBS audit and multi-org (ORG_ID) context. ORG_ID supports Operating Unit partitioning where multi-org is enabled.

Common Use Cases and Queries

Typical reporting scenarios include tracking pending vs. finalized bulk admission decisions and auditing default decision configuration for a given admissions cycle. A representative query:

SELECT b.batch_id, b.description, b.adm_cal_type,
       b.admission_cat, b.decision_make_id, b.decision_date
FROM   igs_ad_batc_def_det_all b
WHERE  b.acad_cal_type = :p_acad_cal_type
AND    b.adm_cal_type  = :p_adm_cal_type
AND    b.org_id        = :p_org_id
ORDER  BY b.batch_id;

Reporting use cases include batch decision audit trails, cycle-based admissions yield analysis, and reconciliation of defaulted versus manually overridden decisions.

Related Objects

Because the mined relationship data classifies this table as standalone, the ETRM does not document explicit foreign keys. Join relationships are therefore inferred through shared reference identifiers rather than enforced constraints:

Application logic is driven primarily through the Student System admissions batch defaulting APIs and concurrent programs rather than direct DML.