Results for “advising_hold_type”

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

Overview

IGSBV_ADVISING_STUDENTS is a read-only view owned by the APPS schema within the Oracle E-Business Suite Student System (IGS) product family. It exposes student details associated with the various advising groups configured in the institution's student information system. The view serves as a simplified, security-constrained reporting and integration layer on top of the transactional advising group membership data, presenting one row per student-to-advising-group association, including the hold state and notification metadata that governs that membership.

Because the view is defined WITH READ ONLY, it is intended exclusively for query, extraction, and downstream integration purposes; no DML operations may be performed against it. This makes it suitable for concurrent programs, Oracle Reports, BI Publisher data models, OBIEE/OTBI-style extracts, and custom SQL used by functional consultants and DBAs to audit advising group populations.

Underlying Base Objects

According to the documented view text, IGSBV_ADVISING_STUDENTS is defined over a single base object: IGS_AZ_STUDENTS. The view selects fourteen columns from that table and applies no joins, unions, or aggregate functions, meaning the row cardinality of the view matches that of the underlying advising group student table. Column naming is largely preserved, with selected identifier columns exposed in the view under adjusted names (for example, GROUP_STUDENT_IDENTIFIER and STUDENT_PERSON_IDENTIFIER).

No additional referenced base objects are documented in the ETRM metadata for this view, so lineage is direct and one-to-one with IGS_AZ_STUDENTS. The WITH READ ONLY clause, combined with the absence of a WHERE predicate, indicates that all row-level filtering — for example by institution, career, or term — is expected to be supplied by the calling query.

Key Columns

• GROUP_STUDENT_IDENTIFIER — Primary identifier for the advising group membership record; uniquely identifies a student's association with a specific advising group.
• GROUP_NAME — Descriptive name of the advising group to which the student belongs.
• STUDENT_PERSON_IDENTIFIER — Foreign key to the person record in the TCA/HZ person model, identifying the student.
• START_DATE / END_DATE — Effective date range during which the student's membership in the advising group is valid.
• ADVISING_HOLD_TYPE — Code identifying the type of advising hold applied to the student in connection with the group.
• HOLD_START_DATE — Date on which the advising hold took effect.
• NOTIFIED_DATE — Date on which the student was notified of the advising hold or group action. This is the column most commonly queried for communication tracking and compliance reporting.
• ACCEPT_ADD_FLAG / ACCEPT_DELETE_FLAG — Flags indicating whether the student has accepted an add or delete action tied to the advising group membership.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — Standard Oracle EBS WHO columns for audit and change tracking.

Common Use Cases and Queries

The view supports advising office reporting, hold management audits, student notification tracking, and integration feeds into third-party advising or CRM systems. A typical notification audit identifies students with an advising hold who have not yet been notified:

• SELECT group_name, student_person_identifier, advising_hold_type, hold_start_date, notified_date FROM apps.igsbv_advising_students WHERE notified_date IS NULL AND advising_hold_type IS NOT NULL;
• SELECT group_name, COUNT(*) FROM apps.igsbv_advising_students WHERE TRUNC(notified_date) BETWEEN :p_start AND :p_end GROUP BY group_name;
• SELECT s.student_person_identifier, s.group_name, s.notified_date FROM apps.igsbv_advising_students s WHERE s.start_date <= SYSDATE AND NVL(s.end_date, SYSDATE) >= SYSDATE;

All queries should reference the view as APPS.IGSBV_ADVISING_STUDENTS and be executed under a responsibility whose MOAC and security profile grant access to the relevant student records. Because the view applies no filtering or joins, callers requiring student names, program enrollments, or hold reason descriptions must join to the person and student base tables separately.