POZ_SUPPLIERS
Product: POZmasterThe supplier master — one row per supplier with the supplier number, type, business relationship level, and tax attributes, backed by the trading community architecture through its party id
There is NO supplier name column — the display name lives on the TCA party (PARTY_ID; the party tables land in a later wave), so every supplier-name report needs that join. SEGMENT1 is the supplier number (the same naming-collision posture as the PO number). BUSINESS_RELATIONSHIP separates prospective from spend-authorized suppliers.
What the badges mean
- master
- Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or a documented view.
Extract access
The delivered surfaces that reach this table — the BICC extract data store (PVO) for bulk extraction and the OTBI subject areas for real-time queries. There is no SQL path to the SaaS database.
- FscmTopModelAM.PrcExtractAM.PozBiccExtractAM.SupplierExtractPVOOTBI: Supplier - Supplier Real Time
Suppliers data store — keyed on VendorId. The subject-area name is Supplier - Supplier Real Time in Oracle's book, not Procurement - Supplier.
Oracle data-store documentation →
Fields
12 fields · 1 key
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | VENDOR_ID | Supplier surrogate key — what every PO table joins on | NUMBER | Key |
| 2 | PARTY_ID | TCA party — where the supplier NAME lives; there is no name column here | NUMBER | |
| 3 | SEGMENT1 | The supplier number — a naming collision with flexfields, not a flexfield | VARCHAR2 | |
| 4 | VENDOR_TYPE_LOOKUP_CODE | Supplier type classification | VARCHAR2 | |
| 5 | BUSINESS_RELATIONSHIP | Prospective vs spend-authorized relationship level | VARCHAR2 | |
| 6 | START_DATE_ACTIVE | Active-from date | DATE | |
| 7 | END_DATE_ACTIVE | Active-to date | DATE | |
| 8 | ONE_TIME_FLAG | One-time supplier indicator | VARCHAR2 | |
| 9 | PARENT_VENDOR_ID | Parent supplier in a hierarchy | NUMBER | |
| 10 | CUSTOMER_NUM | Your account number with the supplier | VARCHAR2 | |
| 11 | FEDERAL_REPORTABLE_FLAG | US 1099 federal reportability | VARCHAR2 | |
| 12 | ORGANIZATION_TYPE_LOOKUP_CODE | IRS organization type | VARCHAR2 |
Field provenance: hand-curated. 1 key field.
Boilerplate SQL
Starting point for reading the BICC-landed copy of POZ_SUPPLIERSon Databricks — real DATE columns need no conversion, and the org anchor and the LAST_UPDATE_DATE watermark (the column incremental BICC extracts key on) are already in place. Set your Unity Catalog location, schema, and org values below; they’re substituted into the SQL and the copy button.
-- ============================================================
-- Table : POZ_SUPPLIERS — The supplier master — one row per supplier with the supplier number, type, business relationship level, and tax attributes, backed by the trading community architecture through its party id
-- Purpose: Column-selected read of POZ_SUPPLIERS — auto-generated from field metadata
-- Grain : One row per VENDOR_ID
-- Notes : Auto-generated skeleton for Oracle Fusion Cloud data landed in your lakehouse by a BICC extract — there is no SQL path to the SaaS database. Column names follow Oracle's table documentation — if your landed data still carries PVO attribute headers, map names first; see quirks #pvo-drift. Dates are real DATE/TIMESTAMP columns — no conversion needed. WHO audit columns omitted (see the quirks guide); the optional LAST_UPDATE_DATE watermark filter supports incremental extracts.
-- ============================================================
SELECT
t.VENDOR_ID AS "Supplier surrogate key — what every PO table joins on",
t.PARTY_ID AS "TCA party — where the supplier NAME lives; there is no name column here",
t.SEGMENT1 AS "The supplier number — a naming collision with flexfields, not a flexfield",
t.VENDOR_TYPE_LOOKUP_CODE AS "Supplier type classification",
t.BUSINESS_RELATIONSHIP AS "Prospective vs spend-authorized relationship level",
t.START_DATE_ACTIVE AS "Active-from date",
t.END_DATE_ACTIVE AS "Active-to date",
t.ONE_TIME_FLAG AS "One-time supplier indicator",
t.PARENT_VENDOR_ID AS "Parent supplier in a hierarchy",
t.CUSTOMER_NUM AS "Your account number with the supplier",
t.FEDERAL_REPORTABLE_FLAG AS "US 1099 federal reportability",
t.ORGANIZATION_TYPE_LOOKUP_CODE AS "IRS organization type"
FROM <catalog>.<schema>.POZ_SUPPLIERS t
WHERE
1 = 1 -- no partition column on this table; the filters below are optional
-- AND t.VENDOR_ID = <VENDOR_ID>
-- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>' -- the column incremental BICC extracts key on
ORDER BY t.VENDOR_ID;4 parameters not filled: <catalog>, <schema>, <VENDOR_ID>, <watermark>
Relationships
1-hop neighbors — click a table to navigate there. FND lookup decode and translation edges are highlighted; they’re the joins newcomers most often get wrong.
Join details
ON PO_HEADERS_ALL.VENDOR_ID = POZ_SUPPLIERS.VENDOR_IDON POR_REQUISITION_LINES_ALL.VENDOR_ID = POZ_SUPPLIERS.VENDOR_IDON POZ_SUPPLIER_SITES_ALL_M.VENDOR_ID = POZ_SUPPLIERS.VENDOR_IDON RCV_SHIPMENT_HEADERS.VENDOR_ID = POZ_SUPPLIERS.VENDOR_ID