Search Results report_type




Overview
Explore in AI Chat

Overview

APPS.GMD_CUST_VEND_MST_V1 is a reporting and integration view in Oracle E-Business Suite that consolidates customer and supplier (vendor) master identifiers into a single, uniformly structured result set. It belongs to the Process Manufacturing (GMD) schema family, which is reflected in the "GMD" prefix, and it is owned by the APPS schema. Its design purpose is to present a master reference list of both customers and vendors side by side, tagged by a discriminating indicator, so that downstream reports, concurrent programs, and interface routines can resolve a party to its master record without issuing separate queries against the customer and supplier tables.

Because the view is defined across both the Order Management/Receivables customer master and the Purchasing supplier master, it acts as a lightweight cross-module lookup. The most distinctive structural feature for consumers is the literal column aliased REPORT_TYPE, which is the object of the search term associated with this documentation. This column carries a hard-coded value of '0' for rows sourced from the customer master and '1' for rows sourced from the supplier master.

Underlying Base Objects

The documented view metadata identifies the following referenced base objects:

  • OP_CUST_MST (SYNONYM) — the customer master source, supplying CUST_NO and CO_CODE.
  • PO_VEND_MST (SYNONYM) — the supplier/vendor master source, supplying VENDOR_NO and CO_CODE.
  • FND_PROFILE (PACKAGE) — the Oracle Application Object Library profile option package, referenced in the dependency chain for session or environment resolution.

The view text is a UNION of two SELECT statements. Both branches filter on DELETE_MARK = 0, excluding logically deleted master records from the result. The customer branch projects CUST_NO AS "Cust_Vend_No" and the supplier branch projects VENDOR_NO AS "Cust_Vend_No", aligning the two distinct key domains into one column. The CO_CODE column is selected from each source without an alias change, and the Report_Type literal distinguishes origin.

Key Columns

  • CUST_VEND_NO — the unified master identifier. It holds CUST_NO when the row originates from OP_CUST_MST and VENDOR_NO when the row originates from PO_VEND_MST. Because the two source numbering schemes are independent, values should always be interpreted together with REPORT_TYPE.
  • CO_CODE — the company or operating unit code carried on the source master record, used to segregate master data by organization or legal entity.
  • REPORT_TYPE — the discriminator column. A value of '0' denotes a customer record; a value of '1' denotes a vendor record. This literal is emitted by the view definition itself rather than stored in either base table, so it is always consistent and requires no decoding table.

No other columns are exposed by the documented view text, which keeps the projection narrow and its purpose tightly scoped to master-number resolution and classification.

Common Use Cases and Queries

Typical uses include populating value lists or LOVs for customer/vendor selection, feeding conversion and migration reports that must enumerate both master sets, and driving discrepancy or reconciliation queries across Receivables and Purchasing master data. A baseline query retrieving all active master entries is:

SELECT cust_vend_no, co_code, report_type FROM apps.gmd_cust_vend_mst_v1 ORDER BY co_code, report_type, cust_vend_no;

To isolate only customer master entries:

SELECT cust_vend_no, co_code FROM apps.gmd_cust_vend_mst_v1 WHERE report_type = '0';

To isolate only supplier master entries:

SELECT cust_vend_no, co_code FROM apps.gmd_cust_vend_mst_v1 WHERE report_type = '1';

To count master records by type within each company code:

SELECT co_code, report_type, COUNT(*) FROM apps.gmd_cust_vend_mst_v1 GROUP BY co_code, report_type;

When joining this view to a transaction line, always constrain on both CUST_VEND_NO and REPORT_TYPE to avoid false matches between unrelated customer and supplier numbers. Because the view performs a UNION across two large master tables and filters on DELETE_MARK, queries should be restricted by CO_CODE or REPORT_TYPE wherever possible to limit full scans of both branches.