Search Results igf_ap_record_match_pk

Overview

The IGF.IGF_AP_RECORD_MATCH_ALL table is a Financial Aid (IGF) configuration table in Oracle E-Business Suite 12.1.1 and 12.2.2. It defines the person attributes and matching rules that the institution uses to reconcile an incoming ISIR (Institutional Student Information Record) or Profile record against an existing person record in the system. Rather than storing students or applicants, it stores the match criteria set — the set of demographic fields to compare, the tolerance flags governing each comparison, and the score thresholds that determine whether a match is accepted automatically, routed for manual review, or rejected.

Physically the table is owned by the IGF schema and contains 30 documented columns. Its primary key is IGF_AP_RECORD_MATCH_PK on ARM_ID. Two unique indexes are defined: IGF_AP_RECORD_MATCH_U1 (ARM_ID) and IGF_AP_RECORD_MATCH_U2 (MATCH_CODE). The second index confirms MATCH_CODE as the meaningful business key, since it enforces uniqueness on the user-visible match definition code independent of the surrogate identifier.

The Data Vault classification for the table is standalone, derived heuristically from its foreign-key structure. In Data Vault modeling terms this suggests it is best treated as a reference or lookup construct — effectively a configuration hub for match rule sets — with no documented parent or child relationships in the mined FK graph. The match configuration is therefore typically consumed by matching logic rather than serving as a transactional fact or a detail satellite.

Key Information Stored

The most significant columns fall into three groups: identification, match criteria, and scoring thresholds.

• ARM_ID — the surrogate primary key (IGF_AP_RECORD_MATCH_PK) that uniquely identifies each match rule row.
• MATCH_CODE and MATCH_DESC — the unique business key and its description; MATCH_CODE is enforced by IGF_AP_RECORD_MATCH_U2.
• ORG_ID — the operating unit or organization context, supporting multi-organization installations.
• SSN, GIVEN_NAME, SURNAME, BIRTH_DT, ADDRESS, CITY, ZIP, GENDER_NUM, EMAIL_NUM — the person attributes compared during matching.
• GIVEN_NAME_MT_TXT, SURNAME_MT_TXT, BIRTH_DT_MT_TXT, ADDRESS_MT_TXT, CITY_MT_TXT, ZIP_MT_TXT, GENDER_MT_TXT, EMAIL_MT_TXT — match-type or tolerance settings that control how each corresponding attribute is compared (for example, exact match versus fuzzy match).
• MIN_SCORE_AUTO_FA and MIN_SCORE_RVW_FA — the score thresholds above which an incoming ISIR or Profile record is matched automatically, and above which it is flagged for manual review.
• ENABLED_FLAG — indicates whether the rule set is active.
• ADMN_TERM — the admission term to which the rule set applies.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS audit columns following the WHO convention.

Common Use Cases and Queries

Institutions maintain several match rule sets, typically varying by admission term or by whether automatic or review-level thresholds apply. A common operational query retrieves the active rule sets and their thresholds:

• SELECT MATCH_CODE, MATCH_DESC, ADMN_TERM, MIN_SCORE_AUTO_FA, MIN_SCORE_RVW_FA FROM IGF.IGF_AP_RECORD_MATCH_ALL WHERE ENABLED_FLAG = 'Y' ORDER BY ADMN_TERM;
• SELECT ARM_ID, MATCH_CODE, GIVEN_NAME_MT_TXT, SURNAME_MT_TXT, BIRTH_DT_MT_TXT FROM IGF.IGF_AP_RECORD_MATCH_ALL WHERE ORG_ID = :p_org_id AND ADMN_TERM = :p_term;
• SELECT COUNT(*) FROM IGF.IGF_AP_RECORD_MATCH_ALL WHERE MATCH_CODE = :p_match_code; — a validation check before inserting a new rule set.

Reporting uses include an impact analysis of threshold changes: raising MIN_SCORE_AUTO_FA increases the volume of automatic matches, while lowering MIN_SCORE_RVW_FA shifts records into manual review queues. Auditing the LAST_UPDATED_BY and LAST_UPDATE_DATE columns supports change control on these configuration rules.

Related Objects

The mined relationship data classifies this table as standalone, so no direct foreign-key parent or child is documented. In practice, the rule sets it defines are consumed by the Financial Aid matching engine that processes ISIR and Profile staging tables and drives person resolution. Administrators and DBA scripts that validate MATCH_CODE uniqueness interact with it through the IGF_AP_RECORD_MATCH_U2 index. Because the metadata records no explicit FK references, integrators should treat IGF_AP_RECORD_MATCH_ALL as a self-contained reference table and confirm actual dependencies against the deployed 12.1.1 or 12.2.2 instance before building joins.