Search Results referee_post




Overview
Explore in AI Chat

Overview

IGSBV_UC_APPLICANT_REFEREES is a read-only database view owned by the APPS schema within the IGS (Student System) product family of Oracle E-Business Suite. It serves as the base view for applicant reference details, exposing data captured against the UCAS (Universities and Colleges Admissions Service) applicant referees entity. The view presents a denormalised, join-resolved projection of referee information — including referee identity, the referee's professional post, establishment details, contact channels, and the applicant's personal statement — alongside the applicant-level OSS person identifier sourced from the parent applicant record.

The view is declared WITH READ ONLY, meaning it is intended exclusively for query, reporting, and integration consumption. No DML is permitted against it. In EBS 12.1.1 and 12.2.2 the object retains a VALID status in the APPS schema and is typically consumed by concurrent programs, Oracle Reports, OAF/ADF-based enquiry pages, and custom extracts that need to surface UCAS referee data without directly joining the underlying transactional tables.

Underlying Base Objects

The view is defined over two base tables, both within the IGS UCAS sub-module:

The two tables are joined on the common key APP_NO (UCAS application number), which is exposed in the view as UCAS_APPLICANT_NUMBER. This is a one-to-many relationship: a single applicant may nominate multiple referees, so each applicant row can generate several referee rows.

Key Columns

  • UCAS_APPLICANT_NUMBER — the UCAS application number (AP.APP_NO); the join key and primary reporting identifier.
  • REFEREE_NAME / REFEREE_POST — the referee's name and the professional post or title held; the referee_post value is frequently the search predicate used by downstream enquiries.
  • ESTABLISHMENT_NAME / ADDRESS1–ADDRESS4 — the referee's institution and postal address.
  • TELEPHONE / FAX / EMAIL — referee contact channels.
  • STATEMENT — the free-text reference statement supplied by the referee.
  • OSS_PERSON_IDENTIFIER — the OSS person identifier from the applicant record (FT1.OSS_PERSON_ID), linking the referee to the institutional person model.
  • PREDICTED_GRADES — predicted qualification grades associated with the reference.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — standard audit columns for row provenance and change tracking.

Common Use Cases and Queries

Typical consumption includes UCAS admissions extracts, referee verification reports, and person-linked integrations keyed on OSS_PERSON_IDENTIFIER. A representative query retrieving referees for a given applicant is:

  • SELECT ucas_applicant_number, referee_name, referee_post, establishment_name, email, oss_person_identifier FROM igsbv_uc_applicant_referees WHERE ucas_applicant_number = :p_app_no;
  • SELECT ucas_applicant_number, referee_name, referee_post FROM igsbv_uc_applicant_referees WHERE UPPER(referee_post) LIKE '%HEAD%'; — locating referees by post, a common requirement when the search term is referee_post.
  • SELECT oss_person_identifier, COUNT(*) FROM igsbv_uc_applicant_referees GROUP BY oss_person_identifier; — counting referees per applicant person.

Because the view is read-only and joins only two documented base objects, it is safe for high-volume reporting and incurs no write contention against the UCAS transactional tables.