Search Results po_match_option




Overview
Explore in AI Chat

Overview

APPS.PO_AP_RECEIPT_MATCH_V is a supplementary database view owned by the APPS schema in Oracle E-Business Suite, registered under FND Design Data as PO.PO_AP_RECEIPT_MATCH_V and SQLAP.PO_AP_RECEIPT_MATCH_V. ETRM metadata marks the object as VALID with an object type of VIEW. Its documented purpose is to simplify forms coding by joining purchasing, receiving, supplier, tax, and organizational data into a single flattened row set. Oracle explicitly warns that this is a supplementary view and does not recommend that customers query or alter data through it, because its definition may change dramatically in subsequent minor or major releases.

The view sits at the intersection of the Purchasing (PO) and Payables (AP) application modules. It exposes receipt transactions alongside the purchase order, supplier, tax, and inventory context required for receipt matching, accrual validation, and invoice-to-receipt reconciliation. In EBS 12.1.1 and 12.2.2 the view remains an internal, non-shipped construct used primarily by Oracle Forms, so it should be treated as read-only and unstable for custom development.

Underlying Base Objects

The documented referenced base objects reveal the join topology. Receiving data originates from RCV_TRANSACTIONS, RCV_SHIPMENT_HEADERS, and RCV_SHIPMENT_LINES. Purchasing data originates from PO_HEADERS, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, and PO_RELEASES_ALL. Supplier and site data come from AP_SUPPLIERS and AP_SUPPLIER_SITES_ALL. Tax and payment terms are drawn from AP_TAX_CODES_ALL and AP_TERMS. Organization and location context is resolved through ORG_ORGANIZATION_DEFINITIONS, HR_LOCATIONS_ALL_TL, HR_GENERAL, HR_SECURITY, PER_PEOPLE_F, and HR_PERSON_NAME. Lookup decoding uses AP_LOOKUP_CODES and PO_LOOKUP_CODES, while session context is supplied by FND_GLOBAL.

The view therefore behaves as a denormalized projection: one receipt transaction joined outward to its shipment header and line, inward to the purchase order and line location, and laterally to supplier, tax, and organization attributes. The use of HR_SECURITY and ORG_ORGANIZATION_DEFINITIONS implies that returned rows can be filtered by operating unit and by the security profile of the querying user.

Key Columns

Common Use Cases and Queries

Because the view is forms-oriented and unsupported for direct querying, its practical uses are limited to diagnostics, data validation, and reconciliation checks where a supported interface does not exist. A typical reconciliation query joins receipt transactions to their purchase order context for quantity verification.

SELECT rcv_transaction_id,
       rcv_transaction_date,
       rcv_transaction_quantity,
       receipt_number,
       po_number,
       po_line_number,
       item_description,
       vendor_name,
       po_uom_lookup_code,
       org_id
FROM   apps.po_ap_receipt_match_v
WHERE  org_id = :p_org_id
AND    rcv_transaction_date BETWEEN :p_start_date AND :p_end_date;

A second common scenario compares unit prices and quantities between receipts and purchase order lines before payables matching, filtering on PO_MATCH_OPTION and ACCRUE_ON_RECEIPT_FLAG to isolate accrual-relevant receipts. A third scenario validates tax setups by reviewing TAXABLE_FLAG and TAX_NAME for received items prior to invoice creation.

Any custom query against PO_AP_RECEIPT_MATCH_V should be treated as fragile. Oracle's own documentation cautions against reliance on the view, and the supported alternative is generally to build queries directly against the base purchasing and receiving tables (PO_HEADERS, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, RCV_SHIPMENT_HEADERS, RCV_SHIPMENT_LINES, and RCV_TRANSACTIONS) or to use documented public APIs and views such as the receiving inquiry interfaces.