Search Results igf_ap_isir_matched_s

Overview

IGF_AP_ISIR_MATCHED_PKG is the PL/SQL package body that supports the ISIR Matched Records entity within the Oracle E-Business Suite Financial Aid module (IGF). In Oracle EBS 12.1.1 and 12.2.2, this package implements the DML logic layered over the IGF_AP_ISIR_MATCHED table, which stores ISIR (Institutional Student Information Record) records that have been matched against student and person data. The package belongs to the APPS schema and is classified as OTHER (a supporting DML package rather than a public business API). Its principal role is to centralize the row-level insert, lock, update, and delete operations required by the ISIR matching process, including the specialized handling needed for distinct ISIR record types.

The package sits at the intersection of the student financial aid data model and the Oracle Trading Community Architecture (TCA) person model. It depends on related packages such as IGF_AP_ISIR_CORR_PKG, IGF_AP_NSLDS_DATA_PKG, IGF_AW_GEN, and IGS_PE_RELATIONSHIPS_PKG, reflecting its participation in ISIR correction processing, NSLDS data exchange, award generation, and person-relationship maintenance. The documented dependency list shows nine packages referencing this package, confirming that it functions as a shared internal service rather than an isolated component.

Key Procedures and Functions

The package exposes eight documented procedures. Their names describe standard table-API responsibilities:

• INSERT_ROW — Inserts a single row into the ISIR matched entity, applying the defaulting and validation logic required before the record is persisted.
• LOCK_ROW — Acquires a row-level lock to support concurrency control during multi-step update transactions.
• UPDATE_ROW — Applies changes to an existing matched-record row, encapsulating the update semantics for the entity.
• DELETE_ROW — Removes a matched-record row, including any associated enforcement of delete preconditions.
• ADD_ROW — A higher-level convenience procedure that coordinates insertion logic, typically wrapping INSERT_ROW with derived or defaulted values.
• GET_PK_FOR_VALIDATION — Returns the primary key value so that callers or validation routines can confirm or reference the row being processed.
• BEFORE_DML — A shared pre-processing routine that executes standard derivations and validations prior to any insert, update, or delete operation.
• UPDATE_ROW_RECTYPE — A specialized update used to manage the record type attribute on the matched ISIR row, supporting the record-type-specific processing inherent to ISIR data.

Because ETRM does not publish parameter signatures, callers should obtain argument details from the actual PL/SQL source or the corresponding public synonym/view definitions.

Tables Accessed

The package operates against the ISIR matched entity through its base table and related synonyms: IGF_AP_ISIR_MATCHED, IGF_AP_ISIR_MATCHED_ALL, and IGF_AP_ISIR_MATCHED_S. It also reads or writes data in the financial aid base record structures IGF_AP_FA_BASE_REC and IGF_AP_FA_BASE_REC_ALL. For person and relationship data it depends on HZ_PARTIES and HZ_RELATIONSHIPS in TCA, together with the organization alternate identifier structures IGS_OR_ORG_ALT_IDS and IGS_OR_ORG_ALT_IDTYP. DUAL is referenced for basic SQL scaffolding. These accesses support the package's mandate: linking inbound ISIR data to identified persons and organizations while maintaining the matched-record attributes used downstream by aid processing.

Usage Notes

Like other generated EBS table-handler packages, IGF_AP_ISIR_MATCHED_PKG is typically invoked indirectly. ISIR matching is driven by concurrent programs and batch processing that ingest ISIR files, compare them against student records, and write the matched results. The >S view (IGF_AP_ISIR_MATCHED_S) and the >_ALL table indicate a multi-org or localization-aware design, so the package is commonly called from forms or OA Framework pages via the entity's view object rather than from custom code. When extending or troubleshooting ISIR matching in 12.1.1 or 12.2.2, developers should treat this package as the authoritative DML layer and avoid direct table manipulation, respecting BEFORE_DML and the standard procedures to preserve validation and concurrency behavior.