Search Results igs_uc_app_addreses

Overview

IGS_UC_APP_ADDRESES is a table within the Oracle E-Business Suite IGS (Student System) product family, documented in the ETRM reference for releases 12.1.1 and 12.2.2. The object holds UCAS Applicant Address details, capturing the correspondence and home address information supplied by applicants entering through the Universities and Colleges Admissions Service (UCAS) interface. UCAS is the United Kingdom's centralised admissions service, and the IGS module historically provided the staging and integration surface through which UCAS applicant records were received, validated, and loaded into the institution's student system.

The table is explicitly flagged as obsolete and, in the documented environment, is not implemented in the database. Its ongoing relevance is therefore archival and analytical rather than transactional: it remains part of the physical schema definition shipped with the product, and installations that were live during the UCAS integration era may still carry historical rows. The documented physical schema contains 30 columns under the IGS owner, with the primary key IGS_UC_APP_ADDRESES_PK defined on APP_NO and no foreign keys mined from the constraint structure. Based on the heuristic Data Vault classification supplied in the metadata, this object is best modelled as a standalone satellite: its rows are descriptive attributes keyed by an applicant identifier rather than relationship records or independent business hubs. The absence of documented foreign keys reinforces the staging-table character of the object, since integration tables frequently load before referential integrity to the core student model is established.

Key Information Stored

The table stores a single row of address data per UCAS applicant. The primary key, IGS_UC_APP_ADDRESES_PK, is defined on APP_NO, which serves as the surrogate applicant identifier and is the only documented unique index business-key candidate. The most significant columns fall into three functional groups.

• Correspondence address: ADDRESS_AREA, ADDRESS1, ADDRESS2, ADDRESS3, ADDRESS4, POST_CODE, and MAIL_SORT hold the structured postal address used for UCAS correspondence.
• Home address: HOME_ADDRESS1, HOME_ADDRESS2, HOME_ADDRESS3, HOME_ADDRESS4, HOME_POSTCODE, and HOME_COUNTRY_CODE mirror the correspondence fields for the applicant's permanent residence, which is frequently distinct from term-time or mailing addresses.
• Contact channels: TELEPHONE, FAX, EMAIL, MOBILE, COUNTRY_CODE, HOME_PHONE, and HOME_FAX capture voice and electronic contact points at both locations.
• Integration and audit: SENT_TO_OSS_FLAG, AD_BATCH_ID, and AD_INTERFACE_ID track transmission to the central admissions system and batch-level interface processing, while CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide standard EBS audit columns.

Common Use Cases and Queries

Because the object is obsolete, usage scenarios centre on data migration, historical reconciliation, and archival reporting rather than live admissions processing. A typical pattern retrieves the full address profile for a known applicant:

• SELECT app_no, address1, post_code, home_address1, home_postcode, email, mobile FROM igs_uc_app_addreses WHERE app_no = :app_no;
• Housekeeping queries can filter on sent_to_oss_flag to identify rows that were never confirmed as transmitted to the central system.
• Batch auditing joins rows back to their load context using ad_batch_id and ad_interface_id to reconcile interface volumes against expected UCAS submission counts.
• Data-quality reporting can compare correspondence and home address elements, flagging applicants whose post_code and home_postcode diverge across regions.

Related Objects

The mined relationship data classifies the table as standalone, with no foreign keys to or from the primary key APP_NO. The following associations are the most significant in practice:

• IGS_UC_APPLICANTS — the parent applicant staging object, joined on APP_NO, carrying applicant identity and application-level attributes.
• IGS_UC_AD_INTERFACE / IGS_UC_AD_BATCH — batch and interface control tables referenced by AD_BATCH_ID and AD_INTERFACE_ID.
• IGS_UC_APP_CHOICES — applicant course choice records, joined through APP_NO to reconstruct complete UCAS submissions.
• IGS_UC_APP_QUALIFICATIONS — qualification staging data for the same applicant identifier.
• IGS_UC_APP_PERSONAL — personal detail staging, correlated on APP_NO.
• HZ_LOCATIONS and HZ_PARTIES — the receiving party and location entities in the Trading Community Architecture model, populated when applicant data is finally promoted into the core student record.

Direct joins should be validated per installation, since the object is not implemented in the documented instance and legacy data may reside only in migrated or archived schemas.