Search Results igf_aw_fund_cat_pkg




Overview
Explore in AI Chat

Overview

IGF_AW_FUND_CAT_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. It belongs to the Oracle Grants Accounting (formerly Oracle Grants Management) module, as indicated by the IGF prefix, and operates in the Award Management and funds control domain. The package encapsulates the data-access and validation logic for the Fund Category entity, which is the classification construct used to group and validate funding sources against awards, proposals, and project transactions. In EBS 12.1.1 and 12.2.2 the package is documented with an API classification of OTHER, meaning it is an internal supporting package rather than a formally published public API. Its role is to provide a controlled insert/update/delete layer over the underlying Fund Category tables, enforce uniqueness and referential integrity, generate primary and foreign key values used during validation, and raise standardized errors through the Oracle message stack. Nine other packages reference IGF_AW_FUND_CAT_PKG, confirming that it functions as a shared lower-level service for the broader IGF award funds subsystem.

Key Procedures and Functions

The ETRM metadata documents eleven procedures and functions. They divide naturally into DML operations, validation key generators, and a pre-DML trigger handler.

  • INSERT_ROW — Performs the core insert of a Fund Category record into the base table, populating the WHO columns from FND_GLOBAL.
  • ADD_ROW — A wrapper entry point that combines row creation with the necessary validation and lock handling before committing a new Fund Category.
  • UPDATE_ROW — Applies modifications to an existing Fund Category row while preserving audit trail information.
  • DELETE_ROW — Removes a Fund Category record, typically subject to dependency checks against related fund inclusions, exclusions, and award associations.
  • LOCK_ROW — Acquires a row-level lock (SELECT FOR UPDATE) to prevent concurrent modification during validation or DML.
  • GET_PK_FOR_VALIDATION — Resolves and returns the primary key value used when validating parent-child relationships.
  • GET_UK_FOR_VALIDATION and GET_UK1_FOR_VALIDATION — Return unique key values that drive duplicate-detection and lookups against alternate unique constraints.
  • GET_UFK_IGF_AW_FUND_TYPE — Returns the unique foreign key linking a Fund Category to its Fund Type parent.
  • GET_FK_IGF_SL_CL_RECIPIENT — Returns the foreign key value referencing the recipient (awards/solicitation) side of the relationship.
  • BEFORE_DML — A trigger-support routine invoked before insert or update to set default values, validate mandatory fields, and enforce business rules before the DML statement proceeds.

Tables Accessed

The package reads and writes two base tables plus DUAL. IGF_AW_FUND_CAT_ALL is the multiorg-enabled base table holding Fund Category definitions; INSERT_ROW, UPDATE_ROW, DELETE_ROW, ADD_ROW, and LOCK_ROW all operate against it. IGF_AW_FUND_CAT_ALL_S is the corresponding intersection or security/sequence table used for key generation and validation lookups performed by GET_PK_FOR_VALIDATION, GET_UK_FOR_VALIDATION, and GET_UK1_FOR_VALIDATION. DUAL is referenced for scalar evaluations such as sequence retrieval and existence checks. Because the ALL suffix is present, all statements are filtered by the current operating unit resolved through IGS_PR_OU_FND_PKG, ensuring multiorg data isolation.

Usage Notes

IGF_AW_FUND_CAT_PKG is normally invoked indirectly. The Oracle Forms-based Fund Category maintenance windows call ADD_ROW, UPDATE_ROW, and DELETE_ROW through the form's block-level DML logic, while BEFORE_DML is fired by the database trigger attached to IGF_AW_FUND_CAT_ALL. Concurrent programs and other IGF packages — including IGF_AW_FUND_MAST_PKG, IGF_AW_FUND_TYPE_PKG, IGF_AW_FUND_INCL_PKG, IGF_AW_FUND_EXCL_PKG, IGF_AW_GEN, and the IGS proposal/award funds packages — call the GET_*_FOR_VALIDATION functions to resolve keys before validating user entries. Error conditions are surfaced through FND_MESSAGE, APP_EXCEPTION, and IGS_GE_MSG_STACK, so callers should expect standard EBS exception handling. No database object references this package, so it is safe to treat as an internal implementation detail; customizations should avoid direct calls and instead use the public Award Management APIs where available.