Search Results oe_agreements_lov_v




Overview
Explore in AI Chat

Overview

OE_AGREEMENTS_LOV_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the Order Management (ONT) product family. Its documented purpose is to present a list of agreements — pricing, sales, or blanket agreements maintained within Oracle Order Management — in a form suited to a List of Values (LOV) window or similar selection component.

Unlike its underlying storage view OE_AGREEMENTS_VL, which carries the full agreement definition including descriptive and translation columns, OE_AGREEMENTS_LOV_V projects a narrowed and selectively transformed set of columns. The most significant transformation is the construction of AGREEMENT_NAME through a call to OE_VIEW_FUNCTIONS.GET_AGREEMENT_REVISION, which concatenates the agreement name and revision into a single display value. This makes the view particularly appropriate for LOV regions where users select an agreement by a human-readable label rather than by numeric identifier.

The view is applicable to both Oracle EBS 12.1.1 and 12.2.2. In 12.2.2 the documented status is VALID, and the object remains a thin presentation layer over the OE_AGREEMENTS_VL view. Because it exposes no DML-capable columns and is defined over another view, it is strictly a query object; insertions and updates must target the base agreement tables.

Underlying Base Objects

The view is defined by a single SELECT statement over OE_AGREEMENTS_VL, aliased as A. Two objects are documented as referenced:

  • OE_AGREEMENTS_VL (VIEW) — the primary source of agreement rows. The _VL suffix indicates a view that exposes both base and translated (language-dependent) columns; OE_AGREEMENTS_LOV_V does not expose the translation columns, but it inherits the language filtering imposed by the underlying view.
  • OE_VIEW_FUNCTIONS (PACKAGE) — a helper package supplying the GET_AGREEMENT_REVISION function used in the select list. The function accepts the agreement name and revision and returns a combined display string.

No base tables are referenced directly. Consequently, any change to the definition of OE_AGREEMENTS_VL, to the GET_AGREEMENT_REVISION function signature, or to the agreement revision data flows through to this view automatically. Organizations that have customized OE_AGREEMENTS_VL should confirm the columns relied upon here remain present after patching.

Key Columns

  • AGREEMENT_NAME — the derived display label returned by GET_AGREEMENT_REVISION(A.NAME, A.REVISION). This is the value typically shown in the LOV and stored for reference after selection.
  • AGREEMENT_ID — the unique primary key identifier of the agreement. This is the value normally written back to the calling form or interface.
  • AGREEMENT_TYPE — the agreement type code (for example, pricing or sales agreement classification).
  • SOLD_TO_ORG_ID — the identifier of the customer organization to which the agreement applies.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — the effective date range of the agreement; useful for filtering to currently active agreements.
  • TERM_ID — the payment or agreement term associated with the agreement.
  • PRICE_LIST_ID — the price list linked to the agreement, where applicable.

Common Use Cases and Queries

The primary scenario is populating a List of Values so that users can pick an agreement by name while the form retains the underlying identifier. A second scenario is reporting: joining the view to order or pricing data to attribute transactions to the governing agreement.

To retrieve all agreements available to the LOV:

  • SELECT agreement_id, agreement_name, agreement_type, sold_to_org_id, start_date_active, end_date_active FROM apps.oe_agreements_lov_v ORDER BY agreement_name;

To restrict the LOV to agreements currently in effect for a given customer:

  • SELECT agreement_id, agreement_name FROM apps.oe_agreements_lov_v WHERE sold_to_org_id = :p_sold_to_org_id AND SYSDATE BETWEEN start_date_active AND NVL(end_date_active, SYSDATE);

To filter by agreement type when the calling context requires only pricing agreements:

  • SELECT agreement_id, agreement_name FROM apps.oe_agreements_lov_v WHERE agreement_type = 'PRICING';

Because the view returns one row per agreement, it is safe to join on AGREEMENT_ID to order management tables. Note that agreement name uniqueness is not guaranteed across customers and types; filtering by SOLD_TO_ORG_ID is recommended when the LOV is context-sensitive.