Search Results igs_uc_enq_details




Overview
Explore in AI Chat

Overview

IGS_UC_ENQ_DETAILS is a table within the IGS (Student System) product family of Oracle E-Business Suite, documented for releases 12.1.1 and 12.2.2. The table belongs to the obsolete IGS UCAS integration area, which supported the exchange of applicant data between Oracle EBS and UCAS (the United Kingdom Universities and Colleges Admissions Service). The table holds the basic person details for a UCAS applicant making an Extra or Clearing application — two UCAS admission routes that operate outside the main application cycle and require rapid capture of applicant identity and contact information.

The ETRM documentation explicitly notes that the object is not implemented in the documented database, meaning it exists as a defined schema object rather than an actively populated one in that environment. Its primary key, IGS_UC_ENQ_DETAILS_PK, is defined on the APP_NO column. Based on the heuristic Data Vault classification mined from the foreign key structure, the object is characterized as standalone. In Data Vault modeling terms, this suggests treating IGS_UC_ENQ_DETAILS as a hub-like construct: a single business key (APP_NO) with no documented foreign key dependencies, rather than a link or satellite.

Key Information Stored

The documented physical schema contains 19 columns owned by the IGS schema. The most significant columns are:

  • APP_NO — the surrogate primary key (IGS_UC_ENQ_DETAILS_PK) and the applicant identifier used to relate the record to the wider UCAS application process.
  • SURNAME — the applicant's family name.
  • GIVEN_NAMES — the applicant's forenames.
  • PREFIX — a name prefix such as Mr, Mrs, Ms, or Miss.
  • SEX — the applicant's recorded gender.
  • BIRTH_DT — date of birth, used for identity verification and eligibility checks.
  • ADDRESS_LINE1 through ADDRESS_LINE4 — the structured correspondence address.
  • COUNTRY — country component of the address.
  • POSTCODE — postal code, a critical field for UK domicile and fee-status determination.
  • EMAIL — electronic contact address.
  • TELEPHONE — voice contact number.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard Oracle EBS audit columns recording insert and update accountability.

No unique business-key index beyond the primary key is documented, so APP_NO acts as both surrogate and business key in practice.

Common Use Cases and Queries

Typical usage centres on extracting and reconciling Extra and Clearing applicant records. A simple lookup by applicant number is the most common pattern:

  • SELECT app_no, surname, given_names, birth_dt, postcode, email FROM igs_uc_enq_details WHERE app_no = :app_no;
  • Reporting on Clearing intake volumes by country or postcode region using GROUP BY country or a postcode prefix filter.
  • Contact-quality audits, identifying records missing EMAIL or TELEPHONE.
  • Data-migration or integration scripts feeding applicant details into student records.
  • Audit queries filtering on creation_date or last_update_date to track when Enquiry records were loaded.

Related Objects

Because the table is classified as standalone, no foreign key relationships are documented. Related objects are therefore inferred from functional context rather than enforced constraints:

  • IGS_UC_ENQ_DETAILS_PK — the primary key constraint on APP_NO.
  • Other IGS UCAS integration tables keyed by APP_NO, such as application-choice and enquiry-header tables within the same obsolete module.
  • IGS student and person tables that receive applicant data after conversion.
  • UCAS interface staging tables and concurrent programs that load Enquiry extracts.
  • Standard audit and DBA views over the IGS schema.

As the product is obsolete, references should be validated against the actual database before use in any 12.1.1 or 12.2.2 environment.