Search Results tracking_step_id

Overview

The IGS_TR_STEP table is a core data entity within the Oracle E-Business Suite's now-obsolete Student System (IGS). It serves as the master repository for individual steps or stages within a defined tracking process. Each record in this table represents a specific step associated with a tracking item, which could be a student application, a service request, or another monitored workflow. The steps can be either predefined defaults configured for a given tracking type or custom, user-defined steps created to handle unique process variations. Its primary role is to enable detailed progress monitoring and workflow management by recording the sequence, status, and details of each action required to complete a broader tracking item.

Key Information Stored

The table's structure is designed to capture the step's identity, its relationship to the parent item, and its operational details. The composite primary key, consisting of TRACKING_ID and TRACKING_STEP_ID, uniquely identifies each step within the system. The TRACKING_ID column is a foreign key that links the step to its parent tracking item in the IGS_TR_ITEM_ALL table. The STEP_CATALOG_CD column references a catalog code in the IGS_TR_STEP_CTLG_ALL table, which likely defines the step's template, description, and standard attributes. A critical column is RECIPIENT_ID, which stores a foreign key to the HZ_PARTIES table, indicating the person or party (e.g., an advisor, staff member, or department) responsible for or assigned to complete this specific step. Other columns not explicitly listed but typical for such entities would include status, due date, completion date, and sequence number.

Common Use Cases and Queries

A primary use case is generating reports on the status and progress of tracking items, such as identifying all pending steps for a specific recipient or analyzing step completion times. Common queries involve joining to the parent tracking item and recipient tables. For example, to find all incomplete steps for a specific recipient, a query might be: SELECT its.tracking_step_id, its.tracking_id, itia.item_name FROM igs_tr_step its JOIN igs_tr_item_all itia ON its.tracking_id = itia.tracking_id WHERE its.recipient_id = &PARTY_ID AND its.step_status != 'COMPLETED';. Another frequent pattern is querying the step catalog to understand the standard workflow: SELECT its.*, itsc.name FROM igs_tr_step its JOIN igs_tr_step_ctlg_all itsc ON its.step_catalog_cd = itsc.step_catalog_cd WHERE its.tracking_id = &TRACKING_ID ORDER BY its.sequence_num;. These queries support operational dashboards and audit trails for process adherence.

Related Objects

The IGS_TR_STEP table is centrally connected within the tracking module's schema through documented foreign key relationships. It references the following tables:

• HZ_PARTIES via the RECIPIENT_ID column, linking a step to the responsible party.
• IGS_TR_ITEM_ALL via the TRACKING_ID column, establishing the step's parent tracking item.
• IGS_TR_STEP_CTLG_ALL via the STEP_CATALOG_CD column, classifying the step type.

Conversely, it is referenced by:

• IGS_TR_STEP_NOTE via the composite foreign key (TRACKING_ID, TRACKING_STEP_ID), allowing for detailed annotations or comments to be attached to each specific process step.

These relationships form a hierarchical data model where a tracking item (IGS_TR_ITEM_ALL) contains multiple steps (IGS_TR_STEP), each of which can have multiple notes (IGS_TR_STEP_NOTE).