Search Results pon_offer_commitments_pk

Overview

PON_OFFER_COMMITMENTS is a Sourcing (PON) module table whose documented purpose is to store the commitments associated with a sourcing Offer. In the Oracle E-Business Suite sourcing model, an Offer represents a supplier's response captured during a negotiation — typically through Oracle Sourcing, iSupplier, or an RFQ/bid process — and the commitment records attached to that Offer represent the specific supply assurances, quantities, prices, dates, or negotiated terms that a supplier has undertaken to honor. The table therefore serves as the transactional anchor that links negotiated sourcing commitments to downstream execution objects such as order lines, service contracts, and quotations.

From a modeling perspective, the provided Data Vault classification is standalone. This heuristic indicates the table is not currently wired as a hub, link, or satellite within the mined foreign-key topology; it is best treated as an independent or reference-style table that other subject areas point to rather than one that fans out aggressively to children. Because the ETRM metadata records "Not implemented in this database," PON_OFFER_COMMITMENTS may be absent from certain instances depending on the applied Sourcing patches and feature set. This should be verified before authoring queries against it.

Key Information Stored

The documented structure centers on the primary key defined by the constraint PON_OFFER_COMMITMENTS_PK, which enforces uniqueness on COMMITMENT_ID. Based on the metadata provided, the most important columns are:

• COMMITMENT_ID — the surrogate primary key and the single documented identifier. It uniquely identifies each commitment row and is the column referenced by every downstream foreign key in the extracted relationship data.
• OFFER reference columns — the table's stated role ("commitments for an Offer") implies an offer/negotiation identifier linking each commitment to its parent Offer; this is the principal business-key candidate alongside COMMITMENT_ID.
• Commitment descriptive and quantity attributes — the terms captured for the commitment (as used later by order and contract lines that carry the same COMMITMENT_ID).

Only COMMITMENT_ID appears explicitly in the documented metadata. No additional column names, unique business-key indexes, WHO audit columns, or date/amount fields are enumerated in the supplied excerpt; any further column-level assertions should be confirmed against the deployed dictionary. Notably, no unique index beyond the PK is documented, so COMMITMENT_ID is simultaneously the surrogate key and the de facto join key across the integrated schema.

Common Use Cases and Queries

The dominant practical use of this table is resolving the commitment behind a downstream transactional line. Because order, contract, and quotation tables all carry a COMMITMENT_ID foreign key to this table, a standard integration or reconciliation query joins them back to the commitment header:

• Order-line traceability: join OE_ORDER_LINES_ALL to PON_OFFER_COMMITMENTS on COMMITMENT_ID to report the sourcing commitment that originated or authorized a sales order line.
• Contract linkage: join OKS_K_HEADERS_B and OKS_K_LINES_B on COMMITMENT_ID to surface the service-contract commitments created from a sourcing event.
• Quote and blanket analysis: join ASO_QUOTE_LINES_ALL and OE_BLANKET_LINES_ALL to analyze how negotiated commitments propagate into quotes and blanket agreements.
• Interface validation: reconcile OE_LINES_IFACE_ALL, SO_LINES_INTERFACE_ALL, and OKS staging tables (OKS_INT_HEADER_STG_TEMP, OKS_INT_LINE_STG_TEMP) against this table to detect orphaned or invalid COMMITMENT_ID values during inbound processing.

A representative pattern is a left-outer join from an interface table to this table, filtering for nulls to isolate commitments that failed to resolve — a common pre-import data-quality check. Reporting extracts for procurement savings and negotiation-to-execution funnels also aggregate through this table by counting child rows per COMMITMENT_ID.

Related Objects

The FK relationship data shows PON_OFFER_COMMITMENTS as a referenced parent. The most significant dependent objects, all joining on COMMITMENT_ID, are:

• OE_ORDER_LINES_ALL and OE_ORDER_LINES_HISTORY — order line commitment references, current and historical.
• OE_BLANKET_LINES_ALL and OE_BLANKET_LINES_HIST — blanket agreement line linkage.
• ASO_QUOTE_LINES_ALL — quote-line association.
• OKS_K_HEADERS_B, OKS_K_LINES_B, OKS_K_HEADERS_BH, and OKS_K_LINES_BH — service contract headers and lines, base and history.
• OE_LINES_IFACE_ALL, SO_LINES_INTERFACE_ALL, OE_LINE_ACKS, OKS_INT_HEADER_STG_TEMP, and OKS_INT_LINE_STG_TEMP — interface and acknowledgement tables used during conversion and integration.

Because all references pivot on the single COMMITMENT_ID key, integrity and reporting across Sourcing, Order Management, and Service Contracts depend on this table remaining populated and consistent with the offers it represents.