Search Results cs_transaction_types_tl_u2




Overview

CS.CS_TRANSACTION_TYPES_TL is the translation (multi-language) table for Service transaction types in Oracle E-Business Suite. It stores the language-dependent attributes of transaction types—specifically NAME and DESCRIPTION—while language-independent attributes such as the transaction type identifier and operational flags reside in the base table CS_TRANSACTION_TYPES_B. Together, the _B and _TL tables form a standard EBS translated entity pattern, where each transaction type row in the base table is accompanied by one translation row per installed language.

Transaction types classify the nature of service activities recorded in the Service (CS) module, such as repairs, installations, inspections, or returns. Because these names and descriptions are presented to end users in Service Depot Repair, Field Service, and TeleService forms, the translated values must be available in the session language. The table resides in the APPS_TS_SEED tablespace, consistent with its role as seed/reference data maintained via the translation and MLS (Multi-Lingual Support) frameworks.

Regarding Data Vault classification, the heuristic mined from the FK structure places this object as standalone. In a Data Vault modeling suggestion, this would most naturally be modeled as a satellite attached to the transaction-type hub (represented by the base table), since it simply carries descriptive, language-qualified attributes keyed by the parent entity and language rather than defining its own business relationship.

Key Information Stored

The combined primary key (CS_TRANSACTION_TYPES_TL_PK) consists of TRANSACTION_TYPE_ID and LANGUAGE. TRANSACTION_TYPE_ID is the numeric surrogate key joining back to CS_TRANSACTION_TYPES_B; LANGUAGE is the NLS language code identifying the translation.

Notable business-key candidates are defined by the unique indexes documented in ETRM 12.2.2:

The principal descriptive columns are:

  • NAME (VARCHAR2 90) — the translated transaction type name.
  • DESCRIPTION (VARCHAR2 720) — the translated description.
  • SOURCE_LANG — the language in which the base record was originally created, used by MLS to flag the source row.
  • LANGUAGE — the target translation language.
  • SECURITY_GROUP_ID — used in hosted/multi-tenant environments to segregate data; it references FND_SECURITY_GROUPS.
  • ZD_EDITION_NAME — editioning column used with EBS Online Patching (12.2) to maintain non-editioned compatibility; it participates in both unique indexes.

Standard Who columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN) provide auditing.

Common Use Cases and Queries

A frequent requirement is to report transaction type names in the current session language, joining the translation table to the base table. A typical pattern filters by LANGUAGE = USERENV('LANG'):

  • Query one language: SELECT tt.transaction_type_id, tt.name, tt.description FROM cs.cs_transaction_types_tl tt WHERE tt.language = USERENV('LANG') AND tt.transaction_type_id = :p_id;
  • List all translations for a type: filter on TRANSACTION_TYPE_ID only to see every language row.
  • Detect missing translations by comparing against FND_LANGUAGES installed.
  • Validate uniqueness conflicts surfaced by CS_TRANSACTION_TYPES_TL_U2 when NAME collides within a language.
  • Auditing/reporting joins to CS_TRANSACTION_TYPES_B to obtain base attributes.

Because the name uniqueness is enforced per language (and per edition), localization teams verify the U2 index before inserting new seed translations.

Related Objects

The most significant related objects are:

  • CS.CS_TRANSACTION_TYPES_B — the base table holding language-independent attributes; joined on TRANSACTION_TYPE_ID.
  • CS_TRANSACTION_TYPES_TL_PK and the unique indexes CS_TRANSACTION_TYPES_TL_U1 / CS_TRANSACTION_TYPES_TL_U2 — keys enforcing integrity.
  • FND_SECURITY_GROUPS — referenced by SECURITY_GROUP_ID.
  • FND_LANGUAGES — defines valid LANGUAGE values via NLS.
  • The Service setup UI (Transaction Types) and MLS APIs used to maintain translated seed data.

Queries should join these objects through TRANSACTION_TYPE_ID to assemble complete transaction type definitions.