Results for “jtf_stores_vl”

18 results




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

Overview

JTF_STORES_VL is a seeded, VALID database view owned by the APPS schema in Oracle E-Business Suite. It belongs to the JTF product family, commonly designated CRM Foundation, which supplies the shared infrastructure objects used across Oracle's CRM applications such as Trade Management, iStore, and Field Service. The suffix "_VL" denotes a "view with language," a standard Oracle EBS naming convention indicating that the view joins a base (non-translated) table to its translation table and filters the translation rows according to the session's language. In this role, JTF_STORES_VL presents store definitions with their language-specific name and description attributes, exposing a single, MLS-aware row per store for the current runtime language. Because stores are a foundational CRM concept, this view is frequently referenced by reporting queries, concurrent programs, and integration interfaces that need to display or extract store information without embedding language-join logic themselves.

Underlying Base Objects

The view is defined over two documented base objects, both referenced as synonyms in the ETRM metadata: JTF_STORES_B and JTF_STORES_TL.

  • JTF_STORES_B — the base table holding language-independent store attributes, including the primary key STORE_ID, the OBJECT_VERSION_NUMBER used for optimistic locking, standard WHO audit columns, and fifteen descriptive flexfield (DFF) attribute columns.
  • JTF_STORES_TL — the translation table storing the translatable text columns STORE_NAME and STORE_DESCRIPTION, keyed by STORE_ID and LANGUAGE, with a SOURCE_LANG column identifying the language from which a translation was derived.

The view joins the two on STORE_ID and restricts the result to rows where L.LANGUAGE equals USERENV('LANG'), the language of the current database session. This is the mechanism that renders the view multilingual: each user sees store text in their own session language, with no application-side filtering required.

Key Columns

  • ROW_ID — the ROWID of the underlying JTF_STORES_B row, exposed for updatable-view and row-identification purposes.
  • STORE_ID — the primary identifier of the store; the join key between the base and translation tables.
  • OBJECT_VERSION_NUMBER — the concurrency-control column used by the framework to detect conflicting updates.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns recording creation and last-modification context.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — descriptive flexfield columns that allow customers to extend the store entity with site-specific attributes without schema changes.
  • LANGUAGE, SOURCE_LANG — the language of the returned translation and the source language of that translation, respectively.
  • STORE_NAME, STORE_DESCRIPTION — the translated, language-sensitive descriptive text for the store.

Common Use Cases and Queries

Typical usage centers on lists, validation, and integration extracts that must be language-aware. A conventional query retrieving all stores visible to the session is:

SELECT store_id, store_name, store_description FROM jtf_stores_vl ORDER BY store_name;

For a single store lookup, the STORE_ID is the standard predicate:

SELECT store_id, store_name FROM jtf_stores_vl WHERE store_id = :p_store_id;

Joins to dependent store-related entities commonly use this view on the STORE_ID key, providing translated names directly to reports and OAF/Forms pages. Because the LANGUAGE predicate is bound to USERENV('LANG'), no additional language filter is necessary. Queries should generally avoid selecting the ROW_ID column for business logic, as it is exposed primarily to support updatable-view behavior, and should rely on STORE_ID as the stable business key.