Search Results igs_fi_govt_fund_src_pkg

Overview

The IGS_FI_GOVT_FUND_SRC_PKG package is an Oracle Application Object Library (AOL) style PL/SQL package owned by the APPS schema. It belongs to the Oracle Student System (IGS) financials product family and provides the data access layer for the Government Fund Source entity. In the Oracle E-Business Suite 12.1.1 and 12.2.2 environments, this package encapsulates the standard insert, update, delete, and locking operations required to maintain government fund source records that students use when applying financial aid, grants, or government-sponsored funding against their student accounts.

The object is registered in the E-Business Suite Technical Reference Manual (ETRM) with an API classification of OTHER and a status of VALID. Its existence as a conforming "table handler" package follows the well-established Oracle Applications Developer (AOL/Forms) pattern, in which each base table is paired with a package that centralizes DML logic, concurrency control, and constraint validation.

Key Procedures and Functions

The ETRM documents eight procedures and functions within this package. They collectively implement the CRUD lifecycle and pre-DML validation logic:

• INSERT_ROW — Inserts a new government fund source record into the base table, populating the standard WHO columns (creation date, created by, last update date, last updated by) as required by the AOL standard.
• UPDATE_ROW — Updates an existing government fund source row, applying the same WHO column maintenance and any entity-specific edits.
• DELETE_ROW — Removes a government fund source row from the base table.
• ADD_ROW — A convenience wrapper that combines row creation with the associated attribute population, typically called from a higher-level API or Forms block.
• LOCK_ROW — Acquires a row-level lock (SELECT ... FOR UPDATE) on a specific government fund source record to guarantee read-consistency and prevent lost updates during concurrent user sessions.
• GET_PK_FOR_VALIDATION — Returns the primary key of a candidate row for validation purposes, allowing callers to verify uniqueness or existence before committing a change.
• CHECK_CONSTRAINTS — Performs business-rule and referential-integrity validation prior to DML, ensuring the row satisfies the entity's constraints before it is written.
• BEFORE_DML — A pre-DML hook invoked by the other procedures to apply standard defaults, WHO stamping, and any shared validations common to all mutation paths.

Because the metadata does not enumerate parameter lists, parameter signatures are intentionally not described here; consumers should obtain the exact specification from the ETRM "show dependent code" links.

Tables Accessed

The package reads and writes the base table IGS_FI_GOVT_FUND_SRC, accessed through its APPS synonym. This table stores the master list of government funding sources (for example, federal, state, or local government grant programs) available for allocation against student financial records. All eight procedures converge on this single table: read operations for validation (GET_PK_FOR_VALIDATION, CHECK_CONSTRAINTS) and mutation operations for INSERT, UPDATE, and DELETE. No other base table is documented as a direct dependency.

Usage Notes

Like most IGS Fund Source handlers, this package is invoked behind the scenes rather than called directly by end users. Typical invocation points include:

• Oracle Forms — The Government Fund Source maintenance form triggers INSERT_ROW, UPDATE_ROW, DELETE_ROW, and LOCK_ROW as the user navigates and commits records.
• Higher-level APIs — The ETRM shows that IGS_FI_FUND_SRC_PKG references this package, meaning the parent fund-source API delegates government-specific operations to it. Custom extensions or concurrent programs should call the parent API in preference to this package where possible.
• Concurrent Programs / Interfaces — Batch loads of government fund source data may use ADD_ROW and CHECK_CONSTRAINTS for bulk validation prior to commit.

Because the package is a private data-access layer, direct calls from custom code bypass documented interfaces and are not recommended. Developers should confirm the current signature and behavior against the actual ETRM "show dependent code" output for their specific point release, since internal logic may differ between 12.1.1 and 12.2.2.