Search Results oe_trxt_types_noorgs_vl




Overview

OE_TRXT_TYPES_NOORGS_VL is a valid, organization-independent multilingual (VL) view owned by the APPS schema in Oracle E-Business Suite. It belongs to the ONT – Order Management product family and is documented in Oracle's ETRM (E-Business Suite Technical Reference Manual) for release 12.1.1 and 12.2.2. its purpose, per the documentation, is explicit: it exists so that the Shipping integration team can retrieve the Order Type name without being constrained by, or required to supply, an operating unit (ORG_ID) context.

Internally, the ETRM describes it as an "Org independent VL view for Shipping integration team to get the Order Type name." In EBS terms, a "VL" view conventionally joins a base (_ALL or _B) table to its corresponding translation (_TL) table, resolving the translated NAME and DESCRIPTION based on the session language. The "NOORGS" prefix signals that this view deliberately does not filter by organization. This makes it suitable for cross-organizational lookups, background programs, and integration channels where the caller has no committed ORG_ID in session.

Underlying Base Objects

According to the documented ETRM metadata, the view is defined over two base objects, both referenced through synonyms:

  • OE_TRANSACTION_TYPES_ALL (SYNONYM) — aliased as B in the view text; supplies the transactional and structural attributes of the order type.
  • OE_TRANSACTION_TYPES_TL (SYNONYM) — aliased as T; supplies the translated NAME and DESCRIPTION.

The join predicate, per the view text, is B.TRANSACTION_TYPE_ID = T.TRANSACTION_TYPE_ID combined with T.LANGUAGE = USERENV('LANG'). Because it is built on a VL pattern and omits an ORG_ID filter in the join, the view returns a single row per order type for the current session language. Note, however, that the projected column list still includes ORG_ID — the column is carried through, but the view itself remains org-independent in behavior.

Key Columns

Because the view selects from a wide base table, it exposes a substantial column set. The most operationally significant columns include:

Common Use Cases and Queries

The primary scenario is Shipping-style integration lookups, where a downstream system needs to resolve a Transaction Type Id to its human-readable name without an operating unit context. A representative query is:

  • SELECT TRANSACTION_TYPE_ID, TRANSACTION_TYPE_CODE, NAME, ORDER_CATEGORY_CODE FROM OE_TRXT_TYPES_NOORGS_VL ORDER BY NAME;
  • Targeted lookup: SELECT NAME, DESCRIPTION FROM OE_TRXT_TYPES_NOORGS_VL WHERE TRANSACTION_TYPE_ID = :p_type_id;
  • Filtering active types for a code: SELECT NAME FROM OE_TRXT_TYPES_NOORGS_VL WHERE TRANSACTION_TYPE_CODE = 'ORDER' AND NVL(END_DATE_ACTIVE, SYSDATE+1) > SYSDATE;

Because the view is org-independent, it is best used strictly for name resolution and validation rather than for org-specific policy enforcement; callers that require an operating unit scope should join to or query OE_TRANSACTION_TYPES_ALL with an explicit ORG_ID predicate. Additionally, since no ORDER BY or DISTINCT is applied, integrations should expect one row per type per language and handle language dependence through the USERENV('LANG') setting of the executing session.