Results for “igs_da_req_rpts”

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

Overview

The IGS.IGS_DA_REQ_RPTS table resides in the IGS (Student System) schema and serves as the persistent store for Degree Audit Request Reports produced by a third-party degree audit engine. In the Oracle E-Business Suite 12.1.1 and 12.2.2 footprint for higher education institutions, degree audit functionality is typically fulfilled by an external academic advising application that returns a formatted audit result set to the EBS database. This table captures that returned payload against the originating degree audit request so it can be retained, reprinted, and reconciled with the student's academic record.

Functionally, the table is an output or results store rather than a transactional driver. Each row is scoped to a degree audit request identified by the composite of a batch identifier and a person identifier, and it holds the rendered report text generated for that request. This makes it the terminal object in the degree audit request flow: the request is raised, students are associated with the batch, and the third-party engine writes its report output back into this table.

The Data Vault classification derived heuristically from the foreign key structure is satellite-leaning. This is a modeling suggestion rather than a physical property of the EBS table: because the object is keyed on a parent business key (BATCH_ID, PERSON_ID) and carries descriptive, non-identifying attributes plus standard audit columns, it behaves like a satellite attached to a degree audit request link or hub rather than a hub or link in its own right.

Key Information Stored

The documented physical schema contains eight columns. The following are the ones of practical significance:

• BATCH_ID — Identifier of the degree audit batch to which the request belongs. Forms part of the primary key and is the column used to join back to the request/student association table.
• PERSON_ID — The person (student) for whom the degree audit report was generated. Together with BATCH_ID it completes the primary key.
• REPORT_TEXT — The body of the audit report as returned by the third-party engine. Depending on configuration this may hold formatted text, structured output, or a serialized payload. It is the substantive data column and typically the largest column in the table.
• CREATION_DATE — Timestamp of row insertion; useful for determining when the audit result was received from the third party.
• CREATED_BY — The application user or process that inserted the row.
• LAST_UPDATE_DATE — Timestamp of the most recent modification, allowing identification of regenerated or corrected reports.
• LAST_UPDATED_BY — The user or process responsible for the last change.
• LAST_UPDATE_LOGIN — The login/session context under which the last update occurred, supporting audit trail reconstruction.

The surrogate primary key is enforced by IGS_DA_REQ_RPTS_PK on (BATCH_ID, PERSON_ID). A unique index, IGS_DA_REQ_RPTS_U1, is documented on the same two columns, so the composite is simultaneously the primary key and the business-key candidate — meaning at most one report row exists per batch/person combination. A secondary index entry, SYS_IL0000196916C00003$$, is an Oracle-generated LOB index associated with a large object column, consistent with REPORT_TEXT being stored as a CLOB or BLOB.

Common Use Cases and Queries

Because the report text is keyed by batch and person, the most common access pattern is retrieval of a single student's audit report for display or reprinting:

• Fetch a student's latest report: SELECT REPORT_TEXT FROM IGS_DA_REQ_RPTS WHERE BATCH_ID = :batch AND PERSON_ID = :person;
• Count reports produced for a batch: SELECT BATCH_ID, COUNT(*) FROM IGS_DA_REQ_RPTS GROUP BY BATCH_ID;
• Identify reports generated in a date window: filter on CREATION_DATE for reconciliation against third-party run logs.
• Detect regenerated rows: compare CREATION_DATE with LAST_UPDATE_DATE to find reports reissued after original load.
• Join to request/student data to produce advising extracts listing each student alongside the audit text.

Reporting use cases center on degree progress tracking, batch reconciliation against the third-party scheduler, and archival of historical audits. Because REPORT_TEXT may be a LOB, avoid selecting it in set-based queries unless required, and prefer DBMS_LOB.SUBSTR or substring extraction for previews.

Related Objects

The documented foreign key relationship anchors this table to the degree audit request/student association table:

• IGS_DA_REQ_STDNTS — Referenced by IGS_DA_REQ_RPTS.BATCH_ID (and, by business key, PERSON_ID). This is the principal parent object; joins here establish which request a report belongs to and which students were included.
• IGS_DA_REQ_RPTS_PK — Primary key constraint on (BATCH_ID, PERSON_ID).
• IGS_DA_REQ_RPTS_U1 — Unique index on (BATCH_ID, PERSON_ID), reinforcing the one-report-per-student-per-batch rule.
• Person/student master data — PERSON_ID resolves to the person record in the IGS student tables, allowing reports to be linked to biographical and program enrollment data.

Where the degree audit request is batch-oriented, reporting queries should be driven from IGS_DA_REQ_STDNTS outward, outer-joining to IGS_DA_REQ_RPTS to identify students within a batch for whom no report text was returned — a common indicator of third-party processing failure.