Search Results oe_agreements_pk

Overview

OE_AGREEMENTS is a table documented within the Oracle E-Business Suite Advanced Pricing (QP) module, and it is also historically associated with the Oracle Order Management (OE) schema, where the "OE_" prefix originates. The table stores agreement header information — the negotiated pricing and commercial arrangements that govern how items, customers, and price lists are associated with one another across the order-to-cash cycle. In the Oracle EBS 12.1.1 and 12.2.2 releases, agreement records underpin pricing engine resolution and order capture behavior, allowing a single negotiated instrument to drive consistent pricing and terms across multiple downstream transactions.

The documented primary key is OE_AGREEMENTS_PK, defined on the AGREEMENT_ID column. The ETRM metadata notes that this object is not implemented in the referenced database, meaning the table exists in the EBS data model but may be absent from a given instance's physical schema, a common situation when a specific module configuration or product installation is not licensed. The metadata additionally records a heuristic Data Vault classification of standalone — that is, no foreign-key relationships to other tables were mined from the FK structure. As a modeling suggestion, this positions OE_AGREEMENTS as a candidate hub (its own business entity keyed by AGREEMENT_ID) rather than a dependent link or satellite, though in practice agreement headers usually participate in soft, application-enforced relationships rather than database-enforced foreign keys.

Key Information Stored

The most significant column documented is AGREEMENT_ID, the surrogate primary key defined by OE_AGREEMENTS_PK. This numeric identifier uniquely distinguishes each agreement header and is the column referenced by virtually every application-level relationship to agreement data. Because the metadata exposes only the primary key column explicitly, the following description relies on standard EBS agreement modeling conventions alongside the documented facts:

• AGREEMENT_ID — Surrogate primary key (OE_AGREEMENTS_PK). No separate unique business-key index is documented in the metadata; business identifiers such as agreement numbers are typically stored as attributes rather than enforced unique constraints at the database level.
• Agreement header attributes — Descriptions, effective dates, active/inactive flags, and version or revision indicators that define the agreement's validity window.
• Operating unit / organization context — The org_id and related multi-org columns that segregate agreement data by business unit.
• Party and pricing context — References to customer, price list, and currency that determine which pricing structures the agreement governs.
• Status and processing columns — Flags indicating whether the agreement has been submitted, qualified, or made available to the pricing engine.

Because the metadata identifies no unique business-key index beyond the surrogate AGREEMENT_ID, any natural key (for example an agreement number or name) should be treated as a descriptive attribute rather than a guaranteed-unique identifier.

Common Use Cases and Queries

Typical reporting and integration scenarios query agreement headers to reconcile negotiated pricing against realized order pricing, to audit which agreements are active for a given operating unit, and to drive custom pricing extracts. A simple retrieval by primary key is the most common pattern:

• Point lookup by surrogate key: SELECT * FROM OE_AGREEMENTS WHERE agreement_id = :id;
• Operating-unit scoped listing of active agreements, filtering on org_id and status columns.
• Pricing reconciliation joins between agreement headers and price list or modifier data to compare agreed versus applied pricing at order entry.
• Audit and compliance extracts that trace an order line's price back to the originating agreement record.

Because the table is documented as not implemented in the reference database, query authors should first confirm the table's presence in the target schema before building dependent logic.

Related Objects

The ETRM metadata reports no mined foreign-key relationships, so the following objects are conceptual or application-enforced dependencies rather than documented FK dependencies. They should be validated against the target instance:

• QP_PRICE_LISTS / QP_LIST_HEADERS — Price list headers that agreements reference to establish pricing context.
• QP_PRICING_ATTRIBUTES — Attribute mappings used by the pricing engine to qualify agreement records.
• OE_ORDER_HEADERS / OE_ORDER_LINES — Order data whose pricing is governed by the agreement at order capture.
• OE_AGREEMENT_LINES or equivalent detail table — Child detail rows keyed by AGREEMENT_ID, if the physical schema includes a line-level companion object.
• QP_QUALIFIERS / QP_MODIFIERS — Qualifier and modifier definitions linked to agreement-driven pricing rules.

Where database-enforced constraints are absent, referential integrity between these objects is maintained by the Advanced Pricing and Order Management application layers rather than by declared foreign keys.