Search Results step_completion_ind

Overview

IGS_TR_STEP_V is a reporting and integration view owned by the APPS schema in the Oracle E-Business Suite Student System (IGS) product family. It exposes the individual tracking steps associated with student tracking records, enriching the underlying step data with derived scheduling figures and recipient identification. In the Oracle EBS 12.1.1 and 12.2.2 releases the view remains a valid, deployed object, and it functions as the canonical read interface for applications, concurrent programs, and custom reports that need to display or process tracking step progress.

The view materialises each step as a single row containing the step's sequence number, descriptive text, completion information, and calculated action and overdue dates. Because the derived columns are produced by PL/SQL functions in the IGS_TR_GEN_001 package rather than stored in a base table, the view abstracts business-date arithmetic away from the consumer, so reporting tools can query due dates and lateness without reimplementing the tracking calendar logic.

Underlying Base Objects

The view is defined over four referenced objects joined in its text:

• IGS_TR_ITEM (TRI) — the tracking item header, supplying START_DT, SEQUENCE_IND, and BUSINESS_DAYS_IND used by the date-calculation functions.
• IGS_TR_STEP (TRST) — the base tracking step table, providing the primary keys, description, completion date, bypass and completion indicators, and step type.
• IGS_PE_PERSON_BASE_V (PE) — the person base view, outer-joined on RECIPIENT_ID to return the recipient's person number and preferred name.
• IGS_LOOKUPS_VIEW (LKUP) — the lookup view, outer-joined on lookup type 'TRACKING_STEP_TYPE' to translate the step type code into its displayed meaning.

The joins are driven from IGS_TR_ITEM to IGS_TR_STEP on TRACKING_ID, with the person and lookup joins expressed as outer joins. The tracked row identity is preserved through ROWID, allowing the view to be used as the basis for updateable-region or DML-aware processing in some toolkits.

Key Columns

• TRACKING_ID / TRACKING_STEP_ID / TRACKING_STEP_NUMBER — the tracking item, the unique step identifier, and the step's ordinal position.
• DESCRIPTION — free-text description of the tracking step.
• ACTION_DT — derived due date, computed by IGS_TR_GEN_001. TRKP_CLC_ACTION_DT from the tracking item's start date, sequence indicator, and business-day flag.
• OVERDUE_DAYS — derived lateness, computed by TRKP_CLC_DAYS_OVRDUE by comparing the derived action date to the actual completion date.
• COMPLETION_DT, STEP_COMPLETION_IND, BY_PASS_IND, ACTION_DAYS — the recorded completion date, completion flag, bypass flag, and configured action window.
• RECIPIENT_ID, RECIPIENT_NUMBER, DSP_PREFERRED_NAME — the responsible person and display name.
• S_TRACKING_STEP_TYPE, DESC_STEP_TYPE — the step type code and its lookup meaning.
• STEP_CATALOG_CD, STEP_GROUP_ID, PUBLISH_IND — catalogue and grouping attributes, plus the publication flag.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns.

Common Use Cases and Queries

Typical consumers are correspondence and admissions tracking reports, overdue-step exception lists, and interfaces that publish pending actions to external systems. The following query lists all steps for a tracking item with derived due dates:

• SELECT tracking_step_number, description, action_dt, completion_dt, overdue_days, desc_step_type, dsp_preferred_name FROM igs_tr_step_v WHERE tracking_id = :p_tracking_id ORDER BY tracking_step_number;
• SELECT tracking_id, tracking_step_number, description, dsp_preferred_name, overdue_days FROM igs_tr_step_v WHERE step_completion_ind = 'N' AND by_pass_ind = 'N' AND publish_ind = 'Y' AND overdue_days > 0 ORDER BY overdue_days DESC;
• SELECT desc_step_type, COUNT(*) FROM igs_tr_step_v WHERE step_completion_ind = 'Y' GROUP BY desc_step_type;

Note that ACTION_DT and OVERDUE_DAYS are evaluated per row by the IGS_TR_GEN_001 functions, so queries filtering heavily on those columns over large volumes may benefit from restricting TRACKING_ID or creation dates first.