Results for “award_quantity”

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

Overview

PON.PON_AUCTION_SUMMARY is a transient staging table in the Oracle E-Business Suite Sourcing (PON) module. Its documented purpose is to hold summary data for individual items participating in an auction, generated on demand so that the auction summary page can be rendered efficiently. Rather than querying the full transactional auction, bid, and pricing structures each time a buyer opens the summary screen, Oracle populates this table with aggregated, presentation-ready rows.

Because the object is explicitly described as a temporary table, its contents are transient by design. Rows are written and consumed within the lifecycle of a single summary-page request or batch refresh, and the data should not be treated as an authoritative record of auction history. Persistent auction, bid, and award information resides in the parent sourcing tables that this table references.

The ETRM metadata carries a heuristic Data Vault classification of link. Under a Data Vault modeling convention, this suggests the table functions primarily as an associative structure connecting auctions, batches, line items, and trading partners rather than as a descriptive hub or satellite. This classification should be read as a modeling suggestion inferred from the foreign key topology, not as a formally declared design attribute.

Key Information Stored

The physical schema documents thirteen columns owned by the PON schema. The most significant are summarized below.

• AUCTION_ID — Identifies the auction to which the summary row belongs. It is part of the composite primary key and the principal join key back to auction header data.
• BATCH_ID — Identifies the auction batch. It participates in the composite primary key, allowing summary data to be scoped to a specific batch of lines.
• LINE_NUMBER — The auction line identifier. Part of the primary key and a foreign key into PON_AUCTION_ITEM_PRICES_ALL.
• TRADING_PARTNER_ID — The supplier or partner identifier, referencing HZ_PARTIES. This is the primary linkage to the Trading Community Architecture party model.
• TRADING_PARTNER_NAME — A denormalized partner name carried alongside the identifier so the summary page need not join to HZ_PARTIES at render time.
• TRADING_PARTNER_CONTACT_ID — Identifies the specific contact associated with the partner for the summarized response.
• BID_NUMBER — The bid or response reference from the trading partner.
• BID_PRICE — The price submitted by the trading partner in the bid.
• AUCTION_PRICE — The auction or target price context for the line, used for comparison against the bid.
• RESPONSE_QUANTITY — The quantity offered or responded with by the trading partner.
• AWARD_QUANTITY — The quantity awarded to the trading partner for the line.
• AWARD_SHIPMENT_NUMBER — The shipment reference associated with the award, carried for downstream display and sourcing document creation.
• RANK — The relative ranking of the trading partner's response for the line, supporting the comparative summary view.

The surrogate-style primary key is PON_AUCTION_SUMMARY_PK, defined over the composite of AUCTION_ID, BATCH_ID, and LINE_NUMBER. Together these columns constitute the business-key candidate for uniqueness within the summary set; no separate single-column surrogate is documented.

Common Use Cases and Queries

The dominant use case is rendering the auction summary page. Buyers open an auction and expect to see, per line, the competing responses with quantities, prices, contact names, and ranks. The application materializes the rows and the page reads them back directly.

A secondary use case is ad hoc reporting on auction competitiveness during the sourcing event window, or verification during troubleshooting when summary figures appear inconsistent with underlying bid data.

A representative query joining the summary to the item-price detail and the party model might resemble the following pattern:

• Filter by AUCTION_ID and BATCH_ID to isolate the batch being displayed, then join LINE_NUMBER to PON_AUCTION_ITEM_PRICES_ALL for authoritative pricing detail.
• Join TRADING_PARTNER_ID to HZ_PARTIES.PARTY_ID when the denormalized TRADING_PARTNER_NAME is insufficient or stale.
• Order by LINE_NUMBER, then RANK, to reproduce the ranked presentation order shown to the buyer.
• Compare RESPONSE_QUANTITY against AWARD_QUANTITY to identify partially awarded or unawarded quantities.

Because the table is temporary, queries should never assume persistence. Any reconciliation or historical reporting requirement must be redirected to the underlying auction, bid, and award tables, with PON_AUCTION_SUMMARY used only as a transient convenience store.

Related Objects

The documented foreign key relationships define the table's immediate dependency graph.

• PON_AUCTION_ITEM_PRICES_ALL — Referenced via LINE_NUMBER (together with auction context in practice). This is the authoritative source of per-line item pricing detail that the summary denormalizes.
• HZ_PARTIES — Referenced via TRADING_PARTNER_ID. The TCA party record supplying supplier identity, which the summary copies into TRADING_PARTNER_NAME.
• PON_AUCTION_HEADERS_ALL — While not listed in the supplied FK set, the auction header is the logical parent implied by AUCTION_ID and is the entry point through which summary generation is scoped.
• PON_AUCTION_ITEMS_ALL — The item master for auction lines corresponding to LINE_NUMBER.
• PON_BID_HEADERS / PON_BID_LINES — The bid structures supplying BID_NUMBER, BID_PRICE, RESPONSE_QUANTITY, and TRADING_PARTNER_CONTACT_ID.
• PON_AWARD_* tables and the Auction Award API — Consume AWARD_QUANTITY and AWARD_SHIPMENT_NUMBER downstream when awards are converted into sourcing documents.
• Auction Summary page / OAF region — The presentation artifact that this table directly serves, defining its population and read lifecycle.

All relationships above are grounded in the documented FK metadata where listed; the remaining entries represent the natural supporting structures implied by the column semantics and Sourcing module design.