Search Results fee_description

Overview

The view IGS_AD_APP_REQ_V belongs to the Oracle EBS IGS — Student System product family, a module that Oracle has designated as obsolete in the 12.1.1 and 12.2.2 release streams. The view presents the admission application requirement records — effectively the applicant fee and payment details captured when a prospective student submits an admission application. Its declared purpose, per the ETRM metadata, is to "show the applicant's application requirement," which in practice means exposing the fee type, fee status, fee amount, payment method, and the associated credit-card and General Ledger accounting attributes for each application requirement row.

Because the underlying IGS tables are legacy Student System objects, the view is primarily encountered in historical reporting, migration extracts, or when investigating a column such as FEE_DESCRIPTION. The ETRM metadata explicitly records "Not implemented in this database," indicating that in many 12.1.1/12.2.2 instances the view is absent or invalid, and the documented referenced base objects list is empty.

Underlying Base Objects

The view text is defined over four objects:

• IGS_AD_APP_REQ (aliased AR) — the driving table holding the application requirement rows.
• IGS_AD_CODE_CLASSES (aliased CC1) — joined on AR.APPLICANT_FEE_TYPE = CC1.CODE_ID to resolve the fee type name and description.
• IGS_AD_CODE_CLASSES (aliased CC2) — joined on AR.APPLICANT_FEE_STATUS = CC2.CODE_ID to resolve the fee status value.
• IGS_AD_CODE_CLASSES (aliased CC3) — outer-joined on AR.FEE_PAYMENT_METHOD = CC3.CODE_ID(+), allowing null payment methods.

The single lookup table IGS_AD_CODE_CLASSES is self-joined three times to decode the fee type, fee status, and payment method code identifiers into human-readable values. The ROW_ID column is derived from AR.ROWID, and NOMINATED_COURSE_CD and SEQUENCE_NUMBER are projected as NULL placeholders.

Key Columns

• APP_REQ_ID / PERSON_ID / ADMISSION_APPL_NUMBER — identifiers linking the requirement to the person and their admission application.
• APPLICANT_FEE_TYPE / FEE_TYPE — the fee type code and its decoded name from CC1.
• FEE_DESCRIPTION — the descriptive text for the fee type, sourced from CC1.DESCRIPTION. This is the column most often searched by users looking up "fee_description."
• APPLICANT_FEE_STATUS / FEE_STATUS / DESCRIPTION — the fee status code, decoded name (CC2.NAME), and its description.
• FEE_DATE / FEE_AMOUNT — date and monetary amount of the fee.
• FEE_PAYMENT_METHOD / PAYMENT_METHOD / PAYMENT_DESCRIPTION — payment method code and decoded values from CC3.
• Credit-card columns — CREDIT_CARD_CODE, CREDIT_CARD_HOLDER_NAME, CREDIT_CARD_NUMBER, CREDIT_CARD_EXPIRATION_DATE, CREDIT_CARD_STATUS_CODE, and payee/tangible codes.
• Accounting columns — REV_GL_CCID, CASH_GL_CCID, REV_ACCOUNT_CD, CASH_ACCOUNT_CD, GL_DATE, GL_POSTED_DATE, and POSTING_CONTROL_ID.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, and REFERENCE_NUM.

Common Use Cases and Queries

The view is typically queried to report application fee collections and their accounting disposition. A representative query retrieving the fee description alongside the applicant application number is:

• SELECT ADMISSION_APPL_NUMBER, FEE_TYPE, FEE_DESCRIPTION, FEE_STATUS, FEE_AMOUNT, FEE_DATE, PAYMENT_METHOD FROM IGS_AD_APP_REQ_V WHERE FEE_DESCRIPTION IS NOT NULL;
• Filtering by applicant: ... WHERE PERSON_ID = :person_id ORDER BY FEE_DATE;
• Reconciling postings: SELECT ADMISSION_APPL_NUMBER, FEE_AMOUNT, GL_DATE, GL_POSTED_DATE, POSTING_CONTROL_ID FROM IGS_AD_APP_REQ_V WHERE GL_POSTED_DATE IS NULL;

Because the module is obsolete and the view may be unimplemented, consultants should verify existence in ALL_VIEWS before relying on it and plan migration to supported student-lifecycle equivalents.