Search Results known_as2




Overview
Explore in AI Chat

Overview

IGS_AD_POSTADM_MISS_ITM_LTR_V is a reporting view in the Oracle E-Business Suite (EBS) Student System (IGS) product, owned by the APPS schema. Its documented purpose is to return missing items associated with Post Admission Requirements, supporting correspondence and letter generation for admitted applicants who have outstanding admissions checklist items. The view is delivered as a VALID database object in both EBS 12.1.1 and 12.2.2 and is intended primarily for XML Publisher / BI Publisher letter templates and operational reports rather than for transactional processing.

Operationally, the view joins party-level data from the Trading Community Architecture (TCA) registry to admissions requirement data, allowing a letter template to print recipient identity, address, and the outstanding requirement description in a single query. It therefore occupies the reporting tier of the IGS architecture: it does not store data and should not be used as an update surface.

Underlying Base Objects

The ETRM metadata for 12.2.2 does not enumerate referenced base tables for this view; the documented excerpt contains only the inline view text, in which the TCA party columns are projected through the HZ alias. Based on that text, the principal contributor is the TCA party/party-site layer (HZ_PARTIES and the associated address, contact-point, and profile-denormalization objects supplying ADDRESS1–ADDRESS4, EMAIL_ADDRESS, and the currency/category columns).

The admissions "missing item" side of the query is drawn from the IGS post-admission requirements tables, which hold the checklist line definitions and the per-person completion status that determines whether an item is outstanding. Because the published metadata lists no confirmed base objects, all dependency claims beyond the HZ party projection should be validated against DBA_DEPENDENCIES in the target instance before use.

Key Columns

Common Use Cases and Queries

The dominant use case is a Post Admission Requirements letter: a concurrent program passes a person or applicant range and the template prints each outstanding item alongside the addressee's preferred name and mailing address.

SELECT person_number,
       party_name,
       known_as3,
       surname,
       given_names,
       address_line1,
       city,
       postal_code
FROM   apps.igs_ad_postadm_miss_itm_ltr_v
WHERE  person_id = :p_person_id;

A second scenario is an operational audit of outstanding post-admission items, filtered to exclude suppressed records:

SELECT person_id,
       person_number,
       party_name,
       known_as,
       known_as3,
       email_address
FROM   apps.igs_ad_postadm_miss_itm_ltr_v
WHERE  do_not_mail_flag = 'N';

Because KNOWN_AS3 is a pass-through party attribute rather than an admissions attribute, it is typically consumed only when the institution configures a third alternate-name field for legal or cultural naming conventions. Queries should always filter on PERSON_ID or the institution's applicant set to avoid a full scan of the TCA party population.