Search Results igs_ad_imp_matches_pp_v

Overview

IGS_AD_IMP_MATCHES_PP_V is a PL/SQL view owned by the APPS schema in the Oracle E-Business Suite Student System (IGS) product family. Its documented purpose is to retrieve person details for the admissions import process from the interface tables. It is a reporting and validation view rather than a transactional entity: it presents rows that have been staged in the IGS admissions interface tables so that the import/matching process, concurrent programs, and diagnostic reports can inspect candidate person records before they are promoted to the core person and student tables.

Because the view is defined over interface (staging) data, its contents are transient by nature. Rows appear when an external source system loads person data through the admissions interface, and they remain visible until the import process succeeds and the staging rows are purged or until the batch is rejected. The view therefore serves as a window into the state of an in-flight import batch. It is available in both Oracle EBS 12.1.1 and 12.2.2, with the same documented column list and the same owner (APPS) in each release.

Underlying Base Objects

The view text identifies three driving objects, all in the APPS schema:

• IGS_AD_INTERFACE (aliased IP) — the primary admissions interface table holding the incoming person records. The view is built from this table, so it is the outer/driving object of the join.
• IGS_AD_API_INT (aliased AI) — the alternate identifier interface table, joined on INTERFACE_ID with an outer join (+) so that person rows without alternate identifiers are retained.
• IGS_AD_STAT_INT (aliased SI) — the statistical/ethnic data interface table, also joined on INTERFACE_ID with an outer join.

The join condition is IP.INTERFACE_ID = AI.INTERFACE_ID(+) AND IP.INTERFACE_ID = SI.INTERFACE_ID(+). Both joins are outer joins, confirming that the interface person record is the root row and that missing API or statistical details do not suppress the row. The view exposes IP.ROWID as ROW_ID, which permits the calling process to address individual staging rows directly, a common requirement for corrections and cleanup during batch validation. Historical ETRM metadata records the referenced base objects as "none documented," so the definition above must be read from the view source text rather than from dependency listings.

Key Columns

• ROW_ID — the ROWID of the interface person row; used to target updates against the staging record.
• INTERFACE_ID — the batch-level key linking the person row to its alternate identifier and statistic rows.
• BATCH_ID — identifies the import batch to which the person belongs.
• PERSON_ID — the matched or proposed person identifier in the core tables.
• GIVEN_NAMES, GIVEN_NAME_1_CHAR, SURNAME, SURNAME_5_CHAR, PREFERRED_GIVEN_NAME — name attributes, with derived single-character and truncated forms used by fuzzy match routines. SURNAME_5_CHAR is explicitly defined as NULL in the view text.
• SEX, BIRTH_DT, PREF_ALTERNATE_ID — demographic and identifier attributes used in matching.
• ETHNIC_ORIGIN, PERSON_ID_TYPE, ALTERNATE_ID — sourced from the statistical and alternate identifier tables.
• CREATED_DATE — note that the view text maps IP.CREATED_BY to the column alias CREATED_DATE. This is a documented quirk: the column named CREATED_DATE actually carries the creating user identifier, while the true creation timestamp is exposed as CREATION_DATE (IP.CREATION_DATE). Users searching for "created_date" must be aware of this aliasing to avoid misinterpreting results.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns from the interface row.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context identifying the request that loaded or touched the row.

Common Use Cases and Queries

Typical use cases include pre-import validation, duplicate detection, batch reconciliation, and operational troubleshooting of stalled interface rows. Because the view is limited to staging data, queries are usually filtered by batch or by a recent creation window.

• List persons in a batch: SELECT interface_id, person_id, surname, given_names FROM igs_ad_imp_matches_pp_v WHERE batch_id = :p_batch;
• Inspect recent staging rows using the true timestamp column: SELECT interface_id, surname, creation_date, created_date FROM igs_ad_imp_matches_pp_v WHERE creation_date >= SYSDATE - 1 ORDER BY creation_date DESC;
• Identify rows without alternate identifiers or statistical detail (outer-join gaps): SELECT interface_id, person_id_type, ethnic_origin FROM igs_ad_imp_matches_pp_v WHERE person_id_type IS NULL OR ethnic_origin IS NULL;
• Trace the originating concurrent request: SELECT interface_id, request_id, program_id FROM igs_ad_imp_matches_pp_v WHERE request_id = :p_request_id;

Because the underlying objects are interface tables that are regularly purged, do not build persistent reporting on this view. Use it for validation, reconciliation, and short-window operational queries, and join to the core person tables once import has completed.