Search Results igs_ad_ps_apintunths




Overview
Explore in AI Chat

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGS_AD_PS_APINTUNTHS is a secure (Organization Unit–stripped) view owned by the APPS schema in the Oracle E-Business Suite IGS (Student System) product family. It presents historical admissions application instance unit data for prospective students, derived from the underlying table IGS_AD_PS_APINTUNTHS_ALL. The view exposes dated history records — captured between HIST_START_DT and HIST_END_DT — that track changes to a nominated admissions unit associated with a person's application.

The primary functional role of the view is to enforce multi-organization (Org ID) security at query time. Rather than forcing each report, form, or concurrent program to implement its own operating-unit filter, the view applies a WHERE predicate that dynamically resolves the current organization from the USERENV('CLIENT_INFO') session context. It matches the ORG_ID column against this resolved value (defaulting to -99 when the client information is unavailable). Because the view name omits the _ALL suffix, it is the intended object for user-facing queries, while the corresponding _ALL table remains the base object for administrative and data-load operations.

Underlying Base Objects

The view is defined solely over the base table IGS_AD_PS_APINTUNTHS_ALL, the "all organizations" table that stores application instance unit history rows without any operating-unit restriction. The relationship is one-to-one; every row returned by the view corresponds to a single row in the base table possessing an ORG_ID that satisfies the security predicate. The generated view text selects each column explicitly and aliases the ROWID of the base table as ROW_ID, giving consuming forms and APIs a stable identifier for row-level operations. No additional joins, other tables, or documented secondary base objects are present in the view definition; the security logic is a pure self-contained filter applied at query time rather than a stored relational structure.

Key Columns

The view exposes 29 columns covering keys, context, and audit attributes:

Common Use Cases and Queries

The view is typically used for admissions history reporting, auditing changes to nominated units, and integration extracts that must respect the caller's operating unit. A typical query filters on person or application and orders by history date:

  • Applicant unit history: SELECT person_id, admission_appl_number, unit_cd, adm_unit_outcome_status, hist_start_dt, hist_end_dt FROM igs_ad_ps_apintunths WHERE admission_appl_number = :p_appl ORDER BY hist_start_dt;
  • Outcome-status change audit: SELECT person_id, unit_cd, adm_unit_outcome_status, last_updated_by, last_update_date FROM igs_ad_ps_apintunths WHERE hist_start_dt >= :p_from_date; to identify status transitions within a period for a given operating unit.
  • Integration extract: join PERSON_ID to applicant master tables and filter on HIST_END_DT IS NULL (or the desired effective window) to obtain current nominated-unit records for downstream interfaces.

Because ORG_ID is automatically constrained by the view, developers need not add an organization predicate explicitly; the session's operating unit context determines the visible rows. When rows are missing, the CLIENT_INFO setting or ORG_ID value on the base table is normally the cause.