Results for “po_vend_asc”

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

Overview

PO_VEND_ASC is a table owned by the GML schema and is part of the Oracle Process Manufacturing Logistics (OPM Logistics) product family. It stores vendor association and relationship records, allowing the E-Business Suite to model hierarchy, affiliation, and grouping relationships between vendor master records. Rather than treating each supplier as an isolated entity, PO_VEND_ASC captures the many-to-many links that describe how one vendor relates to another, together with the semantic classification of that relationship through the ASSOC_TYPE column.

From a Data Vault modeling perspective, the heuristic classification attached to this table is link. This is consistent with its structure: it joins two references to the vendor master table (VEND_ID and ASSOCVEND_ID) within a single row and carries a relationship-type discriminator. In a Data Vault design this table would naturally be modeled as a link table connecting two vendor hub records, with descriptive attributes handled separately.

The table is present and valid in both EBS 12.1.1 and 12.2.2. The documented physical schema contains 15 columns, and the table is defined in the GML schema rather than the more commonly accessed PO or AP schemas, which is an important consideration when building queries and views.

Key Information Stored

The primary key is PO_VEND_ASC_PK, defined over the composite of VEND_ID, ASSOCVEND_ID, and ASSOC_TYPE. This is the business-key candidate in the documented schema; there is no separate single-column surrogate identifier listed. The key columns and their roles are:

• VEND_ID — identifies the primary vendor in the relationship. Foreign key to PO_VEND_MST.
• ASSOCVEND_ID — identifies the associated (secondary) vendor. Foreign key to PO_VEND_MST.
• ASSOC_TYPE — the relationship classification that distinguishes one type of vendor association from another, and which forms part of the primary key.
• TEXT_CODE — foreign key to PO_TEXT_HDR, linking the association to descriptive text stored in the text header table.
• TRANS_CNT — a transaction counter, typically used for optimistic locking or record version tracking.
• DELETE_MARK — soft-delete indicator; records are logically removed rather than physically deleted.

The remaining columns are standard Oracle EBS audit and concurrent-program columns: CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, and REQUEST_ID. These support auditing, row-level change tracking, and traceability back to the concurrent request that created or modified the row.

Common Use Cases and Queries

The most frequent use of PO_VEND_ASC is reporting on vendor relationships — for example, identifying parent/affiliate structures, preferred vendor groupings, or supplier networks used for sourcing and purchasing analysis. A typical query joins both vendor references back to the master table to resolve vendor names:

• Query the primary vendor's associations: SELECT a.VEND_ID, a.ASSOCVEND_ID, a.ASSOC_TYPE FROM GML.PO_VEND_ASC a WHERE a.DELETE_MARK = 0 AND a.VEND_ID = :p_vend_id;
• Resolve names for both sides of the relationship by aliasing PO_VEND_MST twice — once on VEND_ID and once on ASSOCVEND_ID.
• Retrieve the descriptive text associated with a link by joining TEXT_CODE to PO_TEXT_HDR.

Because DELETE_MARK is present, all reporting queries should filter on DELETE_MARK = 0 to exclude logically deleted associations. Analysts integrating OPM vendor data into a warehouse commonly use PO_VEND_ASC as the source for a vendor-relationship link table, feeding a Data Vault or dimensional model alongside PO_VEND_MST.

Related Objects

The following objects have documented relationships with PO_VEND_ASC:

• PO_VEND_MST — referenced twice, via ASSOCVEND_ID and VEND_ID, providing both the associated and primary vendor master records.
• PO_TEXT_HDR — referenced via TEXT_CODE, supplying descriptive text for the association.
• PO_VEND_ASC_PK — the primary key constraint on (VEND_ID, ASSOCVEND_ID, ASSOC_TYPE).
• PO_VEND_MST_PK — the underlying unique key on the vendor master, implicitly required for the two foreign keys.

Because these vendor master records are shared with the core Purchasing (PO) and Payables (AP) modules, PO_VEND_ASC effectively extends vendor data defined in the common supplier model. Reporting that combines association data with purchasing activity should join to PO_VEND_MST first, then resolve to the relevant AP supplier identifier where cross-module reporting is required.