Search Results igs_tr_step_ctlg




Overview
Explore in AI Chat

Overview

IGS_TR_STEP_CTLG is a multi-organization (MO) view owned by the APPS schema in the Oracle E-Business Suite Student System (IGS) product family. It presents a reporting and integration layer over the IGS_TR_STEP_CTLG_ALL master table, which stores the catalog of tracking steps used within the Student System. The view is documented as VALID in Oracle EBS 12.1.1 and 12.2.2, and its ETRM description states that it is "the multi-org view for a master table for tracking steps." Tracking steps represent the discrete milestones or actions that a student record passes through during an academic lifecycle, such as admissions, registration, or program completion. Because it is an MO view rather than a base table, consumers do not query it for direct DML; instead it is intended for SELECT-based reporting, concurrent program data extraction, and integration interfaces that must respect the operating unit (ORG_ID) security context of the session.

Underlying Base Objects

The view is defined over two documented base objects: the master table IGS_TR_STEP_CTLG_ALL (aliased TRSC) and the lookup table IGS_LOOKUP_VALUES (aliased LKUP). The join to IGS_LOOKUP_VALUES is an inner join constrained to LOOKUP_TYPE = 'TRACKING_STEP_TYPE', matching S_TRACKING_STEP_TYPE against LOOKUP_CODE and projecting LKUP.MEANING into the DESC_STEP_TYPE column. This provides a decoded, user-facing description of the step type without requiring the caller to join the lookup table separately.

The multi-org filter is implemented in the WHERE clause using the standard Oracle MO pattern: the NVL expression on TRSC.ORG_ID is compared against the value decoded from the USERENV('CLIENT_INFO') session attribute, with a sentinel of -99 (and blank client info mapped to NULL). This ensures only rows belonging to the current operating unit are returned, or the appropriate global rows where ORG_ID is null.

Key Columns

  • ROW_ID — the base table ROWID, exposed conventionally for MO views.
  • ORG_ID — the operating unit identifier driving the multi-org security filter.
  • STEP_CATALOG_ID / STEP_CATALOG_CD — the primary key and the human-readable code for the tracking step catalog entry.
  • DESCRIPTION — the descriptive text for the tracking step.
  • ACTION_DAYS — the number of days associated with the step action, typically used for scheduling or escalation logic.
  • S_TRACKING_STEP_TYPE / DESC_STEP_TYPE — the step type code and its decoded meaning sourced from IGS_LOOKUP_VALUES (LOOKUP_TYPE = 'TRACKING_STEP_TYPE').
  • S_TRACKING_USED_BY / DESC_USED_BY — exposed as NULL placeholders in the documented view text, reserved for used-by semantics.
  • PUBLISH_IND / CLOSED_IND — indicators controlling whether the step is published for use and whether the catalog entry is closed.
  • Standard WHO audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical consumers use this view to list active tracking steps for an operating unit, most often filtered by PUBLISH_IND or CLOSED_IND. A preferred pattern passes the tracking step type and closed flag as bind variables, beginning by calling FND_CLIENT_INFO.SET_ORG_CONTEXT to initialize the MO session context before the SELECT executes.

A representative query returns the published, open steps together with their decoded type meanings:

  • SELECT STEP_CATALOG_CD, DESCRIPTION, ACTION_DAYS, DESC_STEP_TYPE FROM IGS_TR_STEP_CTLG WHERE PUBLISH_IND = 'Y' AND CLOSED_IND = 'N' ORDER BY STEP_CATALOG_CD;

For integration or reconciliation extracts, all columns may be selected with the ORG_ID included to confirm the operating unit, and the same WHERE clause applied. Because the view joins IGS_LOOKUP_VALUES, it is important that the TRACKING_STEP_TYPE lookup contains a matching, enabled code for every step row; a missing lookup entry will suppress that row from the result set through the inner join. Joins to downstream tracking tables should be driven from the returned STEP_CATALOG_ID. All access is read-only, and the MO filter must be respected to avoid cross-operating-unit leakage in reporting outputs.