Search Results jts_config_versions_tl




Overview
Explore in AI Chat

Overview

JTS_CONFIG_VERSIONS_TL is a translated (language-enabled) table within the JTS – CRM Self Service Administration module of Oracle E-Business Suite. The JTS module itself is flagged as obsolete in the ETRM metadata, meaning its functional footprint has largely been superseded by other CRM Self Service administration components in both EBS 12.1.1 and 12.2.2. The table stores Configuration Versions as presented on the Version Summary Page. As a "_TL" table, it holds translated, language-specific descriptive content for each configuration version, while the base (non-translated) attributes reside in the corresponding base table.

From a data-modelling perspective, the ETRM metadata classifies this object heuristically as standalone under Data Vault conventions. In practice, this suggests it functions more as a descriptive satellite of the version entity (VEA_VERSIONS) rather than as an independent hub or a pure link. The standalone classification arises because its foreign-key relationships do not form a classic many-to-many bridge; instead, it enriches an upstream version record with translated attribute data.

Key Information Stored

The table contains 11 documented columns. The most significant are:

  • VERSION_ID – Primary surrogate identifier for the configuration version; also a foreign key to VEA_VERSIONS and part of the unique index.
  • CONFIGURATION_ID – Identifies the parent configuration to which the version belongs.
  • LANGUAGE – The language code of this translated row; combined with VERSION_ID it forms the business-key candidate.
  • SOURCE_LANG – The source language from which this translation derives, used for language comparison logic.
  • DESCRIPTION – The translated descriptive text surfaced on the Version Summary Page.
  • SECURITY_GROUP_ID – Foreign key to FND_SECURITY_GROUPS; enforces data-level security partitioning.
  • CREATION_DATE, CREATED_BY – Standard audit columns recording row creation.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN – Standard audit columns recording the most recent modification.

The unique index JTS_CONFIG_VERSIONS_TL_U1 (VERSION_ID, LANGUAGE) is the documented business-key candidate, ensuring exactly one translation per version per language. The surrogate primary key remains VERSION_ID for the base entity, with LANGUAGE discriminating translated rows.

Common Use Cases and Queries

Because this table backs a Version Summary Page in the Self Service Administration UI, typical queries retrieve translated version descriptions for a given configuration and language. A common reporting pattern joins the translated row to its base version and parent configuration:

  • Listing all versions for a configuration with their descriptions: SELECT vc.version_id, vc.description FROM jts_config_versions_tl vc WHERE vc.configuration_id = :config_id AND vc.language = USERENV('LANG');
  • Detecting missing translations: compare base table version IDs against translated rows for a target language.
  • Security-filtered lookups: restrict results by SECURITY_GROUP_ID to align with the responsibility's security profile.
  • Audit reporting: use LAST_UPDATE_DATE and LAST_UPDATED_BY to track translation maintenance activity.

Note that the ETRM metadata lists this table as "Not implemented in this database," so absolute row volumes and usage patterns depend on whether the JTS self-service configuration feature was ever deployed.

Related Objects

The most significant related objects, derived from the documented foreign-key structure, are:

  • VEA_VERSIONS – Referenced by VERSION_ID; the base version entity that this translated table augments.
  • FND_SECURITY_GROUPS – Referenced by SECURITY_GROUP_ID; provides data-level security partitioning.
  • JTS_CONFIG_VERSIONS (base / _B table) – Holds the non-translated columns and is joined on VERSION_ID.
  • FND_LANGUAGES – Logical dependency for LANGUAGE and SOURCE_LANG values.
  • FND_APPLICATION / FND_LOOKUPS – Common reference objects when resolving language and status descriptions in reports.

Application logic accessing these objects would typically flow through the JTS self-service administration UI rather than through documented public APIs, given the module's obsolete status.