Search Results igf_sl_dl_manifest_pkg




Overview
Explore in AI Chat

Overview

The APPS.IGF_SL_DL_MANIFEST_PKG package belongs to the Oracle E-Business Suite (EBS) Financial Aid module, specifically the Student Loan (IGF) sub-module. Its name derives from the combination of IGF (the schema prefix used for the Global Financial Aid / Student Loan application), SL (Student Loan), and DL_MANIFEST, which refers to the "Direct Loan Manifest" entity. In the context of Oracle EBS 12.1.1 and 12.2.2, this package serves as the underlying PL/SQL implementation library for the Direct Loan manifest record, which is the consolidated file sent electronically to the U.S. Department of Education's Common Origination and Disbursement (COD) system.

The package is classified as an OTHER API in the ETRM documentation. This classification indicates that it is not a public, published Web ADI or PL/SQL API intended for external integration, but rather an internal, mechanism-level package whose procedures are primarily invoked by the Oracle Forms application layer and by other packages within the same module. It provides the standard CRUD (Create, Read, Update, Delete) and locking behavior typical of Oracle EBS Forms-based table handlers.

Key Procedures and Functions

The ETRM metadata lists eight documented procedures within the package:

  • INSERT_ROW — Inserts a new manifest record into the underlying table. This is the core creation procedure for a Direct Loan manifest entry.
  • LOCK_ROW — Performs a row-level lock using SELECT ... FOR UPDATE semantics, ensuring that no concurrent form session can modify the same manifest record simultaneously. This is central to the Oracle Forms optimistic locking model.
  • UPDATE_ROW — Applies changes to an existing manifest record. It updates the columns of the manifest row that were modified in the form block.
  • ADD_ROW — Adds a row to the in-memory record group or form block. It is typically invoked when the user creates a new manifest line before the physical database insert occurs.
  • DELETE_ROW — Removes an existing manifest record from the database, supporting the removal of erroneous or cancelled manifest entries.
  • GET_PK_FOR_VALIDATION — Retrieves the primary key of the manifest record for validation purposes. This supports cross-field and cross-table validation within the form.
  • GET_FK_IGF_SL_LOANS — Returns the foreign key reference to the parent loan record in IGF_SL_LOANS. This confirms the referential relationship between a manifest and the student loan(s) it reports.
  • BEFORE_DML — A pre-insert/pre-update trigger procedure that populates WHO columns (creation date, created by, last update date, last updated by) and validates mandatory attributes before the DML statement executes.

Tables Accessed

The package references the following tables through APPS synonyms:

  • IGF_SL_DL_MANIFEST_ALL — The base transactional table storing Direct Loan manifest records. The package performs the majority of its DML against this table.
  • IGF_SL_DL_MANIFEST_ALL_S — The corresponding sequence or secondary/translation table used to generate unique primary key values for new manifest rows.
  • DUAL — The standard Oracle single-row dummy table, used for lightweight lookups such as sequence value retrieval (SELECT seq.NEXTVAL FROM DUAL) and for evaluating expressions without accessing a real table.

Usage Notes

IGF_SL_DL_MANIFEST_PKG is referenced by two other packages: IGF_SL_DL_PRINT_MANIFEST and IGF_SL_LOANS_PKG. This dependency pattern confirms its role as a shared low-level data access layer. The print manifest package likely calls the retrieval procedures to gather manifest data before formatting the output file for COD transmission, while the loans package invokes the foreign-key and validation procedures to maintain referential integrity between a loan and its manifest.

In practice, the package is invoked indirectly by the Oracle Forms-based Direct Loan Manifest window. Developers extending the module should not call these procedures directly unless replicating the form's DML behavior, because the standard Forms block already manages the required sequencing, WHO column population, and locking. Any custom concurrent program or interface that needs to create manifest records should prefer the documented public API or the loan-level package, rather than this internal handler, to avoid bypassing validation logic.