Results for “msd_cs_definitions_tl”

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

Overview

MSD_CS_DEFINITIONS_TL is the translation table for MSD_CS_DEFINITIONS within the Oracle EBS Demand Planning (MSD) module. In Oracle Applications, the "_TL" suffix denotes a table that stores language-specific, translatable attributes for a base ("_B" or primary) entity. In this case, MSD_CS_DEFINITIONS_TL holds the translatable descriptive text — most notably the DESCRIPTION column — associated with each Compass/Planning Server (CS) definition row stored in its parent table. Each row represents one language rendition of a given definition, allowing the same underlying definition to be presented in multiple installed languages.

From a data-modeling perspective, the ETRM metadata classifies this object heuristically as standalone from its foreign-key structure. This suggests that, for Data Vault modeling purposes, the table behaves effectively as a satellite attached to the core definition entity, carrying descriptive and multi-lingual attributes keyed to that entity. The absence of declarative foreign keys in the mined relationship data means referential integrity to the base table is enforced by application logic rather than by database constraints.

Key Information Stored

The documented physical schema for 12.2.2 comprises 14 columns. The most significant are:

• CS_DEFINITION_ID — the identifier of the parent definition in MSD_CS_DEFINITIONS; the primary business reference and part of the composite primary key.
• LANGUAGE — the NLS language code for the translated row; the second component of the composite primary key.
• DESCRIPTION — the translatable descriptive text for the definition, the principal attribute this table exists to store.
• SOURCE_LANG — the language from which the row was originally created or translated.
• ZD_EDITION_NAME — an editioning column used by Oracle E-Business Suite online patching (Edition-Based Redefinition), supporting zero-downtime upgrades in 12.2.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard WHO audit columns tracking row provenance and change history.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program audit columns identifying the job that inserted or updated the row.

The surrogate primary key is defined by MSD_CS_DEFINITIONS_TL_PK on (CS_DEFINITION_ID, LANGUAGE). A separate unique index, MSD_CS_DEFINITIONS_TL_U1, is defined on (CS_DEFINITION_ID, LANGUAGE, ZD_EDITION_NAME), which acts as the business-key candidate governing uniqueness under online patching.

Common Use Cases and Queries

Because this is a translation table, it is most often joined to its base entity filtered by the session or reporting language. A typical query retrieves the localized description for a set of definitions:

SELECT b.cs_definition_id, t.description
FROM   msd.msd_cs_definitions_tl t
WHERE  t.language = USERENV('LANG')
AND    t.cs_definition_id = :p_id;

For multi-language reporting or migration audits, developers enumerate all renditions of a definition or identify gaps where translations are missing:

SELECT cs_definition_id, language, description
FROM   msd.msd_cs_definitions_tl
WHERE  cs_definition_id = :p_id
ORDER  BY language;

Common scenarios include localization validation (confirming every definition has rows for all installed languages), upgrade and patching verification (checking ZD_EDITION_NAME population), and analytics extracts that require language-specific labels for downstream demand-planning reports.

Related Objects

The primary related object is MSD_CS_DEFINITIONS, the base table whose translatable content this table carries, joined on CS_DEFINITION_ID. The following objects are the most significant to consider when working with this table:

• MSD_CS_DEFINITIONS — base (non-translated) definition entity; join on CS_DEFINITION_ID.
• MSD_CS_DEFINITIONS_TL unique index MSD_CS_DEFINITIONS_TL_U1 and primary key MSD_CS_DEFINITIONS_TL_PK — constrain and index access paths.
• Standard EBS audit joins to FND_USER on CREATED_BY / LAST_UPDATED_BY for change traceability.
• Concurrent program auditing via FND_CONCURRENT_REQUESTS on REQUEST_ID.
• Language validation against FND_LANGUAGES on LANGUAGE.

Because the metadata indicates a standalone classification with no declared foreign keys, joins to these parent and reference tables must be constructed explicitly on the columns named above rather than relying on enforced constraints.