Search Results msd_dimensions_lb

Overview

APPS.MSD_DP_DIMENSIONS_V is a reporting view within the Oracle E-Business Suite Advanced Supply Chain Planning / Demand Planning schema (MSD). It exposes the dimension configuration associated with demand plans, joining the physical configuration table MSD_DP_DIMENSIONS to plan header data and to two independent lookups of FND_LOOKUP_VALUES_VL that resolve the coded dimension values into user-facing meanings. In Oracle EBS 12.1.1 and 12.2.2 the view serves as the canonical, translation-aware read interface for demand planning dimension metadata, and it is the object that surfaces the MSD_DIMENSIONS_LB lookup type that users frequently search for when investigating liability-plan dimensions.

The view is owned by APPS and is intended for concurrent-program and form-based queries rather than for direct DML. All transactional columns are inherited from MSD_DP_DIMENSIONS, so the view behaves as a denormalized, meaning-enriched projection of that table.

Underlying Base Objects

The documented base objects referenced by the view are:

• MSD_DP_DIMENSIONS (synonym) — the driving table, supplying demand_plan_id, dp_dimension_code, dimension_code, deleteable_flag, enable_nonseed_flag, and the standard WHO audit columns (creation_date, created_by, last_update_date, last_updated_by, last_update_login) plus the concurrent request columns (request_id, program_application_id, program_id, program_update_date).
• MSD_DEMAND_PLANS (synonym) — joined on demand_plan_id to supply the plan name and, critically, the plan_type used to drive the DECODE logic that selects the correct lookup type.
• FND_LOOKUP_VALUES_VL (view) — referenced twice. The FLV1 instance resolves dp_dimension_code; the FLV2 instance resolves dimension_code. Because the VL variant is used, lookup meanings are returned in the session's current language.

The DECODE on mdp.plan_type is the structural key to the view: when plan_type equals 'LIABILITY', both lookups resolve against lookup type MSD_DIMENSIONS_LB; for all other plan types, FLV1 uses MSD_USER_DIMENSIONS and FLV2 uses MSD_DIMENSIONS. This conditional lookup selection is the reason the MSD_DIMENSIONS_LB lookup type appears exclusively in the context of liability-type demand plans.

Key Columns

• DEMAND_PLAN_ID / DEMAND_PLAN_NAME — the plan identifier and its display name, taken from the plan header.
• DP_DIMENSION_CODE / MEANING (FLV1) — the high-level dimension code and its translated meaning, resolved against MSD_DIMENSIONS_LB or MSD_USER_DIMENSIONS.
• DIMENSION_CODE / MEANING (FLV2) — the lower-level dimension code and meaning, resolved against MSD_DIMENSIONS_LB or MSD_DIMENSIONS.
• DELETEABLE_FLAG — indicates whether the dimension row can be removed by the user.
• ENABLE_NONSEED_FLAG — indicates whether non-seed (user-defined) members are permitted for the dimension.
• ROWID — the physical row identifier of the underlying MSD_DP_DIMENSIONS row, permitting precise navigation back to the base record.
• Audit and request columns — support audit reporting and traceability to the concurrent program that last modified the configuration.

Common Use Cases and Queries

Typical uses include reviewing dimension setup for a plan, diagnosing missing lookup meanings for liability plans, and driving integration extracts that require translated dimension labels.

List all dimensions for a named plan:

• SELECT demand_plan_name, dp_dimension_code, meaning, dimension_code, enable_nonseed_flag FROM apps.msd_dp_dimensions_v WHERE demand_plan_name = :plan_name;

Find liability plans that rely on the MSD_DIMENSIONS_LB lookup type:

• SELECT DISTINCT demand_plan_name FROM apps.msd_dp_dimensions_v WHERE demand_plan_id IN (SELECT demand_plan_id FROM apps.msd_demand_plans WHERE plan_type = 'LIABILITY');

Detect unresolvable codes where the joins returned NULL meanings:

• SELECT demand_plan_name, dp_dimension_code, dimension_code FROM apps.msd_dp_dimensions_v WHERE meaning IS NULL;

Because the view performs inner joins to MSD_DEMAND_PLANS and both lookup instances, a row appears only when the plan exists and both dimension codes have active lookup values in the applicable lookup type; when a lookup entry is missing or end-dated, the row drops out entirely. This behaviour should be accounted for when the view is used as the source of reconciliation or load programs.