Search Results igs_pe_std_todo




Overview
Explore in AI Chat

Overview

IGS_PE_STD_TODO is a table within the Oracle E-Business Suite IGS — Student System product family, which Oracle classifies as Obsolete in the 12.1.1 and 12.2.2 documentation sets. Functionally, the table stores to-do items that are placed against an individual student record. Representative examples include "Re-assess Fees" and "Produce Outcome Notification." A to-do entry may also carry a threshold date, meaning the item must not be actioned before that date. The table therefore acts as a lightweight workflow and reminder register attached to a student party, rather than as a transactional or financial record.

From a Data Vault modeling perspective, the FK topology suggests a satellite-leaning classification. The primary key is composed of PERSON_ID, S_STUDENT_TODO_TYPE, and SEQUENCE_NUMBER, and the only outbound foreign key points to HZ_PARTIES. This structure describes descriptive attributes hung off a party hub with a business-key qualifier, consistent with a satellite pattern rather than a hub or link.

Key Information Stored

The table is documented with 14 columns in the 12.1.1 physical schema, owned by the IGS schema. The most significant columns are:

  • PERSON_ID — the student party identifier; participates in the primary key and carries the outbound FK to HZ_PARTIES.
  • S_STUDENT_TODO_TYPE — the to-do category or type (for example, fee reassessment versus outcome notification); part of the primary key.
  • SEQUENCE_NUMBER — distinguishes multiple to-dos of the same type for the same person; the final component of the primary key.
  • TODO_DT — the date before which the to-do should not be actioned, matching the description's "mustn't be actioned before" semantic.
  • LOGICAL_DELETE_DT — soft-delete marker, allowing rows to be logically retired without physical deletion.
  • CREATED_BY, CREATION_DATE — standard audit columns capturing who created the to-do and when.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns tracking the most recent modification and the login session that performed it.
  • REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — the concurrent program context, indicating which request and program last wrote the row.

The surrogate primary key is defined as IGS_PE_STD_TODO_PK over (PERSON_ID, S_STUDENT_TODO_TYPE, SEQUENCE_NUMBER). A unique index, IGS_PE_STD_TODO_U1, covers the same three columns, making them the documented business-key candidate. The intersection of surrogate PK and unique index means the key is entirely natural and business-meaningful; there is no separately generated sequence column.

Common Use Cases and Queries

Typical reporting scenarios include identifying open to-dos for a student, listing to-dos that have become actionable, and auditing who created or last changed a to-do. A representative query is:

  • SELECT PERSON_ID, S_STUDENT_TODO_TYPE, SEQUENCE_NUMBER, TODO_DT FROM IGS_PE_STD_TODO WHERE PERSON_ID = :person_id AND LOGICAL_DELETE_DT IS NULL;
  • SELECT t.PERSON_ID, t.S_STUDENT_TODO_TYPE, t.TODO_DT FROM IGS_PE_STD_TODO t WHERE t.TODO_DT >= TRUNC(SYSDATE) AND t.LOGICAL_DELETE_DT IS NULL ORDER BY t.TODO_DT;
  • SELECT S_STUDENT_TODO_TYPE, COUNT(*) FROM IGS_PE_STD_TODO WHERE LOGICAL_DELETE_DT IS NULL GROUP BY S_STUDENT_TODO_TYPE;

Note the recurring LOGICAL_DELETE_DT IS NULL predicate, which is essential for excluding retired rows. Because the table keys on a party, joins to HZ_PARTIES are the standard route for resolving student names and demographics.

Related Objects

  • HZ_PARTIES — referenced by IGS_PE_STD_TODO.PERSON_ID; the parent party record for the student.
  • IGS_PE_STD_TODO_REF — a child table whose composite FK (PERSON_ID, S_STUDENT_TODO_TYPE, SEQUENCE_NUMBER) points back to IGS_PE_STD_TODO, extending the to-do with reference detail.
  • IGS_PE_STD_TODO_PK / IGS_PE_STD_TODO_U1 — the primary key constraint and unique index enforcing to-do uniqueness per person and type.
  • Concurrent program metadata — via REQUEST_ID, PROGRAM_ID, and PROGRAM_APPLICATION_ID, aligning to FND_CONCURRENT_REQUESTS.

Because the IGS Student System is marked obsolete, implementers should confirm whether the table is populated ("Not implemented in this database") before relying on it in custom reports.