Results for “alternate_code”

50+ results




Overview
Explore in AI Chat

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGS_EN_REG_UPD_INT is an interface (staging) table within the Oracle E-Business Suite Student System module (IGS), documented for releases 12.1.1 and 12.2.2. It belongs to the enrollment registration processing area and holds inbound registration-date update records prior to validation and transfer into the production student registration structures. The table is classified as obsolete in current ETRM documentation, and its DBA data records it as not implemented in this database, meaning the object is a legacy artifact retained for historical and upgrade reference rather than an active processing component.

Functionally, the table acts as a transient holding area: each row captures a single student registration-date update along with its processing context. Rows are not free-standing — they must correspond to a batch recorded in IGS_EN_REG_BTCH_INT, which provides the batch-level control record and error aggregation for the enrollment interface run. Under the heuristic Data Vault classification supplied with the metadata, this object is modeled as standalone, with no mined foreign-key dependencies to other entities. As a modeling suggestion rather than a physical constraint, that classification indicates the table can be treated as an independent staging entity, though its batch association is defined by convention through BATCH_ID rather than enforced by a documented foreign key.

Key Information Stored

The documented physical schema contains 16 columns. The most significant are the following.

  • BATCH_ID — Identifier of the parent batch in IGS_EN_REG_BTCH_INT. Part of the composite primary key.
  • REGISTRATION_ID — Identifier of the student registration record being updated. The second component of the composite primary key.
  • PERSON_NUMBER — The student's person number, used to resolve the individual against the person/student structures.
  • COURSE_CD — Course code associated with the registration line being updated.
  • ALTERNATE_CODE — Alternate identifier for the course or registration, typically used for cross-system reconciliation.
  • ENR_FORM_RECEIVED_DT — Date the enrollment or registration form was received, the principal business attribute this interface exists to convey.
  • ERRORS — Error text or code captured during validation, indicating why a row failed processing.
  • REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE — Concurrent program context identifying the request and program that processed or will process the row.
  • CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard Oracle EBS audit columns recording insert and update provenance.

The surrogate primary key is the unique index IGS_EN_REG_UPD_INT_PK, defined on (BATCH_ID, REGISTRATION_ID). Because that same index is the only documented unique business-key candidate, the batch/registration pair serves simultaneously as the row's technical identity and its natural uniqueness rule; no separate surrogate identifier column is documented.

Common Use Cases and Queries

Historically, this table supported bulk loading and correction of enrollment form receipt dates, with validation performed in batch before records were applied to live registration data. Typical investigation and reconciliation patterns include identifying batches that produced errors, verifying that every staged row resolves to a valid batch, and reporting on incoming registration volumes by date.

  • Listing error rows for a batch: SELECT REGISTRATION_ID, PERSON_NUMBER, COURSE_CD, ERRORS FROM IGS_EN_REG_UPD_INT WHERE BATCH_ID = :batch_id AND ERRORS IS NOT NULL;
  • Confirming batch-row correspondence against the parent interface table: SELECT b.BATCH_ID, COUNT(u.REGISTRATION_ID) FROM IGS_EN_REG_BTCH_INT b, IGS_EN_REG_UPD_INT u WHERE b.BATCH_ID = u.BATCH_ID GROUP BY b.BATCH_ID;
  • Auditing an update by registration: SELECT BATCH_ID, ENR_FORM_RECEIVED_DT, LAST_UPDATE_DATE, LAST_UPDATED_BY FROM IGS_EN_REG_UPD_INT WHERE REGISTRATION_ID = :registration_id;
  • Reconciling processing requests: SELECT REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, COUNT(*) FROM IGS_EN_REG_UPD_INT GROUP BY REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID;

Because the table is obsolete and absent from the running database, such queries are relevant mainly for legacy data extraction, historical migration analysis, or documentation of pre-upgrade interfaces.

Related Objects

The relationship set is dominated by the batch interface: rows here must correspond to entries in the batch table.

  • IGS_EN_REG_BTCH_INT — The batch parent interface table; joined on BATCH_ID. Every row must correspond to a batch.
  • IGS_EN_REG_INT — The enrollment registration interface table, the sibling staging entity for registration data.
  • HZ_PERSON / student person structures — Resolved via PERSON_NUMBER for student identity verification.
  • IGS_EN_REGISTRATIONS — The production registration entity that staged rows are intended to update.
  • FND_CONCURRENT_REQUESTS / FND_CONCURRENT_PROGRAMS — Joined on REQUEST_ID and PROGRAM_ID/PROGRAM_APPLICATION_ID for concurrent processing context.
  • FND_USER — Joined on CREATED_BY and LAST_UPDATED_BY for audit traceability.