Search Results max_repeats_for_credit




Overview
Explore in AI Chat

Overview

IGS_EN_REP_PROCESS_V is a seeded Oracle E-Business Suite view owned by the APPS schema and delivered as part of the IGS (Student System) product family. It exposes the repeat processing rules configured for a student's organizational unit, translating the underlying transaction table's internal foreign keys into human-readable attributes. The view presents one row per repeat process record, joined to the organizational unit description, providing reporting and integration consumers with a denormalized representation of repeat policy configuration. The view is documented as VALID in ETRM metadata for release 12.2.2 and remains compatible with 12.1.1.

Because repeat rules govern credit accrual, funding eligibility, advanced standing treatment, and grade-attempt selection, the view is frequently referenced by academic records reporting, institutional research extracts, and integration interfaces that must resolve repeat policy to an organizational context. The user search term "org_unit_id" maps directly to the view's most prominent join column.

Underlying Base Objects

The view is defined over two base objects within the IGS schema, both accessed by the APPS synonym layer:

  • IGS_EN_REP_PROCESS ERP — the primary repeat process table, supplying the repeat process identifier, policy flags, and standard WHO columns.
  • IGS_OR_UNIT IOU — the organizational unit table, supplying ORG_UNIT_CD and DESCRIPTION.

The defining SQL joins the two tables on ERP.ORG_UNIT_ID = IOU.PARTY_ID (+). The outer join operator (+) on the IGS_OR_UNIT side makes organizational unit details optional; repeat process rows whose org unit cannot be resolved still appear, with ORG_UNIT_CD and DESCRIPTION returned as NULL. This is significant when diagnosing orphaned repeat process setup. The ETRM metadata lists no other referenced base objects; the documented view text is the authoritative source for the join relationship.

Note that IGS_OR_UNIT is keyed by PARTY_ID (the HZ_PARTIES party identifier), not by a surrogate organization ID. This distinction matters for every query that filters on organizational context.

Key Columns

Common Use Cases and Queries

Typical consumption includes validation reporting that detects repeat processes lacking a valid organizational unit, configuration extracts for institutional policy review, and integration payloads that must publish repeat thresholds per organizational unit.

List repeat processes for a specific organizational unit:

SELECT repeat_process_id, org_unit_cd, description,
       max_repeats_for_credit, max_repeats_for_funding
FROM   apps.igs_en_rep_process_v
WHERE  org_unit_id = :p_org_unit_id;

Detect repeat process rows with unresolved organizational units:

SELECT repeat_process_id, org_unit_id, last_updated_by, last_update_date
FROM   apps.igs_en_rep_process_v
WHERE  org_unit_cd IS NULL;

Audit recent configuration changes across all organizational units:

SELECT org_unit_cd, repeat_process_id, use_best_grade_attempt,
       last_updated_by, last_update_date
FROM   apps.igs_en_rep_process_v
WHERE  last_update_date >= :p_since_date
ORDER  BY last_update_date DESC;

Always qualify the view with the APPS schema and observe the ORG_UNIT_ID-to-PARTY_ID relationship when joining outward to organizational or party tables.