Search Results igs_da_req_wiftrcks_u1

Overview

IGS.IGS_DA_REQ_WIFTRCKS is a transactional table in the Oracle E-Business Suite IGS (Student Systems / Student Records) schema. It stores Degree Audit "What-If" request information for track and option selections made by a student. What-If processing allows a student to model an alternative program, major, or track without altering their actual academic record, and this table captures the specific track/option units that the student elected for that hypothetical evaluation.

The table is documented in the ETRM repository as Obsolete. Deployments on 12.1.1 and 12.2.2 may still carry the object because it is part of the shipped FND Design Data (IGS.IGS_DA_REQ_WIFTRCKS) and is retained for historical data and upgrade compatibility, but new development and new functional configuration should not depend upon it. Its storage characteristics are conventional for an APPS transactional table: tablespace APPS_TS_TX_DATA, PCTFREE 10, and indexes in APPS_TS_TX_IDX.

The metadata carries no foreign-key relationships, and the heuristic Data Vault classification mined from the FK structure is standalone. In Data Vault modeling terms, this object is best treated as a satellite that would attach to a request hub keyed by BATCH_ID, since all of its descriptive attributes (track, option, calendar, organization) qualify a single Degree Audit request rather than representing an independent business entity. Practitioners building a warehouse layer should therefore map BATCH_ID as the link to the request hub and treat PRIMARY_SEQ_NUM strictly as the technical row identifier.

Key Information Stored

The table contains 16 documented columns, of which the following are functionally significant:

• PRIMARY_SEQ_NUM — the surrogate primary key (IGS_DA_REQ_WIFTRCKS_PK) and the target of unique index IGS_DA_REQ_WIFTRCKS_U1. It is a system-generated row identifier with no business meaning.
• BATCH_ID — the unique identifier of the Degree Audit request to which the What-If selection belongs.
• PROGRAM_CODE, MAJOR_SEQ_NUM, TRACK_SEQ_NUM — the program/major/track coordinates of the selection. Together with BATCH_ID these form the business-key candidate enforced by unique index IGS_DA_REQ_WIFTRCKS_U2 (BATCH_ID, PROGRAM_CODE, MAJOR_SEQ_NUM, TRACK_SEQ_NUM). Documentation notes that a maximum of one track/option is permitted per major unit set per request, and MAJOR_SEQ_NUM may be null depending on institutional setup.
• TRACK_UNIT_SET and TRACK_OPTION_VERSION — the track/option unit set chosen by the user at request time and its version, which together pin the selection to a specific catalog revision.
• TRACK_OPTION_CATALOG — the catalog under which the track/option selection was made, providing the effective-dated context for university-wide policy.
• TRACK_CAL_TYPE and TRACK_CI_SEQ_NUM — the calendar type and calendar instance sequence number attached to the tracked program. This pair is the direct answer to the "track_cal_type" search; TRACK_CAL_TYPE is the VARCHAR2(10) calendar-type code and TRACK_CI_SEQ_NUM resolves it to a specific calendar instance.
• ORG_UNIT_TRACK — the organizational unit responsible for the track/option unit set.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard Oracle WHO columns recording audit lineage.

Common Use Cases and Queries

Two reporting patterns dominate. The first reconstructs all What-If track selections for a request; the second resolves the calendar context of a selection.

• Request reconstruction: SELECT program_code, major_seq_num, track_seq_num, track_unit_set, track_option_catalog FROM igs_da_req_wiftrcks WHERE batch_id = :p_batch_id ORDER BY program_code, major_seq_num, track_seq_num;
• Calendar-type resolution: SELECT w.batch_id, w.program_code, w.track_cal_type, w.track_ci_seq_num FROM igs_da_req_wiftrcks w WHERE w.track_cal_type = :p_cal_type;
• Institutional audit: aggregate selections by org_unit_track or track_option_catalog to determine which tracks students model most frequently.
• Data-migration or purge scoping: join on BATCH_ID against the parent request table to isolate rows whose request no longer exists, given the object's Obsolete status.

All reporting should filter on the WHO columns (creation_date, last_update_date) when reconstructing point-in-time activity, and should never assume MAJOR_SEQ_NUM is populated.

Related Objects

Because the metadata records no foreign keys, relationships are functional rather than declarative. The most significant objects referenced by or associated with IGS_DA_REQ_WIFTRCKS are:

• The Degree Audit request header table in the IGS_DA schema — joined on BATCH_ID; this is the parent request that determines whether the record is a single (non-batch) request type, the only type for which this table is populated.
• The track/option unit set definition tables — joined on TRACK_UNIT_SET and TRACK_OPTION_VERSION to resolve the selected option's description.
• The program and major catalog tables — joined on PROGRAM_CODE and MAJOR_SEQ_NUM.
• The academic calendar tables (calendar type and calendar instance) — joined on TRACK_CAL_TYPE and TRACK_CI_SEQ_NUM.
• The organizational unit table — joined on ORG_UNIT_TRACK.
• The FND Design Data definition IGS.IGS_DA_REQ_WIFTRCKS — the seeded metadata record that governs upgrade behaviour for the object.
• The Degree Audit process/public API layer for What-If evaluation — the functional consumer that reads these rows when generating a simulated audit.

Given the Obsolete classification, integration work should confirm with the institution's upgrade documentation before extending dependencies on this table.