Search Results igf_aw_fund_excl_pkg




Overview
Explore in AI Chat

Overview

The APPS.IGF_AW_FUND_EXCL_PKG package is a server-side PL/SQL API belonging to the Oracle E-Business Suite Grants Management (IGF/OA framework) product family, specifically the "IGF Award" (IGF_AW) module group. Its business function is to encapsulate data-manipulation logic for the IGF_AW_FUND_EXCL entity — the "Fund Exclusion" records that let an award restrict or exclude specific funds from eligibility. By centralizing INSERT, LOCK, DELETE, foreign-key validation, and pre-DML processing in one AUTHID CURRENT_USER package, the module enforces consistent validation and auditing behavior across every client that manipulates fund-exclusion data.

The package is classified as "OTHER" in ETRM metadata, meaning it is not the primary generated table-handler API but an auxiliary/validation package that supports entities dependent on the fund-exclusion table. The header comment ($Header: IGFWI15S.pls) indicates it originated with the Award Management 15S source set during the 2002 codebase lineage and was carried forward into EBS 12.1.1 and 12.2.2 largely unchanged.

Key Procedures and Functions

  • INSERT_ROW — Inserts a new fund-exclusion row, returning the ROWID through an IN OUT parameter and accepting the fund identifier, fund code, and a processing mode flag (defaulting to 'R', read/validate mode). This is the primary creation entry point for fund-exclusion records.
  • LOCK_ROW — Acquires a row-level lock on an existing fund-exclusion record. It is invoked in an "Update" flow so that a form or caller can hold the row while the user edits it, preventing concurrent modification.
  • DELETE_ROW — Deletes a fund-exclusion row identified by its ROWID. Because the rowid uniquely locates the physical row, the caller is expected to have obtained it via a prior INSERT or query.
  • GET_PK_FOR_VALIDATION — A BOOLEAN validation function that confirms the combination of fund identifier and fund code supplied is valid — i.e., that a corresponding primary/unique key exists. It is used to reject bad input before an insert or update.
  • GET_FK_IGF_AW_FUND_MAST — A foreign-key validation routine that verifies a supplied FUND_ID exists in the parent IGF_AW_FUND_MAST master table. This is the routine most commonly referenced by callers (including the search term that led to this document) when they need to confirm that a fund referenced by an exclusion record is a legitimate fund. It typically raises an application error when the parent key is absent.
  • GET_UFK_IGF_AW_FUND_CAT — A unique-foreign-key check validating the FUND_CODE against the fund-category reference. It ensures the fund code supplied corresponds to a defined category before the row is persisted.
  • BEFORE_DML — The central pre-processing procedure that all mutating calls pass through. It receives the DML action, the rowid, and the standard WHO columns (creation date, created by, last update date, last updated by, last update login, plus the fund_id and fund_code), performing defaulting, auditing-column population, and validation prior to the actual INSERT/UPDATE/DELETE.

Tables Accessed

The documented table is IGF_AW_FUND_EXCL_ALL (accessed through the APPS synonym), the intersection/child table that stores the award-to-fund exclusion relationships. Reads and writes against this table are performed exclusively through the API procedures above; GET_FK_IGF_AW_FUND_MAST additionally validates against the parent fund master table (IGF_AW_FUND_MAST), and GET_UFK_IGF_AW_FUND_CAT validates against the fund-category source. All access is via APPS synonyms, honoring the AUTHID CURRENT_USER stipulation.

Usage Notes

The package is typically invoked from Oracle Forms (the Award/Fund Exclusion maintenance form) and from any concurrent program or custom code that must create, lock, delete, or validate fund-exclusion rows. The standard pattern is: call LOCK_ROW when entering update mode, invoke the relevant GET_FK_* or GET_PK_FOR_VALIDATION routines to pre-validate user input, then call INSERT_ROW, update through BEFORE_DML, or DELETE_ROW to persist the change. Because three other packages reference this API, changes to callers' validation flow should account for downstream dependencies. Direct DML against IGF_AW_FUND_EXCL_ALL is discouraged, as it bypasses the foreign-key and before-DML auditing logic embedded in this package.