Search Results igs_tr_type_v




Overview

IGS_TR_TYPE_V is a form view owned by the APPS schema in the Oracle E-Business Suite Student System (IGS) product family. As documented in the ETRM 12.2.2 metadata, it serves as the form view for the tracking types table. Tracking types define the categories of tracking items used to monitor student interactions, admissions milestones, recruitment activities, and related administrative follow-ups within the Student System.

The view presents a denormalized, user-facing representation of tracking type records by joining the base tracking type table to the lookup values table and resolving the internal code stored on the base record into a human-readable description. This design allows Oracle Forms blocks and concurrent programs to display descriptive text rather than encoded lookup codes. For reporting and integration purposes, the view provides a stable, read-only projection of tracking type configuration without exposing the underlying join logic to the consuming application.

The user search term s_tracking_type_desc corresponds directly to the column that carries this resolved description, making it the primary reason a report developer or integrator would query IGS_TR_TYPE_V rather than the base table.

Underlying Base Objects

The view is defined over two objects:

Because the join is an inner join on a mandatory lookup, tracking type rows whose system tracking type code does not exist in the TRACKING_TYPE lookup set will not appear in the view result set. The view text selects the ROWID of the base table as ROW_ID, which preserves the ability of Oracle Forms to perform row-level updates against the underlying IGS_TR_TYPE record while still displaying the lookup description.

Key Columns

  • ROW_ID — row identifier from IGS_TR_TYPE, used by the form for update and delete processing.
  • ORG_ID — operating unit that owns the tracking type record; supports multi-org security.
  • TRACKING_TYPE — the user-defined tracking type identifier or name.
  • DESCRIPTION — free-text description of the tracking type.
  • S_TRACKING_TYPE — system tracking type code stored on the base record.
  • S_TRACKING_TYPE_DESC — the decoded meaning of the system tracking type, resolved from IGS_LOOKUP_VALUES. This is the column most commonly referenced in reports and is the target of the user's search.
  • TARGET_DAYS — the number of days allowed or expected for the tracking action.
  • SEQUENCE_IND — indicates whether sequence ordering applies to the tracking type.
  • BUSINESS_DAYS_IND — indicates whether target days are counted in business days rather than calendar days.
  • CLOSED_IND — indicates whether the tracking type is closed to further use.
  • PUBLISH_IND — indicates whether the tracking type is published or visible to downstream consumers.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.
  • S_TRACKING_USED_BY, DESC_USED_BY — placeholder columns returned as NULL in the view's select list, retained for form block compatibility.

Common Use Cases and Queries

The view is typically queried to produce configuration listings of tracking types with their resolved system descriptions, to validate that required system tracking types exist before loading tracking data, and to drive LOVs and validation logic in custom or extended forms.

A basic listing of active, published tracking types:

SELECT tracking_type,
       description,
       s_tracking_type,
       s_tracking_type_desc,
       target_days,
       business_days_ind
FROM   apps.igs_tr_type_v
WHERE  closed_ind = 'N'
AND    publish_ind = 'Y'
ORDER  BY tracking_type;

Filtering on the decoded system tracking type description, which is the typical pattern when a report is driven by a descriptive parameter rather than a code:

SELECT tracking_type,
       s_tracking_type_desc
FROM   apps.igs_tr_type_v
WHERE  s_tracking_type_desc = :p_s_tracking_type_desc;

Because the view exposes the base table ROWID, it should be treated as a form-support object: reporting and integration queries should restrict themselves to the SELECT list and avoid DML against the view outside of standard form processing.