Results for “jtf_loc_types_vl”

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

Overview

JTF_LOC_TYPES_VL is a translation-enabled (VL) view owned by the APPS schema within the JTF – CRM Foundation product family. Its purpose is to expose location type definitions, combining the language-independent attributes stored in the base table with the language-specific, translatable text held in the translation table. Because Oracle EBS stores descriptive text separately for each installed language, this view is the standard access point that presents a single, current-language row per location type without requiring the caller to join the base and translation tables manually.

The view is reported as VALID in the documented ETRM metadata (consistent for both 12.1.1 and 12.2.2). It is typically consumed by CRM Trade Management (ETRM) and related foundation components that classify physical or logical locations — for example, ship-to, bill-to, warehouse, or customer site types. It is equally useful in reporting and integration layers, where a stable, user-facing label for a location type is required.

Underlying Base Objects

The view is defined over two documented base objects, both referenced as synonyms in the APPS schema:

• JTF_LOC_TYPES_B — the base table holding language-independent columns (identifier, code, audit columns, version number).
• JTF_LOC_TYPES_TL — the translation table holding the language-specific name and description keyed by language.

The join is performed on LOCATION_TYPE_ID, with the translation side filtered by T.LANGUAGE = USERENV('LANG'). This constraint ensures the query returns only the row(s) matching the session's current language, producing the expected single-row-per-type result. The view text also selects B.ROWID, exposed as ROW_ID.

Key Columns

• ROW_ID — the ROWID of the base table row; useful for high-performance, direct-row access.
• LOCATION_TYPE_ID — the primary identifier and join key linking base and translation records.
• LOCATION_TYPE_CODE — the non-translated, internal code used by application logic and interfaces.
• LOCATION_TYPE_NAME — the translatable display name shown to users in the current language.
• DESCRIPTION — the translatable descriptive text (mapped from LOCATION_TYPE_DESCRIPTION).
• Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN, inherited from the base table.
• OBJECT_VERSION_NUMBER — the optimistic-locking version used by the underlying framework.

Common Use Cases and Queries

Typical scenarios include populating location-type values in CRM or ETRM setup screens, generating reference listings for integrations, and validating that a location references a valid type. Because the view already resolves the current language, reports do not need to join the translation table themselves.

List all location types in the session language:

SELECT location_type_id,
       location_type_code,
       location_type_name
FROM   apps.jtf_loc_types_vl
ORDER  BY location_type_name;

Retrieve a single type by code for a lookup or validation:

SELECT location_type_id,
       location_type_name,
       description
FROM   apps.jtf_loc_types_vl
WHERE  location_type_code = :p_code;

Join to a transactional table requiring the translated label, for example resolving a stored type ID to its name:

SELECT x.some_record_id,
       lt.location_type_name
FROM   apps.some_crm_entity x,
       apps.jtf_loc_types_vl lt
WHERE  x.location_type_id = lt.location_type_id;

When writing custom SQL, bind or filter on LOCATION_TYPE_CODE rather than the translated name, since names vary by language. Integration extracts intended for multilingual environments should resolve the code and translate downstream, rather than relying on the session-language output of this view.