Search Results igf_aw_fund_type_pkg




Overview
Explore in AI Chat

Overview

IGF_AW_FUND_TYPE_PKG is an Oracle Application Object Library package body owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It belongs to the Financial Aid module of the Oracle i-Grants/IGF product family, and its name indicates that it maintains the Fund Type reference entity used in award (AW) processing. The package encapsulates the standard EBS table-handling API pattern — a private core set of row-level DML routines wrapped by public ADD_ROW, UPDATE_ROW, and DELETE_ROW entry points — so that all inserts, updates, and deletes against the fund type tables pass through a single, validated code path. Business rules, surrogate-key and unique-key validation, concurrency control through row locking, and standardized error messaging are applied consistently regardless of whether the change originates from an Oracle Forms screen, a concurrent program, or custom PL/SQL. In the i-Grants data model, fund types classify the sources of awards and sponsored funding, and this package is the sanctioned mechanism for maintaining that classification. The body is documented as VALID in the ETRM repository and exposes eight documented procedures and functions.

Key Procedures and Functions

The documented program units conform to the Oracle Forms-generated table API convention:

  • INSERT_ROW — Performs the physical insert of a new fund type row into the base table, populating the WHO columns and enforcing mandatory attributes.
  • LOCK_ROW — Acquires a row-level lock on an existing fund type record, typically when a form initiates an update, guaranteeing pessimistic concurrency control.
  • UPDATE_ROW — Applies modifications to an existing fund type row, refining the record after it has been locked and validated.
  • ADD_ROW — Public entry point that validates the supplied fund type data and then delegates to INSERT_ROW to create the record.
  • DELETE_ROW — Public entry point that validates deletion eligibility and removes the fund type record.
  • GET_PK_FOR_VALIDATION — Resolves and returns the primary-key value for a fund type so that validation logic can confirm the row exists before a dependent operation proceeds.
  • GET_UK_FOR_VALIDATION — Resolves the unique-key combination (for example, the fund type code) used for uniqueness validation against the underlying tables.
  • BEFORE_DML — Central pre-DML hook invoked before row processing to apply shared validation, defaulting, and WHO-column stamping logic.

Tables Accessed

The package performs DML against the base table IGF_AW_FUND_TYPE_ALL, which stores the fund type definitions, and queries IGF_AW_FUND_TYPE_ALL_S, the corresponding intersection or translation table referenced through APPS synonyms. Both names are documented in the ETRM dependency list. DUAL is used for single-row PL/SQL constructs such as SYSDATE and sequence lookups. The dependency list also records references to IGF_AW_FUND_TYPE and the IGF_AW_FUND_TYPE_PKG specification, confirming that the implementation is bound to the packaged API contract. The body additionally calls APP_EXCEPTION, FND_MESSAGE, FND_GLOBAL, IGS_GE_MSG_STACK, and IGF_AW_GEN for error raising, message resolution, session context (user and login), message-stack handling, and shared general utilities, and it depends on standard PL/SQL facilities (STANDARD and PUBLIC).

Usage Notes

This API is invoked whenever fund type reference data is created or maintained — most commonly from the i-Grants setup forms, but also from concurrent programs and custom extensions that must not write directly to IGF_AW_FUND_TYPE_ALL. Callers should respect the public ADD_ROW, UPDATE_ROW, and DELETE_ROW interfaces rather than the private core routines, and should expect validation errors to be raised through FND_MESSAGE and the message stack. Because the package is not referenced by any other database object, it is purely a top-level provider API consumed by forms and external callers. In both 12.1.1 and 12.2.2, the package body remains VALID, and customization should favor wrapper code that calls the documented entry points, preserving the encapsulated validation and concurrency behavior.