Results for “agreement_num”

4 results




AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

SO_AGREEMENTS_VL is a multilingual (VL) view owned by the APPS schema in Oracle E-Business Suite, residing in the Order Entry (OE) product family. It presents header-level information for sales agreements — the customer-facing documents that establish negotiated pricing, terms, and invoicing conditions for future orders. Because agreements carry descriptive text that must be translatable across installed languages, Oracle stores the base attributes in a "_B" table and the language-dependent name in a "_TL" table; SO_AGREEMENTS_VL joins the two so that a single query returns a complete, user-language-aware record.

In both 12.1.1 and 12.2.2, the view status is VALID and is a standard component of the OE data model. It is not a transactional table and holds no data of its own; it is a read-optimized presentation layer intended for reporting, concurrent programs, and integration extracts that need agreement headers without performing the translation join manually.

Underlying Base Objects

The ETRM metadata documents two referenced base objects, exposed to APPS through synonyms:

  • SO_AGREEMENTS_B — the base table holding non-translatable agreement attributes (identifiers, dates, flags, foreign keys).
  • SO_AGREEMENTS_TL — the translation table holding the language-specific agreement name, keyed by AGREEMENT_ID and LANGUAGE.

The view text joins these on B.AGREEMENT_ID = T.AGREEMENT_ID and filters T.LANGUAGE = USERENV('LANG'), so each row is returned only once, in the session's current language. All columns prefixed "B." originate from the base table; only NAME is contributed by the translation table. The ROW_ID column is derived from the base table ROWID, providing a physical row locator for the agreement record.

Key Columns

Common Use Cases and Queries

Typical usage includes agreement validation reports, active-agreement dashboards, integration extracts feeding CRM or pricing engines, and lookups that resolve an agreement number to its internal ID. Because the view already applies the language predicate, no additional translation handling is required.

  • Retrieve all active agreements for a customer:
SELECT agreement_id, agreement_num, name, start_date_active, end_date_active
FROM   apps.so_agreements_vl
WHERE  customer_id = :p_customer_id
AND    TRUNC(SYSDATE) BETWEEN NVL(start_date_active, SYSDATE)
                          AND NVL(end_date_active, SYSDATE);
  • Resolve an agreement number to its identifier and pricing defaults:
SELECT agreement_id, agreement_type_code, price_list_id, term_id
FROM   apps.so_agreements_vl
WHERE  agreement_num = :p_agreement_num;
  • List agreements by sales representative with audit information:
SELECT agreement_num, name, salesrep_id, last_update_date, last_updated_by
FROM   apps.so_agreements_vl
WHERE  salesrep_id = :p_salesrep_id
ORDER  BY last_update_date DESC;

When querying outside the EBS session context (for example, from an external tool), the caller must supply an appropriate language value, since USERENV('LANG') resolves to the connected session's language. In all cases, the view should be accessed through the APPS synonym to respect the standard EBS security and grant model.