Search Results accounting_credit_method_code




Overview

WSH_TRANSACTION_TYPES_VL is an APPS-owned view in the Oracle E-Business Suite Shipping Execution (WSH) module. Despite its WSH prefix, the view is defined entirely over Order Management (OE) transaction type tables, functioning as a shipping-facing presentation layer that exposes the transaction type definitions used to classify sales documents. The _VL suffix denotes a "view with language" — the view performs an implicit join to the translated table and filters on the session language via USERENV('LANG'), returning the translated name and description appropriate to the logged-in user.

For EBS 12.1.1 and 12.2.2 the definition is unchanged. Its principal reporting role is as a lookup source for order category, invoicing, accounting, credit-checking, and costing attributes associated with a given transaction type. Because it exposes COST_OF_GOODS_SOLD_ACCOUNT, the view is frequently queried when users investigate how cost of goods sold is derived for a given order type — a common search term in ETRM and in shipping/OM troubleshooting.

Underlying Base Objects

The view is defined over two documented synonyms:

  • OE_TRANSACTION_TYPES_ALL — the transactional (non-translated) table holding the bulk of the columns, including COST_OF_GOODS_SOLD_ACCOUNT. It is aliased as B in the view text.
  • OE_TRANSACTION_TYPES_TL — the translation table supplying NAME and DESCRIPTION per language. It is aliased as T.

The join is on TRANSACTION_TYPE_ID, with the additional predicate T.LANGUAGE = USERENV('LANG'). A filter row exists: B.SALES_DOCUMENT_TYPE_CODE <> 'B', which excludes one sales document type code from the result set. The _ALL table is multi-org enabled (ORG_ID is exposed), so returned rows are subject to the operating unit context of the query.

Key Columns

Common Use Cases and Queries

The view supports reporting on transaction type setup, especially when the translated name is required alongside costing and invoicing parameters. Typical scenarios include auditing which order types post to which COGS account, validating credit check rules, and joining order headers to their type definitions.

Example — list transaction types and their COGS account for the current operating unit:

SELECT transaction_type_id,
       transaction_type_code,
       name,
       order_category_code,
       cost_of_goods_sold_account,
       currency_code
FROM   apps.wsh_transaction_types_vl
WHERE  org_id = :p_org_id
ORDER  BY name;

Example — find all transaction types using a specific COGS account:

SELECT transaction_type_id, name, org_id
FROM   apps.wsh_transaction_types_vl
WHERE  cost_of_goods_sold_account = :p_cogs_account;

Example — join to order headers for reporting:

SELECT h.order_number, t.name, t.cost_of_goods_sold_account
FROM   apps.oe_order_headers_all h,
       apps.wsh_transaction_types_vl t
WHERE  h.transaction_type_id = t.transaction_type_id;

Sample queries should be run with an appropriate operating unit context, since ORG_ID filtering governs the visible transaction types.