Search Results igs_ad_acadhis_int

Overview

IGS_AD_ACADHIS_INT is an Oracle EBS 12.1.1 / 12.2.2 database view owned by the APPS schema and classified under the IGS — Student System product family. It exposes the interface/staging structure used to load and validate external academic history records into the Student System, primarily supporting the Academic History interface process (commonly linked to the Admissions and Records functionality). As a view, it does not store data itself; it projects columns from an underlying interface table to present a flattened, interface-ready record set.

In the context of the user's search term transcript_required, this view is significant because it exposes the TRANSCRIPT_REQUIRED column, allowing implementers and developers to query which staged academic history records have been flagged as requiring a formal transcript. This is typically relevant during admissions evaluation, credential verification, and self-reported academic history validation workflows. The view also carries a MATCH_IND, STATUS, and ERROR_CODE, indicating it participates in the matching and error-reporting logic of the interface load.

Underlying Base Objects

The ETRM metadata documentation does not explicitly list referenced base objects, but the view text is a straightforward projection from a single underlying interface table (aliased as TAB) using TAB.ROWID ROW_ID. This pattern is characteristic of EBS interface views that map to a corresponding IGS_AD_ACADHIS_INT or related academic history interface table in the IGS schema. Because the view is defined over an interface (staging) table rather than transactional tables, records here represent inbound data pending validation, matching, or transfer into the permanent academic history and application structures.

The SELECT list relies on TAB.* column references throughout, confirming a one-to-one column projection. No joins, unions, or aggregations are present in the documented excerpt, which supports the interpretation that this is a thin compatibility or exposure layer over the base interface table.

Key Columns

• ROW_ID — ROWID of the underlying interface row, used for targeted updates or deletes.
• EDUCATION_ID / INTERFACE_ACADHIS_ID / INTERFACE_ID — Identifiers linking the staged record to academic history and interface batch processing.
• TRANSCRIPT_REQUIRED — Flag indicating whether a transcript is required for the staged academic history entry.
• INSTITUTION_CODE, TYPE_OF_SCHOOL, CURRENT_INST, PROGRAM_CODE — Descriptors of the external institution and program.
• START_DATE, END_DATE, PLANNED_COMPLETION_DATE — Academic period and completion information.
• SELFREP_TOTAL_CP_ATTEMPTED, SELFREP_TOTAL_CP_EARNED, SELFREP_INST_GPA, SELFREP_WEIGHTED_GPA, SELFREP_RANK_IN_CLASS — Self-reported academic performance metrics.
• MATCH_IND, STATUS, ERROR_CODE, DUP_ACAD_HISTORY_ID — Interface processing state, matching, and duplicate detection.
• ATTRIBUTE1–ATTRIBUTE20, ATTRIBUTE_CATEGORY — Descriptive flexfield (DFF) segments.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — WHO columns and concurrent request context.
• ORG_ID — Multi-org operating unit identifier.

Common Use Cases and Queries

Typical uses include auditing staged academic history loads, identifying records flagged for transcript verification, and diagnosing interface errors before the data is promoted into transactional academic history tables.

SELECT interface_acadhis_id,
       institution_code,
       transcript_required,
       status,
       error_code
FROM   apps.igs_ad_acadhis_int
WHERE  transcript_required = 'Y'
AND    status = 'ERROR';

Another common scenario is reporting self-reported GPA data for inbound applications:

SELECT education_id,
       program_code,
       selfrep_inst_gpa,
       selfrep_total_cp_earned,
       transcript_required
FROM   apps.igs_ad_acadhis_int
WHERE  org_id = :p_org_id
ORDER BY creation_date DESC;

Developers also query MATCH_IND and DUP_ACAD_HISTORY_ID to troubleshoot matching or duplicate detection issues. Because the view is read-mostly and interface-scoped, any corrective action is normally performed through the underlying interface table or the associated concurrent program rather than directly against the view.