Search Results gmd_actions_tl_pk

Overview

GMD_ACTIONS_TL is the translation table for OPM Quality action codes within the Oracle E-Business Suite Process Manufacturing Product Development (GMD) module. In Oracle EBS Release 12.1.1 and 12.2.2, the "_TL" suffix denotes a translated table that stores language-specific descriptive text for a base entity — in this case, quality action definitions used in Process Manufacturing quality workflows. Each row supplies the translated description of an action code in a specific installed language.

Structurally, the object is a narrow, language-keyed reference table. The ETRM metadata classifies it heuristically as standalone, meaning it does not participate in a large web of enforced foreign-key links. Under a Data Vault modeling lens, this data object most naturally maps to a satellite — descriptive, descriptive-of-key attributes (the translated descriptions) attached to the business key formed by action code plus language. It could also be treated as a small reference/dimension table in a conventional star schema.

Key Information Stored

The table holds nine documented columns. The most significant are:

• ACTION_CODE — the business identifier for the quality action; part of the composite primary key.
• LANGUAGE — the language identifier for the translated row; the second component of the composite primary key.
• ACTION_DESC — the translated description of the action code, which is the primary payload of the translation table.
• SOURCE_LANG — the source language from which the translation was derived, supporting multilingual maintenance.
• CREATION_DATE, CREATED_BY — audit columns recording when and by whom the row was inserted.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — audit columns capturing the most recent modification and the login context of the updater.

The surrogate primary key is defined by GMD_ACTIONS_TL_PK, comprising ACTION_CODE and LANGUAGE. Because the same composite of columns also forms the unique index, the primary key is simultaneously the business-key candidate; there is no separate meaningless surrogate. The combination of action code and language uniquely identifies each translated description and guarantees one description per action per language.

Common Use Cases and Queries

Typical usage centers on presenting action descriptions in the user's session language. A common pattern joins the translation table to the base action table so that only rows matching the current language are returned:

• Resolving the display name for an action code in a specific language: SELECT action_desc FROM gmd_actions_tl WHERE action_code = :code AND language = USERENV('LANG').
• Auditing which action codes have translations for a given language, useful when deploying a new language and verifying coverage.
• Comparing ACTION_DESC against SOURCE_LANG to detect rows that fall back to the base language because no local translation exists.
• Integration and migration scripts that load translated text for quality actions during multi-language implementations.
• Reporting on the multilingual completeness of quality action definitions across the enterprise.

Because the object is standalone, queries generally drive from a base action or quality configuration table and pick up descriptions via a join on ACTION_CODE and LANGUAGE.

Related Objects

As a translation table, GMD_ACTIONS_TL is referenced primarily through the base action entity rather than through enforced foreign keys. The most significant related objects are:

• GMD_ACTIONS (base table) — the untranslated action definitions joined on ACTION_CODE.
• GMD_ACTIONS_B — the base-table variant holding the canonical action rows.
• FND_LANGUAGES — the language registry, joined on LANGUAGE to validate installed languages.
• OPM Quality setup and specification screens that display action descriptions to the user.
• Public APIs and concurrent programs in the GMD module that resolve action descriptions during processing.
• Translation-maintenance utilities and the standard "_TL" pattern objects within the same schema.

Because the metadata indicates a standalone classification, no strong foreign-key dependencies are documented; joins to base and language tables are performed logically on the shared business keys.