Search Results interface_fee_id

Overview

The IGS_AD_FEE_INT table is a core interface (staging) object within the Oracle E-Business Suite IGS — Student System product family. Its documented purpose is to hold admission fee details that need to be imported for an application. Rather than serving as a permanent transactional ledger, it functions as a temporary holding area in which fee records are loaded, validated, and ultimately transferred into the base admission fee tables by a concurrent import process. In Oracle EBS Release 12.1.1 and 12.2.2, such interface tables are the standard mechanism for bulk data ingestion from external sources — legacy systems, third-party admission portals, or flat-file extracts — before the data is cleansed and committed to the production schema.

From a data modeling perspective, the metadata classifies this object heuristically as a standalone entity within the Data Vault classification scheme. In Data Vault terms this suggests treating IGS_AD_FEE_INT as neither a strict hub, link, nor satellite, but rather as an independent staging structure. This is consistent with its role: it is a transient import artifact whose business keys are resolved during the load into the core model rather than persisting as durable business-key anchors.

Key Information Stored

The table is documented with 24 physical columns and is uniquely keyed by the primary key constraint IGS_AD_FEE_INT_PK, defined on the surrogate INTERFACE_FEE_ID column. The most significant columns include:

• INTERFACE_FEE_ID — the surrogate primary key uniquely identifying each staged fee row.
• INTERFACE_APPL_ID — the foreign key linking this fee record to its parent application row in IGS_AD_APL_INT.
• APPLICANT_FEE_TYPE_ID and APPLICANT_FEE_STATUS_ID — describe the category and processing status of the admission fee.
• FEE_DATE and FEE_AMOUNT — the date the fee applies and the monetary value to be imported.
• REFERENCE_NUM and MATCH_IND — external reference identifiers and the matching indicator used to reconcile staged rows.
• STATUS, ERROR_CODE, and ERROR_TEXT — the outcome columns populated after validation, flagging rows that fail import.
• INTERFACE_RUN_ID and DUP_APP_REQ_ID — correlate the staging batch and any duplicate-application handling.
• PERSON_ID and ADMISSION_APPL_NUMBER — identify the applicant and the human-readable admission application number.
• REQUEST_ID, PROGRAM_ID, and the WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) — standard Oracle EBS concurrent-program and audit stamping columns.

Common Use Cases and Queries

The primary use case is batch import of admission fees. A typical workflow loads external data into IGS_AD_FEE_INT, runs the admission fee import concurrent program, and inspects STATUS, ERROR_CODE, and ERROR_TEXT to triage rejections. Reporting queries commonly filter failed rows or correlate fees to applications.

A representative query joins the interface table to its parent interface application table:

• SELECT f.INTERFACE_FEE_ID, f.FEE_AMOUNT, f.STATUS, f.ERROR_TEXT FROM IGS_AD_FEE_INT f WHERE f.STATUS = 'E';
• SELECT a.ADMISSION_APPL_NUMBER, f.FEE_AMOUNT FROM IGS_AD_FEE_INT f, IGS_AD_APL_INT a WHERE f.INTERFACE_APPL_ID = a.INTERFACE_APPL_ID;

Other scenarios include reconciliation against REFERENCE_NUM, duplicate detection via DUP_APP_REQ_ID, and tracking import batches by INTERFACE_RUN_ID.

Related Objects

The documented foreign key relationship ties this table most directly to the following:

• IGS_AD_APL_INT — the parent application interface table, joined on INTERFACE_APPL_ID.
• IGS_AD_FEE_INT_PK — the primary key constraint enforcing uniqueness on INTERFACE_FEE_ID.
• IGS core admission fee tables — receiving objects targeted by the import process (via PROGRAM_ID / REQUEST_ID concurrent context).
• Concurrent program and request metadata tied through REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, and PROGRAM_UPDATE_DATE.
• IGS person and applicant reference data resolved via PERSON_ID and APPLICANT_FEE_TYPE_ID.

Records are transient by design and are typically purged or marked after a successful import run.