Search Results application_source

Overview

IGSBV_UC_APPLICANTS is a base view owned by the APPS schema in the Oracle E-Business Suite Student System (IGS) product family. It exposes applicant-level detail originating from the UCAS (Universities and Colleges Admissions Service) integration used by UK higher-education institutions. The view is registered as VALID in ETRM 12.2.2 and presents a denormalised, report-friendly projection of the UCAS applicant record, exposing the applicant identifier, personal identifier, UCAS applicant number and check digit, application source, application date, fee payer information, qualification flags, choice and reply status, and a substantial set of derived UCAS-specific attributes.

Its principal role is analytical and integration-oriented: it provides a stable read interface over the base UCAS applicant table without requiring consumers to know the physical column names or to join supporting lookups. Because it is a view rather than a table, no data is stored in it; all rows are resolved at query time from the underlying base objects. This makes it suitable for concurrent-program extracts, Discoverer or BI Publisher reports, and inbound/outbound interfaces that need a flat applicant record.

Underlying Base Objects

The ETRM documentation for this view does not enumerate referenced base objects, listing "none documented." The view definition, however, is a single-table projection: every column is qualified by the alias AP, which points to the UCAS applicant base table in the IGS schema (the physical table commonly named IGS_UC_APPLICANTS or its UCAS staging equivalent). No joins, unions, or sub-queries appear in the documented view text; each output column is a direct column-to-column alias.

Consequently, the relationship between the view and its base object is one-to-one at the row level. There is no aggregation and no filtering predicate documented, so the row count of the view equals the row count of the underlying applicant table. Any row-level security, organisation security, or multi-org policy applied to the base table is inherited unchanged by the view. Because the view renames columns rather than combining them, it also serves as a decoupling layer: if the base table columns are reorganised during patching, the view can be recompiled to preserve the public column names used by downstream reports.

Key Columns

• APPLICANT_ID (AP.APP_ID) — Surrogate primary key of the applicant record.
• PERSONAL_ID — Link to the person record, enabling joins to person and party tables.
• UCAS_APPLICANT_NUMBER / UCAS_APPLICANT_CHECK_DIGIT — The external UCAS reference and its check digit.
• APPLICATION_DATE — Date the application was created; the column users most commonly search on.
• APPLICATION_SENT_DATE / APPLICATION_SENT_RUN — When the application was transmitted to UCAS and the batch run that sent it.
• APPLICATION_SOURCE — Indicates the originating channel (for example electronic versus paper).
• FEE_PAYER_CODE / FEE_TEXT / DOMICILE_CODE — Fee assessment and domicile attributes used for fee-status reporting.
• APPLICANT_STATUS, FIRM_CHOICE_NUMBER, FIRM_REPLY, INSURANCE_REPLY — Choice and reply tracking, including confirmation-history variants.
• Qualification flags — WINTER_A_LEVELS, PREVIOUS_QUALS, BTEC_FLAG, ILC_FLAG, AILC_FLAG, IB_FLAG, OTHER_EXAMINATION_QUAL_FLAG, plus the corresponding moved dates.
• WITHDRAAWN / WITHDRAAWN_DATE, RELEASE_TO_CLEARING_REASON, ROUTE_B_FLAG — Status and clearing indicators.
• RESIDENTIAL_CATEGORY, PERSONAL_STATEMENT, CRIMINAL_CONVICTIONS_FL — Sensitive applicant attributes requiring restricted access.

Common Use Cases and Queries

The most frequent requirement is to retrieve applicants by application date, either for a reporting period or for reconciliation against a UCAS transmission file.

SELECT applicant_id, ucas_applicant_number, application_date,
       application_sent_date, applicant_status
FROM   apps.igsbv_uc_applicants
WHERE  application_date BETWEEN :p_from AND :p_to
ORDER  BY application_date;

Fee and domicile analysis joins the fee-payer attributes to the person record, while qualification-flag queries count applicants by examination type for admissions planning. Withdrawal and clearing reporting uses WITHDRAAWN and RELEASE_TO_CLEARING_REASON. Because the view is a straight projection, queries remain efficient when TRUNC(application_date) is avoided and bind variables are used on the indexed base column. Access should be granted through the APPS schema, respecting the sensitivity of the personal statement and criminal convictions columns.