Search Results igsbv_student_prg_transfers

Overview

IGSBV_STUDENT_PRG_TRANSFERS is a read-only view owned by the APPS schema in the Oracle E-Business Suite Student System (IGS) product family. It exposes student program attempt transfer records, presenting the relationship between a student's original program or course attempt and the transfer program or course to which the attempt is being applied. The view consolidates student, party, and program version information into a single denormalized projection, making it suitable for reporting, inquiry screens, and integration extracts without requiring the caller to reconstruct the multi-table join manually. Because the view is defined WITH READ ONLY, it supports query access exclusively and cannot be used as the target of DML operations.

The view is registered as VALID in the ETRM repository and is available in both Oracle EBS 12.1.1 and 12.2.2 environments. It is particularly relevant to users searching for the SUSA_TO_TRANSFER attribute, which is a legacy flag carried on the transfer record indicating whether Student Unit Attempt (SUA) records are to be transferred along with the program attempt transfer.

Underlying Base Objects

The view is defined over five base tables within the APPS schema, joined on person and course identifiers:

• IGS_PS_STDNT_TRN (aliased PST) — the primary transfer record table, supplying the source program, transfer program, dates, flags, and audit columns.
• HZ_PARTIES (aliased HP) — the trading community party record, providing PARTY_NUMBER and PARTY_NAME for the student.
• IGS_EN_STDNT_PS_ATT_ALL (aliased SCA and SCA1) — the student program attempt table, joined twice: once for the originating attempt and once for the transfer attempt.
• IGS_PS_VER_ALL (aliased PSV and PSV1) — the program version table, again joined twice to resolve the titles of the originating and transfer programs.

The join conditions require matching PERSON_ID and COURSE_CD across PST, SCA, and PSV, with VERSION_NUMBER linking the attempt and program version rows. An equivalent set of joins is repeated with SCA1 and PSV1 for the transfer side. Note that the documented column list uses the PROGRAM_* naming convention, whereas the view text references COURSE_CD columns; the IGS data model treats program and course codes interchangeably at this level.

Key Columns

• PERSON_IDENTIFIER / PERSON_NUMBER / PERSON_NAME — student identification drawn from HZ_PARTIES.
• PROGRAM_CODE / PROGRAM_TITLE — the originating program attempt.
• TRANSFER_PROGRAM_CODE / TRANSFER_PROGRAM_TITLE — the destination program attempt.
• TRANSFER_DATE — the date the transfer was recorded.
• APPROVED_DATE — the date the transfer received approval.
• EFFECTIVE_TERM_CAL_TYPE / EFFECTIVE_TERM_SEQUENCE_NUM — the academic term from which the transfer takes effect.
• DISCONTINUE_SOURCE_FLAG — indicates whether the source program attempt is discontinued upon transfer.
• TRANSFER_ADV_STAND_FLAG — indicates transfer of advanced standing.
• UOOIDS_TO_TRANSFER / SUSA_TO_TRANSFER — flags controlling whether unit offering option identifiers and student unit attempt records are carried across.
• STATUS_FLAG / STATUS_DATE — current disposition of the transfer record and the date that status was set.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE.

Common Use Cases and Queries

Typical usage includes transfer articulation reporting, verification of advanced standing, and feeds into student records extracts. A representative query filtering on the SUSA transfer flag:

SELECT person_number, person_name, program_code, transfer_program_code, transfer_date, susa_to_transfer
FROM apps.igsbv_student_prg_transfers
WHERE susa_to_transfer = 'Y';

A second pattern lists all approved transfers effective in a given term:

SELECT person_number, program_title, transfer_program_title, approved_date
FROM apps.igsbv_student_prg_transfers
WHERE status_flag = 'APPROVED'
AND effective_term_cal_type = 'STANDARD';

Because the view performs multiple outer joins across high-volume attempt and version tables, queries should be constrained on PERSON_ID, PROGRAM_CODE, or date ranges wherever possible to limit the join cost.