Search Results igs_en_rep_process




Overview
Explore in AI Chat

Overview

IGS_EN_REP_PROCESS is a configuration table in the Oracle E-Business Suite Student System (IGS) product family. Its documented purpose is to store the setup details for Repeat Processing, the mechanism by which an institution defines how repeated course attempts are evaluated for academic standing, credit accumulation, and funding eligibility. Each row in the table represents a single repeat-processing rule set, typically scoped to an institution and an organizational unit.

The table resides in the IGS schema and is marked VALID in the documented ETRM metadata. It carries 15 columns and is identified by the primary key constraint IGS_EN_REP_PROCESS_PK, which is defined on the REPEAT_PROCESS_ID column. One foreign key relationship is documented: ORG_UNIT_ID references HZ_PARTIES, tying the repeat rule to the Oracle Trading Community Architecture party model used to represent organizational units.

From a heuristic Data Vault modeling perspective, the mined foreign-key structure classifies this object as satellite-leaning. In practice, that suggests treating it as a descriptive, attribute-bearing structure linked to a business key rather than as an independent hub or a pure association table.

Key Information Stored

The table separates its surrogate identity from its business configuration attributes. The most significant columns documented in the ETRM metadata are:

  • REPEAT_PROCESS_ID — the surrogate primary key, generated to uniquely identify each repeat-processing setup record.
  • INSTITUTION_CD and ORG_UNIT_CD — the institution and organizational unit codes that scope the rule; together these act as the principal business-key candidates.
  • ORG_UNIT_ID — the foreign key to HZ_PARTIES, providing the internal identifier of the owning organizational unit.
  • INCLUDE_ADV_STANDING_UNITS — controls whether units attempted under advanced standing are counted toward repeat logic.
  • MAX_REPEATS_FOR_CREDIT — the maximum number of repeat attempts counted for academic credit.
  • MAX_REPEATS_FOR_FUNDING — the maximum number of repeat attempts eligible for funding.
  • USE_MOST_RECENT_UNIT_ATTEMPT — determines whether the most recent attempt governs the outcome.
  • USE_BEST_GRADE_ATTEMPT — determines whether the highest grade achieved governs the outcome.
  • EXTERNAL_FORMULA — holds an externally supplied formula reference used when standard repeat logic must be overridden.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Oracle EBS audit columns capturing record provenance and change history.

Common Use Cases and Queries

Registrar and student-records teams use this table to verify which repeat policy applies to a given organizational unit before processing grade changes, transcript recalculation, or funding extracts. A typical lookup joins the setup row to its owning party:

  • Retrieve the active rule set for an institution and unit: SELECT * FROM igs.igs_en_rep_process WHERE institution_cd = :p_inst AND org_unit_cd = :p_unit;
  • Resolve the organizational unit description via the documented FK: SELECT r.repeat_process_id, p.party_name FROM igs.igs_en_rep_process r, hz_parties p WHERE r.org_unit_id = p.party_id;
  • Audit repeat-credit ceilings across units: SELECT org_unit_cd, max_repeats_for_credit, max_repeats_for_funding FROM igs.igs_en_rep_process;
  • Identify rules relying on non-standard logic: SELECT repeat_process_id, external_formula FROM igs.igs_en_rep_process WHERE external_formula IS NOT NULL;

Reporting use cases include policy-compliance extracts, configuration baselines for implementations, and reconciliation of funding-eligibility rules against institutional policy.

Related Objects

  • HZ_PARTIES — referenced through ORG_UNIT_ID; supplies the organizational unit identity.
  • IGS_EN_REP_PROCESS_PK — the primary key constraint on REPEAT_PROCESS_ID.
  • IGS_EN_REP_PROCESS (base table) — the central setup record consumed by repeat-processing logic and inquiry forms.

Other IGS student-system entities — including enrollment, unit attempt, and grade records — depend on this configuration at runtime, though additional foreign-key relationships are not enumerated in the supplied ETRM metadata.