Search Results igf_aw_fund_tp_pkg

Overview

The package body APPS.IGF_AW_FUND_TP_PKG is a table-handler (TP, or "table-processing") package within the Oracle E-Business Suite 12.1.1 / 12.2.2 Grants Management (IGF) module. It encapsulates the Data Manipulation Language (DML) logic for the IGF_AW_FUND_TP_ALL entity, which stores awarding-fund type and related setup information. In the Oracle EBS architecture, TP packages serve as database-side gateways that the Oracle Forms client invokes through the server-side Forms infrastructure, ensuring that inserts, updates, deletes, and locking operations against base tables are centralised in a single PL/SQL layer rather than being issued directly from the form. The package is owned by the APPS schema and is documented as VALID (compiled and usable). Its API classification is recorded as OTHER, reflecting that it supports internal, framework-driven table maintenance rather than a published business API. The package is not referenced by any other database object, confirming it is a terminal dependency.

Key Procedures and Functions

The ETRM metadata documents nine procedures/functions:

• INSERT_ROW — Inserts a new row into the underlying fund type table, populating the WHO columns and key attributes from the values passed by the calling form or program.
• LOCK_ROW — Acquires a row-level lock on the record being edited, using a SELECT ... FOR UPDATE pattern, to protect against concurrent modification during a Forms session.
• UPDATE_ROW — Applies modified column values to an existing fund type row, updating the auditing columns accordingly.
• ADD_ROW — Provides an overloaded convenience entry point that creates a row and returns the newly generated primary key, typically used in programmatic or non-Forms contexts.
• DELETE_ROW — Removes the specified fund type record, supported by the appropriate cleanup semantics.
• GET_PK_FOR_VALIDATION — Returns the primary key value for a candidate record, allowing the framework to validate that the row exists before performing dependent operations.
• GET_FK_IGS_CA_INST — Retrieves the foreign key reference to the IGS_CA_INST (calendar instance) entity, which underpins date-effectivity handling for the fund type record.
• GET_FK_IGF_AW_FUND_MAST — Retrieves the foreign key reference to the IGF_AW_FUND_MAST (awarding fund master) entity, linking the fund type detail to its parent fund record.
• BEFORE_DML — A pre-DML hook invoked before any insert, update, or delete; it performs validation, derives derived/defaulted values, and raises application errors through the message stack where business rules are violated.

No parameter lists are documented in the ETRM metadata, and none should be assumed.

Tables Accessed

The documented base table is IGF_AW_FUND_TP_ALL, accessed through the APPS synonym. All of the procedural logic above operates against this table: INSERT_ROW and ADD_ROW create records, UPDATE_ROW modifies them, DELETE_ROW removes them, LOCK_ROW locks them, and the GET_PK/GET_FK routines resolve key relationships. Dependent lookups against IGF_AW_FUND_MAST and IGS_CA_INST are performed via the referenced packages IGF_AW_FUND_MAST_PKG and IGS_CA_INST_PKG respectively, rather than direct joins, preserving encapsulation of those other entities.

Usage Notes

IGF_AW_FUND_TP_PKG is packaged as a dependency of the award fund type maintenance form within Oracle Grants Management. It is invoked during interactive form sessions when a user creates, edits, or deletes a fund type record, and its ADD_ROW / GET_PK_FOR_VALIDATION routines are also suitable for call from custom concurrent programs, PL/SQL scripts, or integration interfaces that need to seed or validate award fund type data. Its dependencies on APP_EXCEPTION, FND_GLOBAL, FND_MESSAGE, and IGS_GE_MSG_STACK indicate heavy use of the standard EBS error-handling and message dictionary infrastructure, meaning errors raised by BEFORE_DML are surfaced as standard EBS messages with application context. Because the package is not referenced by any other database object and is classified as OTHER, it should be treated as an internal implementation utility: direct modification is not supported, and any custom code should call the documented procedures rather than issuing DML against IGF_AW_FUND_TP_ALL.