Results for “wms_op_plans_tl”

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

Overview

WMS_OP_PLANS_TL is the translation (TL) table for the Warehouse Management operation plan base entity, WMS_OP_PLANS_B, within the Oracle E-Business Suite WMS module. It implements Oracle's standard Multi-Language Support (MLS) pattern, in which language-independent attributes of an operation plan reside in the _B base table while all translatable, user-facing text is stored here, one row per installed language. Operation plans represent reusable, named execution blueprints for warehouse operational tasks — receiving, put-away, picking, replenishment, and cycle counting — and the translatable layer ensures that plan names and descriptions are presented in the operator's session language across a global, multi-organization deployment.

From a Data Vault modeling perspective, the metadata's heuristic classification of this object is standalone. No foreign key relationships were mined from the constraints catalog, indicating that WMS_OP_PLANS_TL is not part of a normalized hub-and-link web but rather serves as a denormalized definition/translation store whose natural parent relationship to WMS_OP_PLANS_B is maintained by Oracle's MLS framework rather than by enforced referential constraints.

Key Information Stored

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

• OPERATION_PLAN_ID — the surrogate identifier of the parent operation plan; the first component of the composite primary key.
• LANGUAGE — the ISO language code of the translation row; the second primary key component and the discriminator that makes this a translated (TL) entity.
• OPERATION_PLAN_NAME — the translated display name of the operation plan, shown in WMS setup and execution screens.
• DESCRIPTION — the translated long description of the plan's purpose or scope.
• SOURCE_LANG — the language in which the base record was originally authored, used by MLS to determine when re-translation is required.
• ZD_EDITION_NAME — the editioning column supporting Oracle's Edition-Based Redefinition (EBR), enabling online patching. It participates in the unique index WMS_OP_PLANS_TL_U1 (OPERATION_PLAN_ID, LANGUAGE, ZD_EDITION_NAME).
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns tracking row provenance and change history.

The primary key WMS_OP_PLANS_TL_PK is declared on (OPERATION_PLAN_ID, LANGUAGE). The unique index WMS_OP_PLANS_TL_U1 on (OPERATION_PLAN_ID, LANGUAGE, ZD_EDITION_NAME) is the business-key candidate guaranteeing one translation per plan per language per edition.

Common Use Cases and Queries

Typical usage includes resolving translated plan labels for a user's session language, auditing which plans have translations in which languages, and reporting on translation completeness. A standard lookup joined to the base table:

• SELECT b.OPERATION_PLAN_ID, t.OPERATION_PLAN_NAME, t.DESCRIPTION FROM WMS.WMS_OP_PLANS_B b, WMS.WMS_OP_PLANS_TL t WHERE b.OPERATION_PLAN_ID = t.OPERATION_PLAN_ID AND t.LANGUAGE = USERENV('LANG');
• Translation coverage: SELECT OPERATION_PLAN_ID, COUNT(*) FROM WMS.WMS_OP_PLANS_TL GROUP BY OPERATION_PLAN_ID HAVING COUNT(*) > 1;
• Audit queries filtering on LAST_UPDATE_DATE to identify recently re-translated plan text.

Reports frequently restrict to LANGUAGE = 'US' for English-only extracts, and to the active ZD_EDITION_NAME value when querying under EBR-enabled 12.2.x environments.

Related Objects

• WMS_OP_PLANS_B — the base MLS table; joined on OPERATION_PLAN_ID. All non-translatable plan attributes reside here.
• WMS_OP_PLANS_VL — the MLS view exposing both base and translated columns for application consumption.
• WMS_OP_PLAN_STEPS / related step tables — child entities defining the tasks belonging to an operation plan.
• FND_LANGUAGES — reference table joined on LANGUAGE to obtain language descriptions.
• FND_TERRITORIES / FND_LANGUAGE — supporting localization reference data.

Application programming interface access is generally performed through the MLS view layer rather than direct DML against this table, reinforcing the standalone-classification suggested by the absence of mined foreign keys.