Search Results get_fk_igf_ap_fa_base_rec

Overview

IGF_AP_TAX_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that encapsulates the data manipulation logic for the IGF_AP_TAX_ALL table. The package supports the Oracle Grants / Federal financials tax reporting component of the EBS Financials family, where IGF_AP_TAX_ALL stores tax amounts and adjusted gross income (AGI) figures associated with a base record. The header declares the package with AUTHID CURRENT_USER, meaning that all unqualified object references are resolved using the privileges of the invoking user rather than the definer, consistent with standard Oracle Forms-generated table handler packages.

The package follows the classic Oracle Forms server-side table handler pattern: a single table (IGF_AP_TAX_ALL), a primary-key validation function, a foreign-key validation procedure, an internal before_dml routine that applies WHO columns, and the standard INSERT/UPDATE/DELETE/LOCK/ADD operations. Its API classification is OTHER, indicating it is an internal supporting package rather than a formally published public API. The source header (IGFAI20S.pls, version 115.4, dated 2002) confirms its long-standing presence across EBS releases, including 12.1.1 and 12.2.2.

Key Procedures and Functions

The package exposes eight documented procedures and functions:

• INSERT_ROW — Inserts a new row into IGF_AP_TAX_ALL, accepting the base identifier, taxes paid, AGI, and a mode flag. Designed for use when the row does not already exist.
• LOCK_ROW — Re-queries the identified row to obtain a row-level lock, typically invoked before an update to detect concurrent modification.
• UPDATE_ROW — Updates the tax and AGI values of an existing row identified by its ROWID, with a mode flag controlling validation behavior.
• ADD_ROW — Inserts the row if it does not exist and updates it if it does, providing the dual-purpose behavior used by Oracle Forms blocks.
• DELETE_ROW — Removes the row identified by the supplied ROWID.
• GET_PK_FOR_VALIDATION — Returns a Boolean indicating whether a row exists for the supplied base identifier, supporting primary-key validation.
• GET_FK_IGF_AP_FA_BASE_REC — Validates that the base identifier supplied corresponds to an existing parent record in the base-record table, thereby enforcing the foreign-key relationship required before tax data can be written. This is the routine returned for the user's search term.
• BEFORE_DML — Internal helper that populates the standard WHO audit columns (creation date, created by, last update date, last updated by, last update login) and applies action-specific logic ahead of the DML statements.

Tables Accessed

The only documented table referenced through APPS synonyms is IGF_AP_TAX_ALL, the transaction table that stores the tax-paid and adjusted-gross-income values keyed by base identifier. All insert, update, delete, and lock operations target this table. The foreign-key validation procedure implicitly depends on the parent base-record table (IGF_AP_FA_BASE_REC) to verify referential integrity, though the excerpt only names IGF_AP_TAX_ALL explicitly. The package is referenced by one other package, confirming it is a leaf-level table handler rather than a driver of cross-module processing.

Usage Notes

IGF_AP_TAX_PKG is typically invoked from an Oracle Forms-based maintenance screen whose base table is IGF_AP_TAX_ALL. The form's block triggers call LOCK_ROW, UPDATE_ROW, INSERT_ROW, ADD_ROW, and DELETE_ROW respectively, while GET_PK_FOR_VALIDATION and GET_FK_IGF_AP_FA_BASE_REC are called from validation triggers to enforce primary- and foreign-key integrity before DML is committed. Direct invocation from concurrent programs or custom PL/SQL is uncommon; where custom code must manipulate tax records, the supported route is generally through the surrounding Grants/AP integration rather than through this internal handler. Because AUTHID CURRENT_USER is in force, callers must hold the necessary privileges on IGF_AP_TAX_ALL and its parent. The package should be treated as internal and subject to change between patch levels, and any direct use in custom code should be validated against both 12.1.1 and 12.2.2 environments.