Search Results oebv_sales_order_types




Overview

OEBV_SALES_ORDER_TYPES is a read-only view owned by the APPS schema in Oracle E-Business Suite, classified under the Order Entry (OE) product family. The object type is VIEW, its status is VALID, and the ETRM description carries the annotation "Retrofitted," indicating that the object was carried forward into the 12.1.1 and 12.2.2 code lines to preserve backward compatibility for existing reports, forms, and integrations. The view exposes sales order type configuration maintained in Order Management, presenting both the underlying code values and translated, presentation-ready labels resolved at runtime through Oracle's multilingual ("_LA" and "_DF") mechanism.

In reporting and integration contexts, OEBV_SALES_ORDER_TYPES functions as a de-normalized, language-aware projection of the sales order type definition. Substituting the raw view for the base table spares developers from writing lookup joins against FND_LOOKUPS or SO_LOOKUPS merely to render codes such as freight terms or shipping method as friendly meanings. The presence of ORG_ID supports multi-organization security filtering, and the WITH READ ONLY clause guarantees the view cannot be used for DML.

Underlying Base Objects

The ETRM 12.2.2 metadata documents that the view is defined over two referenced base objects: OE_TRANSACTION_TYPES_SYN (a synonym) and OE_TRANSACTION_TYPES_TL (the translation table synonym). The view text, however, selects from SO_ORDER_TYPES_ALL, the Order Management base table that stores order transaction type definitions, with the "_DF:OE:SO_ORDER_TYPES:SO_ORDER_TYPES_ALL" token reflecting the descriptive flexfield context. This apparent divergence reflects the retrofit lineage: the shipped SQL text references SO_ORDER_TYPES_ALL, while the documented dependency list reflects the synonym chain used by the current 12.2.2 object definition. Both descriptions should be treated as accurate for their respective contexts, and the relationship to the transaction type family is direct — one row per order type per operating unit.

Key Columns

  • ORDER_TYPE_NAME — the internal name of the sales order type, functionally the primary identifier.
  • CONVERSION_TYPE_CODE — the column the user searched for; it designates the conversion type associated with the order type, governing document numbering transitions or order classification behavior in Order Management.
  • "_LA:..." columns — translated lookup meanings for enforce price list, enforce line prices, shipment priority, shipping method, freight terms, agreement type and required flag, invoicing credit method, accounting credit method, and order category.
  • "_DF" — the descriptive flexfield context column for the order type.
  • START_DATE / END_DATE — effective dating that determines whether the order type is active.
  • CYCLE_ID, CURRENCY_CODE, PRICE_LIST_ID, WAREHOUSE_ID, INVOICING_RULE_ID, ACCOUNTING_RULE_ID, COST_OF_SALES_ACCOUNT_ID — defaults propagated to orders created under the type, including the currency, price list, ship-from warehouse, invoicing and accounting rules, and cost of goods sold account.
  • ORG_ID — the operating unit that owns the order type definition.
  • Audit columnsCREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY.

Common Use Cases and Queries

Typical scenarios include auditing which order types are active in an operating unit, listing conversion type assignments, and joining order headers to retrieve translated configuration values without additional lookup joins. The following query retrieves conversion type codes for active order types in a given operating unit:

SELECT order_type_name, conversion_type_code, currency_code, price_list_id
FROM apps.oebv_sales_order_types
WHERE org_id = :p_org_id
AND TRUNC(SYSDATE) BETWEEN NVL(start_date, SYSDATE) AND NVL(end_date, SYSDATE + 1);

A second common pattern filters by the search term directly:

SELECT order_type_name, conversion_type_code
FROM apps.oebv_sales_order_types
WHERE conversion_type_code IS NOT NULL;

Because the view is read-only and its labels are resolved through the language tokens, it is well suited to BI Publisher data models, OAF/Forms LOVs, and outbound integration extracts where consistent business-facing descriptions are required.