Search Results oe_agreements_vl




Overview
Explore in AI Chat

Overview

OE_AGREEMENTS_VL is an APPS-owned, VALID database view in Oracle E-Business Suite, delivered as part of the QP (Advanced Pricing) product family. It functions as a translation (MLS) view that merges the base pricing agreement table, OE_AGREEMENTS_B, with its translation table, OE_AGREEMENTS_TL, to expose agreement data alongside the translated descriptive columns in the session's local language. The _VL suffix identifies it as a "view with language," a standard Oracle Applications convention for presenting base and translated table data as a single row per agreement, filtered by the runtime language.

In practice, OE_AGREEMENTS_VL presents pricing agreements — sales agreements, pricing agreements, and related negotiated documents captured through Order Management and Advanced Pricing — in a user-readable form. Its role in EBS reporting and integration is to provide a pre-joined, language-aware source so that reports, concurrent programs, and interfaces do not need to perform their own outer join between the base and translation tables or apply language filtering logic themselves. The view is available in both 12.1.1 and 12.2.2, where it retains the same APPS owner and VALID status.

Underlying Base Objects

The view is defined over three underlying objects:

  • OE_AGREEMENTS_B (SYNONYM) — the base table holding non-translated agreement attributes, including identifiers, dates, type codes, price list references, and descriptive flexfield columns.
  • OE_AGREEMENTS_TL (SYNONYM) — the translation table storing the language-specific NAME for each agreement, one row per installed language.
  • OKC_K_HEADERS_TL (SYNONYM) — referenced through the OKC_K_HEADERS_V synonym in the view text to supply the SHORT_DESCRIPTION (DESCRIPTION) from the corresponding contract header.

The view joins OE_AGREEMENTS_B to OE_AGREEMENTS_TL on AGREEMENT_ID, guaranteeing that only the translation row matching the user's language appears. It joins to the contract header by ORIG_SYSTEM_AGR_ID using an outer join (C.ID(+)). The WHERE clause restricts translation rows to T.LANGUAGE = USERENV('LANG'), so the view returns exactly one row per agreement in the current session language. Because the referenced objects are synonyms, the definition resolves to the underlying APPS tables at runtime.

Key Columns

The view exposes the full set of base agreement columns plus translated and joined descriptive columns. Notable columns include:

Common Use Cases and Queries

OE_AGREEMENTS_VL is typically queried for agreement lookups, reporting, and integration extracts where the display name and description in the local language are required. Because the language filter is built in, callers need not add a language predicate. A representative query lists active pricing agreements with their translated names:

  • Agreement listing: SELECT agreement_id, agreement_num, name, agreement_type_code, start_date_active, end_date_active FROM oe_agreements_vl WHERE start_date_active <= SYSDATE AND NVL(end_date_active, SYSDATE) >= SYSDATE;
  • Lookup by number: SELECT agreement_id, agreement_num, name, revision, description FROM oe_agreements_vl WHERE agreement_num = :p_num;
  • Pricing reference audit: SELECT agreement_num, name, price_list_id, term_id, sold_to_org_id FROM oe_agreements_vl WHERE price_list_id IS NOT NULL;
  • Integration extract: join OE_AGREEMENTS_VL to order or pricing tables on AGREEMENT_ID or PRICE_LIST_ID to enrich transactional data with readable agreement names.

When building reports, note that the DESCRIPTION column depends on a successful outer join to the contract header, and may be null where no matching header exists. Query performance is generally adequate for agreement-level reporting, though filtering on indexed base-table columns such as AGREEMENT_ID or AGREEMENT_NUM is advisable for large datasets.