Results for “attachment_url”

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

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:

• Staging and identity: BATCH_ID and INTERFACE_LINE_ID identify the load run and the individual interface row. These are the technical locators used to isolate, reprocess, or purge a given upload. Because the metadata documents no unique index, BATCH_ID plus INTERFACE_LINE_ID is the practical candidate key for deduplication and error triage.
• Auction and line context: AUCTION_HEADER_ID (the documented foreign key to PON_AUCTION_HEADERS_ALL), BID_NUMBER, LINE_NUMBER, and DOCUMENT_DISP_LINE_NUMBER tie each row back to the specific auction and line being answered. These are the business-key candidates used when joining interface rows to their production bid counterparts.
• Response and commercial detail: QUANTITY, BID_CURRENCY_PRICE, BID_CURRENCY_LIMIT_PRICE, NOTE_TO_AUCTION_OWNER, PROMISED_DATE, and PO_BID_MIN_REL_AMOUNT capture the supplier's offer and its constraints. Complex-category terms are carried in BID_CURR_ADVANCE_AMOUNT, RECOUPMENT_RATE_PERCENT, PROGRESS_PYMT_RATE_PERCENT, RETAINAGE_RATE_PERCENT, and BID_CURR_MAX_RETAINAGE_AMT. Period-of-performance data is held in PROMISE_POP_START_DATE, PROMISE_POP_END_DATE, CLM_PROMISE_PERIOD and its UOM, CLM_PROMISE_POP_DURATION and its UOM, and the corresponding UOM_CODE columns. Attachment references are stored in ATTACHMENT_DESC and ATTACHMENT_URL, and worksheet mapping in WORKSHEET_NAME and WORKSHEET_SEQUENCE_NUMBER.

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.