Search Results igf_ap_fa_base_rec_s

Overview

The APPS.IGF_AP_FA_BASE_REC_PKG package body is a core data-access and maintenance component within the Oracle E-Business Suite Financial Aid (IGF) module, specifically the Application Processing (AP) sub-module that manages Financial Aid Applicant records. Its principal business function is to encapsulate the low-level DML (Insert, Update, Delete, and Lock) operations for the IGF_AP_FA_BASE_REC entity — the base record that stores the foundational financial aid application data for a student or applicant.

This package implements the standard Oracle EBS "table handler" pattern, where a generated or seeded PL/SQL package body isolates all direct manipulation of a base table and its associated sequence and view. It is classified as an OTHER API, meaning it is not a public integration API but rather an internal support package used by higher-level business logic. In EBS 12.1.1 and 12.2.2, this package ensures consistent row-level access, validation, and audit stamping against the IGF_AP_FA_BASE_REC_ALL and IGF_AP_FA_BASE_REC_S objects, while delegating cross-entity validation to a range of award, institution, person, and tax packages.

Key Procedures and Functions

The documented API surface exposes nine procedures and functions, each providing a discrete operation on the base record:

• INSERT_ROW — Inserts a new base financial aid applicant record, orchestrating the primary-key population and row-level validation.
• LOCK_ROW — Acquires a row-level lock on an existing record to guarantee concurrency control during subsequent updates or deletes.
• UPDATE_ROW — Applies changes to an existing base record, preserving the "Who" audit columns set by FND_GLOBAL.
• ADD_ROW — Provides a higher-level convenience wrapper that inserts a record and performs any required post-insert initialization.
• DELETE_ROW — Removes a base record and enforces referential integrity against dependent child objects.
• GET_PK_FOR_VALIDATION — Returns the primary key of a base record so that foreign entities can validate an association before committing.
• GET_UK_FOR_VALIDATION — Returns the unique key of a base record for uniqueness checks and duplicate prevention.
• GET_FK_IGS_CA_INST — Supplies the foreign-key relationship to IGS_CA_INST, linking the base record to the student's institution/calendar instance.
• BEFORE_DML — A shared pre-DML hook that standardizes audit stamping and validation logic invoked prior to any insert, update, or delete.

No parameter signatures are documented in ETRM metadata; consumption should reference the live package specification for argument details.

Tables Accessed

The package operates against two documented data objects plus DUAL:

• IGF_AP_FA_BASE_REC_ALL — the multi-org (ALL) base table that physically stores the financial aid applicant records; the primary target of INSERT, UPDATE, DELETE, and LOCK operations.
• IGF_AP_FA_BASE_REC_S — the corresponding sequence or single-org lookup object used for key generation and validation.
• DUAL — used for single-row SELECT expressions, sequence value retrieval, and lightweight validation calls.

Reads and writes are channelled exclusively through the APPS-synonym layer, and the package depends heavily on sibling IGF packages — such as IGF_AP_INST_VER_ITEM_PKG, IGF_AP_TAX_PKG, IGF_AP_PERS_NOTE_PKG, IGF_AW_AWARD_PKG, IGF_GR_RFMS_PKG, and IGS_PE_PERSON_PKG — for cross-entity validation and business rules.

Usage Notes

Because the package is a generated table handler, it is not intended for direct invocation by end users or external integrations. It is typically called from Financial Aid forms, concurrent programs, OAF pages, and other IGF packages that manage applicant and award processing. In EBS 12.1.1 and 12.2.2, calls flow through the higher-level IGF_AP_FA_BASE_REC_PKG specification rather than the base table, ensuring validation via BEFORE_DML and FND_MESSAGE error handling. Custom code should never bypass this package to insert or update IGF_AP_FA_BASE_REC_ALL directly, as doing so would circumvent audit stamping, concurrency locking, and downstream award, institution, and tax validations. Notably, the package is not referenced by any database object, confirming its position as a leaf-level dependency invoked by callers rather than a dependency source.