Results for “match_id”

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

Overview

INL_CORR_MATCHES_V is a PL/SQL view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the INL - Oracle Landed Cost Management product. It presents corrected information about matches between actual and estimated amounts on a Landed Cost Shipment. Landed Cost Management reconciles estimated charges captured at shipment or receipt time against the actual invoice amounts subsequently received from suppliers and carriers. Each reconciliation produces a row in the matching infrastructure, and this view exposes the effective, corrected version of those rows.

The view is not a simple projection of a single table. It is a self-referencing query over matches in which a correction match (an adjustment record) is coalesced against its original match. Through NVL and DECODE constructs, the view returns a single logical record per match that reflects the most current values for adjustment group date, matched amount, currency, and processing flags. Because it derives these values dynamically from the underlying match data and applies currency conversion rules through the Landed Cost private package, the view is the authoritative source for reporting and downstream integration processes that require corrected match amounts rather than raw staging values.

Underlying Base Objects

The view is defined over the match data maintained by Landed Cost Management, exposed to the APPS schema through the INL_MATCHES synonym referenced in the ETRM metadata. The query aliases two instances of this underlying match source as MAT1 and MAT2: MAT1 supplies the base match row, and MAT2 supplies the corresponding correction or adjustment row when one exists. The join between the two instances is keyed on the match relationship, and the DECODE on MATCH_ID populates CORRECTION_MATCH_ID only when the adjustment row differs from the base row.

The view also references the INL_LANDEDCOST_PVT package. This package is invoked through its CONVERTED_AMT function, which converts the corrected matched amount from the correction's currency into the base match's currency using the conversion type and conversion date carried on the base record. This dependency means the view cannot be queried successfully if INL_LANDEDCOST_PVT is invalid; the view's VALID status therefore implies both underlying objects are compiled and accessible.

Key Columns

• MATCH_ID - Unique identifier of the base match record.
• CORRECTION_MATCH_ID - Identifier of the correcting match, returned as NULL when the row is not itself a correction.
• ADJ_GROUP_DATE - Adjustment group date, taking the correction's value when present via NVL.
• MATCH_TYPE_CODE, SHIP_HEADER_ID - Match classification and the owning Landed Cost shipment header.
• FROM_PARENT_TABLE_NAME / FROM_PARENT_TABLE_ID - Source entity (table name and primary key) from which the match originates, such as a purchase order or receipt line.
• TO_PARENT_TABLE_NAME / TO_PARENT_TABLE_ID - Target entity to which the match is applied. The TO_PARENT_TABLE_ID column is the key value most frequently used to link match rows back to the charged parent document.
• MATCHED_QTY, MATCHED_UOM_CODE - Corrected matched quantity and unit of measure.
• MATCHED_AMT, MATCHED_CURR_CODE, MATCHED_CURR_CONVERSION_TYPE, MATCHED_CURR_CONVERSION_DATE, MATCHED_CURR_CONVERSION_RATE - Corrected matched amount and the currency attributes used to convert it when the correction currency differs.
• ADJ_ALREADY_GENERATED_FLAG, EXISTING_MATCH_INFO_FLAG, REPLACE_ESTIM_QTY_FLAG - Processing flags controlling whether adjustments have been generated and how existing match information is treated.
• CHARGE_LINE_TYPE_ID, PARTY_ID, PARTY_SITE_ID, TAX_CODE, NREC_TAX_AMT, TAX_AMT_INCLUDED_FLAG - Charge, party, and tax attributes of the match.
• MATCH_AMOUNT_ID - Identifier of the associated match amount record.
• Audit columns - PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE, REQUEST_ID, CREATED_BY, CREATION_DATE.

Common Use Cases and Queries

A frequent requirement is to retrieve corrected matches for a specific Landed Cost shipment, optionally filtering to only those rows that carry a correction. The following query returns all corrected matches for a shipment:

• SELECT match_id, correction_match_id, matched_amt, matched_curr_code, to_parent_table_name, to_parent_table_id FROM apps.inl_corr_matches_v WHERE ship_header_id = :p_ship_header_id;

To isolate corrections only, add WHERE correction_match_id IS NOT NULL. This pattern supports reconciliation reporting that compares estimated versus actual landed cost and highlights variances.

Because the view exposes FROM_PARENT_TABLE_NAME and TO_PARENT_TABLE_NAME alongside their identifiers, another common scenario is resolving the parent document that a match references. Filtering on to_parent_table_id allows the caller to locate every corrected match applied to a given parent record, regardless of the parent type encoded in TO_PARENT_TABLE_NAME.

• SELECT match_id, ship_header_id, matched_amt, matched_qty FROM apps.inl_corr_matches_v WHERE to_parent_table_id = :p_parent_id AND to_parent_table_name = :p_parent_table;

Integration and diagnostic queries frequently inspect the processing flags, for example SELECT match_id, adj_already_generated_flag, existing_match_info_flag FROM apps.inl_corr_matches_v WHERE adj_already_generated_flag = 'N';, to identify matches whose adjustments remain outstanding. Dashboard-style reporting aggregates MATCHED_AMT by MATCHED_CURR_CODE or by ADJ_GROUP_DATE to summarize corrected landed cost by period. All such queries depend on the corrected amount logic embedded in the view, which guarantees that the correction's value and converted currency are returned in preference to the base match values.