Search Results gmd_cust_vend_mst_v1




Overview
Explore in AI Chat

Overview

GMD_CUST_VEND_MST_V1 is a read-only database view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the GMD product family — Process Manufacturing Product Development. The view presents a consolidated list of master-level business partners, exposing both customers and vendors through a single, uniform result set. Its defining characteristic is a synthetic discriminator column, REPORT_TYPE, which allows a consumer to distinguish whether a given row originated from the customer master or the vendor master. The customer number is emitted under the unified alias CUST_VEND_NO, and the operating unit context is carried through the CO_CODE column. In Oracle EBS reporting and integration scenarios the view functions as a lightweight abstraction layer: instead of writing separate queries against OP_CUST_MST and PO_VEND_MST and manually unioning the results, a report developer or interface can select from one object and filter or branch on REPORT_TYPE. The view is documented as VALID in ETRM metadata and is therefore supported for reference and diagnostic purposes. It contains no procedural logic, no substitution variables, and no reference to FND_PROFILE at the SQL level, so its behaviour is purely deterministic and driven by filter predicates applied at runtime.

Underlying Base Objects

The view is a straight UNION of two base objects, both accessed through APPS synonyms:

  • OP_CUST_MST — the Process Manufacturing customer master. Rows are drawn from the columns CUST_NO and CO_CODE, restricted by the predicate DELETE_MARK = 0.
  • PO_VEND_MST — the purchasing vendor master. Rows are drawn from VENDOR_NO and CO_CODE, again restricted by DELETE_MARK = 0.

Because the two branches are combined with UNION rather than UNION ALL, duplicate row combinations of CUST_VEND_NO, CO_CODE, and REPORT_TYPE are suppressed, though in practice the REPORT_TYPE literal keeps the two branches distinct. The metadata lists FND_PROFILE (PACKAGE) among referenced objects; this association reflects the broader report context in which the view is invoked (for example, operating unit or report-type profile lookups performed by the calling concurrent program) rather than any dependency inside the view SQL itself. No joins to descriptive or address tables are present, which keeps the view narrow and inexpensive but means callers requiring customer or vendor names must join to the respective master tables independently.

Key Columns

  • CUST_VEND_NO — the business identifier. When REPORT_TYPE is '0' it holds the customer number from OP_CUST_MST.CUST_NO; when REPORT_TYPE is '1' it holds the vendor number from PO_VEND_MST.VENDOR_NO. The value is exposed as a single column precisely so that downstream logic need not care which master supplied it.
  • CO_CODE — the company or operating unit code associated with the customer or vendor record, taken unchanged from both source tables. It provides the organisational partition used to scope reports.
  • REPORT_TYPE — a character literal forming the discriminator: '0' for customer-sourced rows and '1' for vendor-sourced rows. It is a constant, not a stored attribute, and therefore cannot be used for update or drill-back to a single master table.

Common Use Cases and Queries

Typical use is in concurrent programs and BI Publisher reports that must present a single validated list of customer or vendor numbers to the user, with the report type driven by a parameter. A basic query retrieving the customer branch is:

SELECT CUST_VEND_NO, CO_CODE FROM APPS.GMD_CUST_VEND_MST_V1 WHERE REPORT_TYPE = '0' ORDER BY CUST_VEND_NO;

To obtain the vendor branch, change the predicate to REPORT_TYPE = '1'. To retrieve both populations while retaining their origin — for example when populating a validation LOV or an interface staging table — select all three columns without a filter. When the report must be restricted to a single operating unit, add WHERE CO_CODE = :p_co_code, optionally combined with the report type. Because the view returns only identifiers, a display query that also needs names or status must join the output back to OP_CUST_MST or PO_VEND_MST on the appropriate number column, carefully choosing the join target based on REPORT_TYPE. All access should occur under the APPS schema or a synonym with suitable grants; the view is not intended for DML.