Results for “po_dist_inst_pk_key”

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

Overview

The POA_EDW_PO_DIST_F object is a fact table within the Purchasing Intelligence (POA) module of Oracle E-Business Suite. It stores purchase order distribution-level transactional metrics designed for the Purchasing Intelligence data warehouse, aggregating spend, quantity, and cycle-time measurements at the PO distribution grain. The table is owned by the POA schema and comprises 152 columns in the ETRM 12.1.1 physical schema.

Under the ETRM metadata, POA is flagged as Obsolete, and the implementation note records that this table is "Not implemented in this database." This means the object may exist in older or reference schemas but is not instantiated in the current environment; organizations relying on Purchasing Intelligence analytics should verify availability before querying.

From a data modeling perspective, the metadata's heuristic Data Vault classification is standalone. This suggests the table functions as an independent fact construct rather than participating in an explicit hub-link-satellite chain, though the presence of a documented foreign key to PO_RELEASES_ALL indicates a dimensional relationship with the purchasing release entity.

Key Information Stored

The table's business grain is reflected in its unique index, POA_EDW_PO_DIST_F_U1, which is defined on the PO_DIST_INST_PK column. This column serves as the documented business-key candidate and surrogate primary key, uniquely identifying each PO distribution instance within the warehouse.

Key identifier and relationship columns include PO_RELEASE_ID, PO_LINE_ID, PO_HEADER_ID, LINE_LOCATION_ID, DISTRIBUTION_ID, ITEM_ID, and SOURCE_DIST_ID, which anchor the fact record to the operational purchasing and receiving schema. Quantity measures include QTY_ORDERED_B, QTY_DELIVERED_B, QTY_CANCELLED_B, and QTY_BILLED_B, covering the base-unit lifecycle of the distribution.

Financial measures are captured in paired transactional and global currency columns: AMT_PURCHASED_T/G, AMT_BILLED_T/G, AMT_CONTRACT_T/G, AMT_NONCONTRACT_T/G, and AMT_LEAKAGE_T/G. Price-related measures include PRICE_T, PRICE_G, PRICE_LIMIT_T/G, LIST_PRC_UNIT_T/G, MARKET_PRICE_T/G, and POTENTIAL_SVG_T/G.

Cycle-time analytics are supported by columns such as ORDER_TO_PAY_CYCLE_TIME, INV_TO_PAY_CYCLE_TIME, PO_CREATION_CYCLE_TIME, RECEIVE_TO_PAY_CYCL_TIME, and INV_CREATION_CYCLE_TIME. Numerous foreign-key style columns (for example BUYER_FK_KEY, SUPPLIER_ITEM_FK_KEY, SHIP_TO_ORG_FK_KEY) provide dimensional keys, while USER_ATTRIBUTE and USER_MEASURE columns support extensibility.

Common Use Cases and Queries

Primary use cases center on procurement spend analysis, supplier performance reporting, and cycle-time trending. A typical query aggregates purchased amounts by buyer or supplier site using the transactional currency columns, filtering on the distribution key to avoid double counting:

• SELECT BUYER_FK_KEY, SUM(AMT_PURCHASED_T) FROM POA_EDW_PO_DIST_F GROUP BY BUYER_FK_KEY;
• Aggregate QTY_DELIVERED_B versus QTY_ORDERED_B to measure fulfillment variance at distribution level.
• Trend ORDER_TO_PAY_CYCLE_TIME and RECEIVE_TO_PAY_CYCL_TIME by PO_CREATE_DATE_FK_KEY to identify process bottlenecks.
• Compare AMT_CONTRACT_T to AMT_NONCONTRACT_T to quantify contract compliance and off-contract spend.
• Filter on PO_RELEASE_ID to isolate release-level activity against blanket agreements.

Related Objects

The documented foreign key relationship from PO_RELEASE_ID references PO_RELEASES_ALL, linking distribution facts to purchasing release headers. Operational joins can also be inferred to PO_HEADERS_ALL and PO_LINES_ALL via PO_HEADER_ID and PO_LINE_ID, and to PO_LINE_LOCATIONS_ALL through LINE_LOCATION_ID. The DUNS_FK_KEY, SUPPLIER_SITE_FK_KEY, and BUYER_FK_KEY columns typically join to supplier and buyer dimension tables in the POA warehouse. Because POA is marked obsolete, confirmation of any replacement schema objects, such as BI Publisher data models or OTBI subject areas, is advisable before integrating these columns into new reporting.