Search Results gmf_xla_vendor_v




Overview
Explore in AI Chat

Overview

GMF_XLA_VENDOR_V is a public APPS-owned view in the Process Manufacturing Financials (GMF) product family of Oracle E-Business Suite. It is registered in ETRM with status VALID and exists in both 12.1.1 and 12.2.2 releases, where it serves as a lightweight derivation layer that resolves the vendor (supplier) identity associated with a given inventory or receiving transaction. Rather than storing data itself, the view joins receiving, purchasing, and inventory tables to expose a compact three-column projection: VENDOR_ID, VENDGL_CLASS, and MMT_TRANSACTION_ID.

In 12.2.2, the view text is documented as resolving MMT.TRANSACTION_SOURCE_TYPE_ID = 1 (the "Purchase Order" source type) and using an outer join on RCV_TRANSACTIONS, so that transactions sourced directly from a purchase order header still resolve a vendor site. The view is primarily consumed by Subledger Accounting (XLA) and costing logic to determine the supplier dimension for transaction accounting entries, and it is also referenced in custom operational reporting where a vendor must be attributed to a material transaction. The MMT_TRANSACTION_ID column is the pivot: it is the join key back to MTL_MATERIAL_TRANSACTIONS, which is why users searching for that column land on this view as a bridge between inventory transactions and supplier records.

Underlying Base Objects

ETRM records the following referenced base objects for the view:

  • PO_VENDOR_SITES_ALL (view) — supplier sites and their descriptive attributes.
  • PO_HEADERS_ALL (synonym) — purchase order headers, providing the fallback vendor site when receiving transactions do not carry one.
  • RCV_TRANSACTIONS (synonym) — receiving transactions, supplying VENDOR_SITE_ID and TRANSACTION_ID for the outer-joined path.
  • MTL_MATERIAL_TRANSACTIONS (synonym) — the driving inventory/material transaction table, keyed by TRANSACTION_ID.
  • FND_GLOBAL (package) — the standard EBS session context package, typically used for organizational or user security context.

The join path is PO_VENDOR_SITES_ALL.VENDOR_SITE_ID = NVL(RCV_TRANSACTIONS.VENDOR_SITE_ID, PO_HEADERS_ALL.VENDOR_SITE_ID), with RCV_TRANSACTIONS.TRANSACTION_ID(+) = MMT.RCV_TRANSACTION_ID as an outer join and PO_HEADERS_ALL.PO_HEADER_ID = MMT.TRANSACTION_SOURCE_ID as the inner join that ties a material transaction to its originating purchase order.

Key Columns

  • VENDOR_ID — although named VENDOR_ID, this is sourced from PO_VENDOR_SITES_ALL.VENDOR_SITE_ID. It therefore represents the supplier site identifier, not the supplier header identifier from PO_VENDORS. Consumers needing the true vendor should resolve this through PO_VENDOR_SITES_ALL.
  • VENDGL_CLASS — sourced from PO_VENDOR_SITES_ALL.ATTRIBUTE1, so its meaning is implementation-defined. In GMF and XLA contexts it is typically used as a vendor GL class or supplier classification flex attribute.
  • MMT_TRANSACTION_ID — the MTL_MATERIAL_TRANSACTIONS.TRANSACTION_ID for the material transaction being enriched. This is the primary join key to inventory transaction data and the column most commonly searched.

Common Use Cases and Queries

Typical uses include attributing a supplier site to inventory transactions for procurement and receiving reconciliation, extracting vendor GL classification for accounting, and driving subledger mapping in XLA. Because the view is thin, it is generally joined back to MTL_MATERIAL_TRANSACTIONS and MTL_TRANSACTION_TYPES.

Example: list vendor context for a material transaction.

SELECT v.mmt_transaction_id, v.vendor_id, v.vendgl_class
FROM apps.gmf_xla_vendor_v v
WHERE v.mmt_transaction_id = :mmt_transaction_id;

Example: reconcile PO-sourced transactions to vendor sites.

SELECT mmt.transaction_id, mmt.transaction_date, v.vendor_id, pvs.vendor_id AS vendor_header_id
FROM apps.mtl_material_transactions mmt,
     apps.gmf_xla_vendor_v v,
     apps.po_vendor_sites_all pvs
WHERE mmt.transaction_id = v.mmt_transaction_id
  AND pvs.vendor_site_id = v.vendor_id
  AND mmt.transaction_source_type_id = 1;

Because the view contains no ORGANIZATION_ID predicate of its own, queries should filter on organization via the joined MTL_MATERIAL_TRANSACTIONS record, and access should respect EBS organization security.