Search Results convert_int




Overview
Explore in AI Chat

Overview

IGF_AP_PROFILE_MATCHING_PKG is an Oracle E-Business Suite PL/SQL package body owned by the APPS schema that supports the Financial Aid module of Oracle Student System (formerly Oracle iLearning/Student Information). Its principal business function is profile matching: the process of comparing incoming financial aid applicant data—captured in the CSS/ISIR interface tables—against existing person, party, and base records held in the HZ (Trading Community Architecture) and IGF financial aid tables, in order to determine whether an applicant matches an existing record, requires manual review, or must be added as a new record.

The package header carries the revision identifier $Header: IGFAP16B.pls 120.9 2006/06/30, indicating it is a shipping Oracle file. It is classified under the ETRM metadata as an "OTHER" API type rather than a formal public API, meaning it is intended primarily for internal use by the Financial Aid processing programs rather than as a published extension point. It is referenced by two other APPS packages, confirming it participates in a larger call chain. The package is documented in both Oracle EBS 12.1.1 and 12.2.2 environments, with no architectural differences between those releases for this object.

Key Procedures and Functions

The package exposes twenty documented procedures and functions. The entry point is MAIN, which orchestrates the overall matching run and drives the remaining logic. Supporting the load and reconciliation of applicant data are CREATE_FA_BASE_RECORD, CREATE_FNAR_DATA, CREATE_PERSON_RECORD, CREATE_PERSON_ADDR_RECORD, CREATE_PROFILE_MATCHED, CREATE_ADMISSION_REC, and UPDATE_CSS_INTERFACE. These routines build the base, person, address, admission, and profile-matched records, and write status back to the CSS interface.

Match-evaluation and record maintenance are handled by IS_FA_BASE_RECORD_PRESENT, UPDATE_PERSON_MATCH, and UPDATE_FA_BASE_RECORD, which determine whether a base record already exists and update person-match and base-record data accordingly. Processing paths are separated into AUTO_FA_REC, RVW_FA_REC, and UNMATCHED_REC, covering automatic matching, records routed for manual review, and unmatched applicants respectively.

Utility routines include CONVERT_INT, which returns the numeric value of a supplied character column, and REMOVE_SPL_CHR, which strips special characters from input values during comparison. Four public wrappers—SS_WRAP_CREATE_PERSON_RECORD, SS_WRAP_REFRESH_MATCHES, SS_WRAP_CREATE_BASE_RECORD, and SS_WRAP_UPLOAD_PROFILE—provide self-service invocable entry points that encapsulate the core private logic. An additional internal log_debug_message routine is retained for diagnostic tracing.

Tables Accessed

The package reads and writes the financial aid interface and staging tables IGF_AP_CSS_INTERFACE_ALL, IGF_AP_CSS_PROFILE_ALL, IGF_AP_ISIR_INTS_ALL, and IGF_AP_TD_ITEM_INST_ALL, which hold incoming applicant and profile data. Matching and record configuration are read from IGF_AP_RECORD_MATCH_ALL (via the cur_setup_score cursor), IGF_AP_MATCH_DETAILS, IGF_AP_PERSON_MATCH_ALL, IGF_AP_FA_BASE_REC_ALL, and IGF_AP_BATCH_AW_MAP_ALL, which maps batches to academic calendar and sequence information.

Person, party, and location data are maintained through the TCA tables HZ_PARTIES, HZ_PERSON_PROFILES, HZ_PARTY_SITES, HZ_LOCATIONS, and HZ_CONTACT_POINTS. Academic calendar configuration is read from IGS_AD_CAL_CONF. All references are resolved through APPS synonyms.

Usage Notes

IGF_AP_PROFILE_MATCHING_PKG is invoked from Financial Aid concurrent programs that load and match applicant data, and from self-service flows through the SS_WRAP_* wrapper procedures. Because it is classified as OTHER rather than as a public API, customizations should avoid calling the internal procedures directly; extensions should instead use the documented wrapper entry points or the concurrent program interfaces. The package maintains package-level global state—counters such as g_total_processed, g_matched_rec, g_unmatched_rec, and g_bad_rec—so it is not re-entrant across concurrent invocations within the same session. The hard-coded IP-like reference in the search string (172.16.40.1 /~meghana/) is a non-functional artifact and has no bearing on the package's behaviour.