Results for “po_vtrd_cls”

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

Overview

PO_VTRD_CLS is a reference (lookup) table owned by the GML schema and delivered as part of the Process Manufacturing Logistics module in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented description is "Vendor trade class," indicating that it stores the controlled vocabulary of trade classifications that can be assigned to vendor records. Trade classes are used to segment suppliers by commodity, regulatory category, or commercial grouping so that procurement, logistics, and reporting processes can filter and aggregate vendor populations consistently.

The table is a low-volume, slowly changing reference object. It holds one row per vendor trade class and is referenced by the vendor master rather than referencing transactional data. The mined Data Vault classification is satellite-leaning, which is consistent with its structure: VENDTRADE_CLASS acts as the business key and the primary key, while the remaining descriptive and audit columns behave as satellite attributes. Under that classification, PO_VTRD_CLS would be modelled as a reference satellite (or a small hub carrying descriptive attributes) keyed on the trade class code, with the descriptive text and audit columns attached as dependent attributes. A separate hub is not strictly required where the code itself is the durable identifier.

Key Information Stored

Ten columns are documented. The most significant are:

• VENDTRADE_CLASS — the primary key column, defined by the unique index PO_VTRD_CLS_PK. It is the business-key candidate and the value stored on vendor records.
• VENDTRADE_CLASS_DESC — the human-readable description of the trade class, used in list-of-values displays and reports.
• TEXT_CODE — a foreign key to PO_TEXT_HDR, associating the trade class with an Oracle Text or notes template so that supplementary descriptive text can be attached.
• TRANS_CNT — a transaction count column typical of GML reference tables, used to record usage or ordering.
• DELETE_MARK — the soft-delete flag; rows are logically removed rather than physically deleted, so queries must filter on this column.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard EBS audit columns capturing who inserted and last changed the row and when, plus the login context of the last update.

The surrogate-versus-business-key distinction is straightforward here: PO_VTRD_CLS_PK is a unique index over VENDTRADE_CLASS, meaning the primary key is the natural business key and no separate surrogate identifier exists. The audit columns follow the ORACLE standard "WHO" column conventions.

Common Use Cases and Queries

The primary use case is validation and enumeration of trade classes for the vendor master. A typical lookup returning active classes is:

SELECT vendtrade_class, vendtrade_class_desc
FROM   gml.po_vtrd_cls
WHERE  delete_mark = 0
ORDER  BY vendtrade_class;

A frequent reporting pattern joins the class to vendors to count suppliers per trade class:

SELECT c.vendtrade_class, c.vendtrade_class_desc, COUNT(*) vendor_count
FROM   gml.po_vtrd_cls c, gml.po_vend_mst v
WHERE  v.vendtrade_class = c.vendtrade_class
  AND  c.delete_mark = 0
GROUP  BY c.vendtrade_class, c.vendtrade_class_desc;

Other scenarios include populating a list of values for the vendor setup form, auditing which classes are unused before cleanup, and resolving the TEXT_CODE to retrieve associated notes via PO_TEXT_HDR. Because the table is a reference object, reports should always apply the delete_mark filter and, where relevant, restrict to classes actually in use.

Related Objects

• PO_VEND_MST — the vendor master. PO_VEND_MST.VENDTRADE_CLASS references PO_VTRD_CLS.VENDTRADE_CLASS; this is the principal dependent table and the main consumer of the trade class values.
• PO_TEXT_HDR — text header table. PO_VTRD_CLS.TEXT_CODE references PO_TEXT_HDR, supplying descriptive text templates for a trade class.
• PO_VTRD_CLS_PK — the unique index (primary key constraint) on VENDTRADE_CLASS that enforces uniqueness of the class code.

The documented relationship set is deliberately narrow: one inbound foreign key from the vendor master and one outbound foreign key to the text header. Any other object that appears to reference trade classes does so indirectly through PO_VEND_MST, which should therefore be the focus of impact analysis when trade class values are added, changed, or logically deleted.