Search Results amd_id

Overview

IGF_AP_PERSON_MATCH_V is an Oracle E-Business Suite view owned by the APPS schema that supports the Oracle Grants Management / student and applicant processing functionality — specifically the person matching engine used to compare external applicant records against existing person (party) records already held in Oracle. The view consolidates header-level batch information from the person match run with line-level scoring detail from the individual match results, and enriches each row with the matched party's name and party number. Its defining characteristic is that it exposes only those match records whose header status is "REVIEW" — that is, candidates requiring human adjudication before a decision is committed.

In Oracle EBS 12.1.1 and 12.2.2, the view is most often consumed by administrative review pages, custom concurrent programs, and downstream reporting queries in which staff examine potential duplicate or uncertain person matches. Because it presents a curated "work queue" rather than the entire matching history, it serves as a stable integration point for review-oriented processing without exposing the raw match tables directly.

Underlying Base Objects

The view is defined over three base objects joined together:

• IGF_AP_PERSON_MATCH (aliased APM) — the match header, keyed by APM_ID. This object carries the batch/run context: CSS_ID, SI_ID, RECORD_TYPE, DATE_RUN, CI_CAL_TYPE, and CI_SEQUENCE_NUMBER. It is the driving table of the join and supplies the RECORD_STATUS predicate that filters the view.
• IGF_AP_MATCH_DETAILS (aliased AMD) — the per-candidate match detail, keyed by AMD_ID and linked to the header via APM_ID. It holds the person identifier being compared against and the individual match-element flags and scores, along with standard WHO audit columns.
• HZ_PARTIES (aliased PE) — the Trading Community Architecture party registry, joined on PE.PARTY_ID = AMD.PERSON_ID. It supplies the display name and party number for the matched person.

The join is an inner join throughout, so a detail row is only returned when both its parent header and its referenced party record exist. The additional predicate APM.RECORD_STATUS = 'REVIEW' restricts the result set to items pending review; records already dispositioned by the matching process are excluded.

Key Columns

• APM_ID / AMD_ID — surrogate keys for the match header and detail rows respectively; used for DML and drill-down.
• CSS_ID, SI_ID — identifiers linking the match run to its student/applicant source context.
• RECORD_TYPE, DATE_RUN — the type of match record and the timestamp of the originating run.
• CI_CAL_TYPE, CI_SEQUENCE_NUMBER — calendar type and sequence associated with the run, supporting academic-term segmentation.
• PERSON_ID — the party identifier of the candidate person being matched.
• NAME, PARTY_NUMBER — concatenation of last name, comma, first name, plus the TCA party number, providing human-readable identification.
• SSN_MATCH, GIVEN_NAME_MATCH, SURNAME_MATCH, DOB_MATCH, ADDRESS_MATCH, CITY_MATCH, ZIP_MATCH — individual element-level match indicators (typically Y/N) for each comparison attribute.
• MATCH_SCORE — the composite score produced by the matching engine, used to rank candidates.
• RECORD_STATUS — status from the detail record; the header-level status is fixed at 'REVIEW' by the view predicate.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns for traceability of the detail record.

Common Use Cases and Queries

The view is typically queried to build a review worklist ordered by descending match score, to report on match element agreement for a specific run, or to feed an adjudication screen. Because the header status predicate is embedded, no additional status filter is required.

Retrieve the pending review worklist for a given run:

• SELECT apm_id, amd_id, person_id, name, party_number, match_score, ssn_match, surname_match, dob_match FROM apps.igf_ap_person_match_v ORDER BY match_score DESC;

Analyse element-level agreement for a calendar term:

• SELECT ci_cal_type, ci_sequence_number, ssn_match, given_name_match, surname_match, dob_match, COUNT(*) FROM apps.igf_ap_person_match_v GROUP BY ci_cal_type, ci_sequence_number, ssn_match, given_name_match, surname_match, dob_match;

Drill into a specific candidate party:

• SELECT apm_id, person_id, name, party_number, match_score FROM apps.igf_ap_person_match_v WHERE person_id = :party_id;

Queries should always reference the view through the APPS synonym or a fully qualified APPS owner, and joins back to IGF_AP_PERSON_MATCH or IGF_AP_MATCH_DETAILS should use APM_ID or AMD_ID to avoid ambiguity.