Search Results igs_ps_rpt_fmly_all

Overview

The IGS_PS_RPT_FMLY_ALL table is a core data structure within the Oracle E-Business Suite Student System (IGS) module, versions 12.1.1 and 12.2.2. It serves as a master definition table for grouping academic units (courses or subjects) that are considered part of the same "repeat family." This logical grouping is essential for managing academic policies where students are permitted or required to repeat a specific unit. The table provides a centralized, institution-specific repository for a repeat code, ensuring consistent application of repeat rules across the curriculum and student enrollment records. Its role is to act as a reference point that links multiple unit versions under a single, controlled identifier for repeat processing.

Key Information Stored

The table's primary function is to store unique identifiers for each repeat family. The key columns, as indicated by the provided metadata, are:

• RPT_FMLY_ID: The primary key column, uniquely identifying each repeat family record within the database. This surrogate key is typically referenced by foreign keys in related tables.
• REPEAT_CODE: A meaningful code or short description that defines the repeat family. This column, combined with ORG_ID, forms a unique key (IGS_PS_RPT_FMLY_ALL_UK), making the code unique within an operating unit.
• ORG_ID: The operating unit identifier, a standard column in multi-org enabled tables, which partitions the data by the specific institution or business unit within the EBS instance.

While the explicit metadata does not list all columns, typical tables of this nature would also include standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) for auditing, and potentially an ENABLED_FLAG or descriptive NAME field.

Common Use Cases and Queries

This table is primarily used in administrative and academic reporting to enforce and analyze repeat enrollment rules. A common scenario is identifying all unit versions that are considered equivalent for repeat purposes. For instance, when a student attempts to enroll in UNIT_B, the system can check if it shares a RPT_FMLY_ID with a unit the student has already passed (UNIT_A), and thus prevent or flag a redundant enrollment. A typical query would join this table to the unit version master to list families:

SELECT rpt.repeat_code, uv.unit_cd, uv.version_number
FROM igs_ps_rpt_fmly_all rpt,
igs_ps_unit_ver_all uv
WHERE rpt.rpt_fmly_id = uv.rpt_fmly_id
AND rpt.org_id = :p_org_id
ORDER BY 1, 2;

Another critical use case is during the creation or update of a unit definition, where an administrator assigns the unit to an existing repeat family or creates a new family via this table.

Related Objects

The table maintains defined relationships with other key Student System entities, as documented in the provided metadata.

• Primary Key: The table is uniquely identified by the constraint IGS_PS_RPT_FMLY_ALL_PK on the RPT_FMLY_ID column.
• Foreign Key Relationships: The primary key (RPT_FMLY_ID) is referenced by a foreign key in the IGS_PS_UNIT_VER_ALL table. Specifically, the column IGS_PS_UNIT_VER_ALL.RPT_FMLY_ID points to IGS_PS_RPT_FMLY_ALL.RPT_FMLY_ID. This is the primary relationship, linking the repeat family definition to the actual academic units (unit versions) that belong to that family.

This structure ensures referential integrity, meaning a unit version cannot be assigned a non-existent repeat family ID, and a family cannot be deleted if unit versions are still associated with it.