Search Results oe_default_agreement




Overview
Explore in AI Chat

Overview

OE_DEFAULT_AGREEMENT is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It forms part of the Oracle Order Management (OM) and Advanced Pricing infrastructure that governs pricing and agreement defaults during the order capture lifecycle. Its central business purpose is to resolve and apply defaulting rules for pricing agreements — the master commercial contracts that establish negotiated prices, price lists, and terms for specific customers, customer groups, or order types. When an order line is entered, the pricing engine must determine which agreement, if any, should be attached so that the correct negotiated price is used instead of the list price. OE_DEFAULT_AGREEMENT encapsulates that defaulting logic, providing a reusable programmatic entry point rather than embedding the rules directly in the pricing flow.

The package is classified as an "OTHER" API, meaning it is an internal utility rather than a formally published, externally supported interface. It sits beneath the public pricing surface exposed by OE_PRICING_CONT_PUB and the private implementation package OE_PRICING_CONT_PVT.

Key Procedures and Functions

The documented metadata identifies a single procedure or function named ATTRIBUTES. Consistent with Oracle's internal defaulting utilities, ATTRIBUTES is the routine responsible for deriving and returning the agreement-related attributes that the pricing engine requires when defaulting a pricing agreement onto an order, quote, or line context. It binds the defaulting outcome to the caller's pricing context so that downstream pricing calls can treat the resolved agreement as an input.

No parameter lists are published for this routine in the ETRM metadata, and none are inferred here. The package's dependency on FND_API indicates it follows Oracle's standard API design conventions — specifically the use of the FND_API.G_MISS_* and FND_API.G_RET_STS_* constants for validating optional arguments and communicating success, error, or unexpected status back to the caller. This is important for integrators: ATTRIBUTES should be treated as returning status information that must be checked, not as a silently succeeding routine.

Tables Accessed

Two tables are documented as being referenced through APPS synonyms:

  • OE_AGREEMENTS_S — the base table (and its sequence) that stores pricing agreement headers, including agreement number, customer or customer group, agreement type, effective and expiration dates, and status. OE_DEFAULT_AGREEMENT queries this table to identify the candidate agreement(s) eligible for defaulting given the current pricing context, then applies date and status filtering to select the appropriate record.
  • DUAL — used for single-row evaluation of expressions and constants, a standard PL/SQL device.

Usage Notes

OE_DEFAULT_AGREEMENT is not intended for direct invocation by customers or implementers. It is referenced by OE_PRICING_CONT_PVT, the private pricing context package that drives order-line pricing, and it in turn depends on OE_PRICING_CONT_PUB and FND_API. This dependency chain confirms its role as an internal helper within the pricing engine.

Typical invocation paths are therefore indirect:

  • Order Management order entry forms and the Pricing Engine, which trigger agreement defaulting automatically as lines are entered or repriced.
  • AutoAttribution and related concurrent programs that reprice or reattribute orders and order lines.
  • External applications and custom code that call the public pricing APIs, which internally reach OE_DEFAULT_AGREEMENT through OE_PRICING_CONT_PVT.

Because the package is a non-published "OTHER" API, Oracle does not guarantee its signature across releases or patches. Customers implementing custom pricing logic should invoke the supported public pricing APIs rather than calling OE_DEFAULT_AGREEMENT directly. Any customization that does reference it must be revalidated after applying patches, since changes in OE_PRICING_CONT_PVT or OE_AGREEMENTS_S can affect behavior without notice. The package is validated in the documented environments, and its APPS-synonym access to OE_AGREEMENTS_S means it operates on the shared Order Management schema data owned by the Oracle applications.