Search Results igs_fi_fee_as_all




Overview
Explore in AI Chat

Overview

The IGS_FI_FEE_AS_ALL table is a core data entity within the Oracle E-Business Suite (EBS) Student System (IGS), specifically within the Financials module. Its primary function is to record and manage fee assessments levied against an individual (student) for a specific fee liability within a defined fee category. This table acts as the central transactional record linking a person to their assessed financial obligations, forming the basis for invoicing, payment tracking, and financial reporting. It is a multi-org table, as indicated by the "_ALL" suffix, meaning it stores data for multiple operating units with the ORG_ID column controlling data access and security. Notably, the ETRM documentation explicitly marks the IGS Student System as "Obsolete," indicating this table belongs to a legacy product line that may have been superseded or is in the process of being retired in EBS 12.1.1 and 12.2.2.

Key Information Stored

The table's structure is designed to uniquely identify a fee assessment and its context. The primary key is a composite of PERSON_ID and TRANSACTION_ID, ensuring a unique record per assessment transaction for an individual. Critical foreign key relationships define the assessment's scope. The PERSON_ID links to HZ_PARTIES, identifying the student. The combination of FEE_CAT, FEE_CAL_TYPE, FEE_CI_SEQUENCE_NUMBER, and FEE_TYPE links to IGS_FI_F_CAT_FEE_LBL_ALL and IGS_FI_F_TYP_CA_INST_ALL, defining the exact fee category, calendar type, instance, and fee type for which the liability is assessed. The COURSE_CD column, linked to IGS_PS_COURSE, may associate the assessment with a specific academic program. Other typical columns in such a table would include assessment amounts, due dates, assessment dates, status flags (e.g., assessed, cancelled, invoiced), and the ORG_ID.

Common Use Cases and Queries

This table is central to student financial operations. Common use cases include generating student invoices, producing outstanding balance reports, analyzing fee revenue by category or course, and auditing assessment history. A typical query might join to party and course tables to retrieve a student's assessed fees for a given term. For example:

  • Retrieve Assessments for a Student: SELECT f.* FROM igs_fi_fee_as_all f WHERE f.person_id = :p_person_id AND f.fee_cal_type = :p_term_code;
  • Report on Total Assessed Fees by Category: SELECT fee_cat, SUM(assessed_amount) FROM igs_fi_fee_as_all WHERE org_id = :p_org_id AND assessment_date BETWEEN :p_from_date AND :p_to_date GROUP BY fee_cat;
  • Find Assessments for Invoicing: Queries would typically filter on a status column (e.g., STATUS = 'ASSESSED') to identify fees ready to be billed.

Direct querying should be done with caution, as business logic is often encapsulated in higher-level APIs.

Related Objects

The ETRM metadata defines clear relationships for this table. It is a parent to the IGS_FI_FEE_AS_ITEMS table, which likely holds line-level details for each assessment. Its primary dependencies are as a child table, referencing:

  • HZ_PARTIES: For the student's identity.
  • IGS_FI_F_CAT_FEE_LBL_ALL: For the fee liability definition within a category.
  • IGS_FI_F_TYP_CA_INST_ALL: For the fee type and calendar instance details.
  • IGS_PS_COURSE: For the associated academic course (if applicable).

Given its role, it is also intrinsically linked to invoicing (AR), payment, and general ledger interfaces within the financials flow. Any custom reporting or integration involving student fee assessments would likely reference this table.