Results for “igf_sp_fc”

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

Overview

The object IGF_SP_FC is a database view belonging to the IGF – Financial Aid product family within Oracle E-Business Suite. In the ETRM (E-Business Suite Technical Reference Manual) metadata, IGF is explicitly flagged as Obsolete, which means the module is no longer actively maintained or shipped as part of the supported 12.1.1 and 12.2.2 application footprints. The view itself presents student financial aid fee classification and fee percentage data — information historically used to determine how sponsorship funds are allocated against particular fee classes for a given funding source.

The description documented in ETRM states that IGF_SP_FC is an “MO view based on IGF_SP_FC_ALL table.” The “MO” designation refers to a Multi-Org (operating unit) secured view. Its defining characteristic is that it filters rows returned from the underlying _ALL table so that a querying session sees only the records belonging to its current operating unit, as determined by the session’s client information. This pattern is standard across Oracle EBS multi-org (MO) security views, which expose an ORG_ID column and constrain it against the value stored in the session environment.

Because the object is documented as “Not implemented in this database” in the supplied ETRM excerpt, the view should be treated as a legacy or reference definition rather than a guaranteed live object in any given environment. In releases where it does exist, it functions strictly as a reporting and integration access layer, not as a transactional entity.

Underlying Base Objects

The single documented base object is the table IGF_SP_FC_ALL. The view definition selects from this table using the alias SFCL. All columns exposed by the view are projected directly from IGF_SP_FC_ALL without joins, aggregations, or calculated expressions, apart from the ROWID pseudo-column and the ORG_ID predicate.

The row-level security predicate is the only logic present in the view. It compares the base table’s ORG_ID (with a NVL fallback to -99) against a value derived from USERENV('CLIENT_INFO'). The first character of the client information string is inspected; if it is a space, NULL is returned, otherwise the first ten characters are converted to a number. This DECODE/SUBSTRB construct is the classic EBS MO initialization pattern and confirms that IGF_SP_FC is the operating-unit-secured companion to the unrestricted _ALL table. No other referenced base objects are documented in ETRM metadata.

Key Columns

• ROW_ID — the ROWID of the underlying row in IGF_SP_FC_ALL, exposing the physical row address for direct row access.
• FEE_CLS_ID — identifier of the fee classification record, typically the primary key component linking to the fee class definition.
• FUND_ID — identifier of the funding source to which the fee class allocation applies.
• FEE_CLASS — the descriptive or coded fee classification.
• FEE_PERCENT — the percentage of the fund attributable to this fee class.
• MAX_AMOUNT — a ceiling amount limiting the fee allocation for the class.
• ORG_ID — operating unit identifier; the column to which the multi-org predicate is applied.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit columns recording who created and last modified each row and when.

Common Use Cases and Queries

Typical usage is reporting on the percentage and maximum amount allocated to each fee class per fund within the currently initialized operating unit. A canonical query resembles:

• SELECT fund_id, fee_class, fee_percent, max_amount FROM igf_sp_fc WHERE fund_id = :p_fund_id; — retrieving fee class allocations for a specific funding source.
• SELECT * FROM igf_sp_fc WHERE org_id = :p_org_id; — explicit operating unit reporting, though the view already enforces MO filtering.
• Integration extracts joining FUND_ID to a fund master and FEE_CLS_ID to a fee class master to produce a complete allocation picture.

Because the view is MO-secured, the returned dataset implicitly depends on the caller’s session CLIENT_INFO; analysts comparing results across operating units must initialize the MO context appropriately or query IGF_SP_FC_ALL directly where authorized.