Results for “igs_pe_res_chg_s”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGF_AP_INST_APP is an APPS-owned PL/SQL package that belongs to the Oracle Student System (IGS) family of modules, specifically the Financial Aid / institutional application components (IGF). It was created by the developer identified as "Ulhas" on 04-JUL-2005 under the header IGFAP50S.pls (version 120.0). As stated in its embedded comments, the package's purpose is to provide "all the procedures to do the updation related to institutional applications submitted by the student." In practice, this means the package centralizes the server-side write operations that move an institutional aid application through its lifecycle: updating To-Do checklist items, changing application and status codes, maintaining anticipated (ANT) disbursement data across terms, and firing the business event that signals submission of an institutional aid application.

Within the Oracle EBS 12.1.1 and 12.2.2 releases, the package is classified in the ETRM as an OTHER API — it is not a public, file-based interface intended for external system integration, but rather an internal API layer used by the institution's own application workflows. It exposes no functions in the documented interface; all six documented entry points are procedures.

Key Procedures and Functions

• UPDATE_TODO_STATUS — Updates the To-Do status associated with an institutional application, driven by the base record identifier and application code.
• UPDATE_TODO — Sets a specific status value on the institutional To-Do item record, again keyed by base ID and application code. Where UPDATE_TODO_STATUS resets status generically, UPDATE_TODO accepts an explicit status to apply.
• UPDATE_APP_STATUS — Writes a new application status code to the application status record for the given base record and application code, advancing the application through its status progression.
• UPDATE_ANT_DATA_FOR_ALL_TERMS — Maintains anticipated (ANT) disbursement data across every term associated with the application, taking a calendar type and sequence number and a column/value pair to update, with an override flag controlling whether existing data may be replaced.
• UPDATE_ANT_DATA_A_TERM — The single-term counterpart to the procedure above; it updates one specified disbursement term using a calendar type and sequence number, a target data column, a new value, and the same override flag.
• RAISE_EVENT_ON_IA_SUBMIT — Raises the business event that marks submission of an institutional aid application, using the base ID and application code to identify the application being submitted.

Each procedure returns an x_return_status OUT parameter, the standard Oracle EBS API convention for reporting success, expected error, or unexpected error outcomes to the caller.

Tables Accessed

The procedures read and write a focused set of APPS synonyms. Core application records are held in IGF_AP_FA_BASE_REC_ALL and the status table IGF_AP_APPL_STATUS_ALL, which together drive UPDATE_APP_STATUS and the To-Do procedures. To-Do items are stored in IGF_AP_TD_ITEM_INST_ALL (instance level) with master definitions in IGF_AP_TD_ITEM_MST_ALL. Anticipated disbursement updates touch IGF_AP_FA_ANT_DATA, with calendar structure supplied by IGS_CA_INST_ALL, IGS_CA_INST_REL, and IGS_CA_TYPE. Party context comes from HZ_PARTIES, setup defaults from IGF_AP_APPL_SETUP_ALL, and IGS_PE_RES_CHG_S supports resource/charge resolution. DUAL is used for single-row utilities.

Usage Notes

Because no other package references IGF_AP_INST_APP, it is invoked directly rather than being called through a higher-level API chain. Typical callers are the Oracle Forms-based institutional aid application pages within the Financial Aid module, and institution-specific concurrent programs or custom PL/SQL that automate status changes and anticipated disbursement maintenance. Because it is classified as OTHER rather than a public API, direct custom invocation should be preceded by regression testing during upgrades between 12.1.1 and 12.2.2, and the override flag parameters on the ANT data procedures should be set deliberately to avoid overwriting institutionally entered anticipated disbursement figures.