Search Results igf_se_payment_s

Overview

IGF_SE_PAYMENT_PKG is a PL/SQL package body owned by the APPS schema within the Oracle E-Business Suite, belonging to the Oracle Grants / Federal Financials (IGF) module family that supports grant and award financial management. The package encapsulates the core DML logic for the IGF_SE_PAYMENT entity, which stores payment records associated with the Student/Fellowship payment processing flow used in grants administration. The "_SE_" prefix identifies the object as part of the Self-Service Enrollment or related student expenditure sub-module of Oracle Grants Management.

The package is classified as OTHER in the ETRM metadata, indicating it is not exposed as a formally published public API but is used internally by the application and, in practice, by integrators building extensions around the IGF payment tables. Status is VALID in the APPS schema. It is referenced by two other database objects and references numerous dependencies including IGF_SE_PAYMENT_S (the primary table synonym), IGF_SE_PAYMENT_INT, and IGF_SE_PAYMENT_INT_PKG.

Key Procedures and Functions

The package exposes eight documented procedures and functions:

• INSERT_ROW — Inserts a new row into the IGF_SE_PAYMENT table, enforcing mandatory column assignment and any defaults defined by the package.
• UPDATE_ROW — Updates an existing IGF_SE_PAYMENT record after the row has been validated and locked.
• LOCK_ROW — Issues a SELECT ... FOR UPDATE to acquire a row-level lock, preventing concurrent modification during payment processing.
• ADD_ROW — Provides a higher-level entry point that combines validation and insert operations for adding a payment record.
• DELETE_ROW — Removes a payment row, typically guarded by dependent integrity checks.
• GET_PK_FOR_VALIDATION — Retrieves the primary key of a payment record to support validation of referential relationships before DML.
• GET_FK_HZ_PARTIES — Resolves the foreign key relationship to HZ_PARTIES, returning the party identifier associated with the payment record so callers can link to the trading community registry.
• BEFORE_DML — A pre-DML hook invoked by the other procedures to enforce Who columns (created_by, creation_date, last_updated_by, last_update_date) and audit consistency.

Tables Accessed

The package touches the following tables via APPS synonyms:

• IGF_SE_PAYMENT_S — Primary entity table holding payment records; the target of INSERT, UPDATE, and DELETE operations.
• IGF_SE_PAYMENT_INT — Interface/staging table used for inbound payment data, typically before validation promotes rows to the main table.
• HZ_PARTIES — Trading community party registry; read via GET_FK_HZ_PARTIES to resolve the payee or grant recipient. To process a payment, an HIF or other interface entry must have been validated and party-derived first.
• IGF_AP_FA_BASE_REC_ALL — Stores base award/funding records referenced during validation.
• IGF_AW_FUND_MAST_ALL — Award funding master data, providing the funding source context for the payment.
• IGF_SE_AUTH — Authorization records controlling which payments are permitted.
• DUAL — Used for single-row lookups and validation queries.

Usage Notes

IGF_SE_PAYMENT_PKG is not referenced by other database objects directly (per the dependency report, it is bypassed for external referencing), but it does reference IGF_SE_PAYMENT_INT_PKG, IGS_PE_PERSON_PKG, IGS_GE_MSG_STACK, FND_MESSAGE, FND_GLOBAL, and APP_EXCEPTION. It is therefore typically invoked from the Self-Service payment forms and concurrent programs in the IGF module, as well as from custom PL/SQL code that needs to insert, update, or populate payment records from external sources. Customizations should call the DML procedures rather than issuing direct DML against IGF_SE_PAYMENT, because the package enforces the Who columns, party FK resolution, and authorization checks. Because the package body calls FND_GLOBAL, callers must ensure the FND session context (user_id, resp_id, app_id) is initialized, otherwise NameValuePair and audit column population may fail or return unexpected values. Error handling is surfaced through FND_MESSAGE and IGS_GE_MSG_STACK, so callers should inspect FND message state after any exception propagation.