Search Results pon_bid_item_prices_interface




Overview
Explore in AI Chat

Overview

PON_BID_ITEM_PRICES_INTERFACE is a staging table in the PON (Sourcing) product of Oracle E-Business Suite, holding 29 columns in the documented 12.2.2 schema. Its stated purpose is to temporarily store response information during auction and sourcing bid processing — specifically the per-line price, quantity, and commercial terms submitted by a supplier or entered on the buyer's behalf before that data is validated and pushed into the production bidding tables. Because the name carries the _INTERFACE suffix, the table is an inbound staging area rather than a transactional master: rows are typically loaded through the bid spreadsheet or the Sourcing open interface, keyed by BATCH_ID, and consumed by a concurrent program that transfers them to live bid structures. Data residing here is transient by design and should not be treated as an authoritative record of any bid.

From a Data Vault modeling perspective — offered here as a heuristic suggestion mined from the foreign-key structure rather than a documented classification — the table resolves as standalone. It does not sit as a pure link between two hubs, nor does it carry a full natural business key of its own; the surrogate identity is the interface line row, while the auction context is supplied by the foreign key to PON_AUCTION_HEADERS_ALL. The practical consequence is that this object behaves like a staging or effectivity structure attached to the auction header, with its business meaning anchored upstream rather than self-contained.

Key Information Stored

The most significant columns fall into three groups:

Common Use Cases and Queries

The primary operational use case is diagnosing failed or partially applied bid uploads. A concurrent manager run may leave rows here when validation rejects a line, so support queries typically group by BATCH_ID to establish what was received versus what transferred:

SELECT batch_id, COUNT(*), SUM(NVL(bid_currency_price,0)) FROM pon.pon_bid_item_prices_interface GROUP BY batch_id;

A second pattern reconciles interface rows against the auction header and their production bid lines, exposing unmatched or duplicated lines before they are purged:

SELECT i.batch_id, i.line_number, i.quantity, i.bid_currency_price FROM pon.pon_bid_item_prices_interface i, pon.pon_auction_headers_all h WHERE i.auction_header_id = h.auction_header_id AND h.auction_header_id = :auction_id;

Reporting use cases include audit of submitted supplier terms for a given negotiation, trend analysis on promised dates and retainage or progress-payment percentages, and extraction of NOTE_TO_AUCTION_OWNER and ATTACHMENT_URL content for buyer review. Because the table is transient, any repeatable reporting should be built from the post-interface bid tables and this object used only for reconciliation and troubleshooting.

Related Objects

The documented relationship set is deliberately narrow, which is consistent with a staging table. The significant related objects are:

  • PON_AUCTION_HEADERS_ALL — the sole documented foreign key, joined on AUCTION_HEADER_ID; supplies the auction identity and drives every reconciliation query.
  • The production bid item price tables in the PON schema — the downstream target of the interface transfer, matched on auction and line number.
  • PON_BID_ITEMS_PROCES_INTERFACE — referenced in the documented description as the sibling interface construct for response processing.
  • The Sourcing open interface concurrent program and the bid spreadsheet upload utility — the processes that populate and consume this table.
  • PON_AUCTION_HEADERS_ALL-dependent bid and award query views used in Sourcing reporting, which ultimately reflect the data once transferred.

Because the Data Vault shape is standalone, no additional dependent link tables are implied by the metadata; all meaningful joins route through AUCTION_HEADER_ID.