Search Results po_vendors




Overview
Explore in AI Chat

Overview

PO_VENDORS is the master supplier (vendor) table in Oracle E-Business Suite, owned by the Purchasing (PO) module. Its documented description is simply "Suppliers," reflecting its role as the single source of truth for supplier identity across Procurement, Payables, Payments, Projects, Assets, and Manufacturing. Every purchase order, invoice, payment, receipt, and supplier-facing transaction ultimately resolves to a VENDOR_ID in this table. Although it is physically owned by PO, it functions as the shared supplier registry for the entire applications suite, making it one of the most heavily referenced objects in an EBS 12.1.1 or 12.2.2 instance.

The ETRM metadata classifies this object heuristically as hub-leaning in Data Vault terms. That is a modeling suggestion: PO_VENDORS behaves as a hub because it carries a stable surrogate key (VENDOR_ID) and a large surrounding population of dependent link and satellite tables, rather than acting as a pure transactional link or an attribute-only satellite. Note the metadata's implementation flag of "Not implemented in this database"; the table is a standard EBS object and its presence depends on whether the PO module is fully installed and patched in a given instance.

Key Information Stored

The primary key is defined by the PO_VENDORS_PK constraint on VENDOR_ID, which is the surrogate key used by every downstream foreign key. VENDOR_ID is internally generated via sequence and should never be treated as a business identifier. Business-key candidates in EBS typically include SEGMENT1 (the human-readable supplier number) together with operating unit context supplied through PO_VENDOR_SITES_ALL; the metadata excerpt does not enumerate unique indexes beyond the PK, so uniqueness of supplier number should be confirmed against AP_SUPPLIERS-style validation logic rather than assumed from this table alone.

Among the most operationally significant documented columns are:

Common Use Cases and Queries

Typical reporting scenarios include supplier spend analysis, hold and inactive supplier audits, parent/child consolidation, and currency/accounting default validation. A basic supplier lookup joins the supplier to its Payables identity:

  • SELECT pv.vendor_id, pv.vendor_name, pv.segment1 FROM po_vendors pv WHERE pv.vendor_id = :vendor_id;
  • Suppliers on buyer hold: join HOLD_BY to PO_AGENTS to identify the responsible buyer and team.
  • Supplier hierarchy reporting: self-join PO_VENDORS via PARENT_VENDOR_ID to flatten corporate families.
  • Currency exposure: join INVOICE_CURRENCY_CODE and PAYMENT_CURRENCY_CODE to FND_CURRENCIES for a supplier-to-currency matrix.
  • Accounting default validation: left-join the five GL_CODE_COMBINATIONS FKs to detect suppliers missing default accounts.

In the specific case referenced by the user's search, FV_REFUNDS_VOIDS_ALL.VENDOR_ID joins back to PO_VENDORS.VENDOR_ID, so refund and void activity reported from the Federal Financials (FV) module can be attributed to the supplier master for reconciliation and 1099-style reporting.

Related Objects

The FK metadata shows PO_VENDORS at the centre of an unusually broad dependency web. The most significant related objects are:

  • PO_VENDOR_SITES_ALL — supplier sites; PO_VENDOR_SITES_ALL.VENDOR_ID → PO_VENDORS.VENDOR_ID.
  • PO_HEADERS_ALL — purchase orders; PO_HEADERS_ALL.VENDOR_ID → PO_VENDORS.VENDOR_ID.
  • AP_INVOICES_ALL — invoices; AP_INVOICES_ALL.VENDOR_ID → PO_VENDORS.VENDOR_ID.
  • AP_CHECKS_ALL — payments; AP_CHECKS_ALL.VENDOR_ID → PO_VENDORS.VENDOR_ID.
  • RCV_SHIPMENT_HEADERS and RCV_TRANSACTIONS — receiving; both join on VENDOR_ID.
  • FA_ASSET_INVOICES, FA_LEASES, FA_WARRANTIES — asset and lease references via PO_VENDOR_ID or LESSOR_ID.
  • FV_REFUNDS_VOIDS_ALL — refunds and voids; FV_REFUNDS_VOIDS_ALL.VENDOR_ID → PO_VENDORS.VENDOR_ID.
  • PO_AGENTS — buyers, referenced inward via PO_VENDORS.HOLD_BY.
  • GL_CODE_COMBINATIONS and FND_CURRENCIES — accounting and currency lookups referenced by PO_VENDORS.

Because so many modules depend on PO_VENDORS, changes to supplier records propagate broadly; supplier merge and purge routines in Payables and Purchasing exist specifically to consolidate or retire VENDOR_ID values without orphaning these dependent relationships.