Results for “igf_ap_st_inst_appl_all”

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

Overview

The IGF_AP_ST_INST_APPL_ALL table resides in the IGF product family, historically designated Financial Aid and now classified as Obsolete within Oracle E-Business Suite 12.1.1 and 12.2.2. The table stores the answers — that is, the values supplied by applicants — for all user-defined questions configured against a financial aid application. Where the setup tables define which questions exist and how they behave, this table captures the transactional responses associated with a specific institutional application record.

The ETRM metadata notes that the object is "Not implemented in this database," indicating that in the reference environment the physical table was absent, though the documented schema and relationship model remain authoritative for installations where the module is deployed. From a modeling perspective, the heuristic Data Vault classification mined from the foreign-key structure is link. This suggests the table behaves principally as an associative construct connecting base applicant records, question definitions, and application contexts, with the stored answer value treated as descriptive payload rather than an independent hub attribute.

Key Information Stored

The documented physical schema comprises eleven columns. The most significant are summarized below.

• INST_APP_ID — the surrogate primary key, enforced by IGF_AP_ST_INST_APPL_ALL_PK and mirrored by the unique index IGF_AP_ST_INST_APPL_ALL_U1. It uniquely identifies each stored question response.
• BASE_ID — foreign key referencing IGF_AP_FA_BASE_REC_ALL, tying the answer to the underlying financial aid base record.
• QUESTION_ID — foreign key referencing IGF_AP_APPL_SETUP_ALL, identifying the user-defined question being answered.
• QUESTION_VALUE — the actual response captured for the question; the substantive content of the row.
• APPLICATION_CODE — identifies the application context and participates in the unique key IGF_AP_ST_INST_APPL_ALL_UK alongside BASE_ID and QUESTION_ID.
• ORG_ID — the operating unit / multi-org partition column supporting row-level security.
• CREATED_BY, CREATION_DATE — standard audit columns recording row creation.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns capturing the most recent modification and its session context.

The business-key candidate IGF_AP_ST_INST_APPL_ALL_UK spans BASE_ID, QUESTION_ID, and APPLICATION_CODE, meaning a given question may be answered once per base record and application code. The surrogate INST_APP_ID should not be exposed as a business identifier; reporting should rely on the unique key columns.

Common Use Cases and Queries

Typical usage centers on retrieving applicant-supplied responses for review and reporting. A straightforward pattern joins the question definition to display prompts alongside values:

• Extracting all answers for a base record: SELECT QUESTION_ID, QUESTION_VALUE FROM IGF_AP_ST_INST_APPL_ALL WHERE BASE_ID = :p_base_id ORDER BY QUESTION_ID;
• Resolving question text: join to IGF_AP_APPL_SETUP_ALL on QUESTION_ID to obtain the question label.
• Auditing changes within a date range using LAST_UPDATE_DATE and LAST_UPDATED_BY.
• Multi-org filtered reporting, always constraining by ORG_ID to respect operating unit security.
• Detecting incomplete applications by comparing expected questions against stored responses for a given APPLICATION_CODE.

Because the module is obsolete, new development is discouraged; existing extracts are typically read-only and used for historical or compliance reporting.

Related Objects

• IGF_AP_FA_BASE_REC_ALL — parent base record; joined via BASE_ID.
• IGF_AP_APPL_SETUP_ALL — question configuration; joined via QUESTION_ID.
• IGF_AP_ST_INST_APPL_ALL — self-referencing relationship documented through BASE_ID and APPLICATION_CODE, reflecting the unique business key.
• APPLICATION_CODE — a role-based reference resolving to the application definition rather than a discrete physical table in the documented metadata.

These relationships confirm the table's position as a linking entity between applicant base records and configured questions, consistent with its link classification.