Search Results org_level_value




Overview
Explore in AI Chat

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

Overview

MSD_CS_DATA_V1 is a reporting view owned by the APPS schema within the MSD – Demand Planning product family in Oracle E-Business Suite 12.1.1 and 12.2.2. Per the documented ETRM description, the view exists specifically to support an Audit report. Demand Planning maintains configuration and consumption scenario data that end users may need to audit periodically, and this view provides a stable, flattened projection of that data. Because the underlying base object is a synonym pointing to the Demand Planning schema tables, the view deliberately shields report consumers and integration programs from direct dependency on the physical MSD tables. Its status is VALID, confirming that it compiles cleanly against the shipped data model. The view is most relevant to report developers and technical consultants who need to extract scenario definitions, level value assignments, and time-based planning quantities for audit or reconciliation purposes.

Underlying Base Objects

MSD_CS_DATA_V1 is defined as a SELECT over a single documented base object: MSD_CS_DATA, exposed as a synonym. The view projects a wide but curated subset of columns from that source, and applies one explicit transformation in the view text: TO_DATE(ATTRIBUTE_43, 'YYYY/MM/DD'). This indicates that the source stores ATTRIBUTE_43 as a character string in YYYY/MM/DD format, and the view converts it to a true DATE datatype for downstream reporting. All other projected columns, including the ATTRIBUTE_1 through ATTRIBUTE_44 range (with gaps, notably ATTRIBUTE_35 through ATTRIBUTE_40 being absent), are passed through directly. The view therefore inherits its grain and row count from MSD_CS_DATA, and any audit report built on it reflects the current state of that base table at query time.

Key Columns

The column list reveals a dimensional planning structure. Each planning dimension is represented by a paired set of columns:

  • ORG_LEVEL_ID, ORG_SR_LEVEL_VALUE_PK, ORG_LEVEL_VALUE, ORG_LEVEL_VALUE_PK — These carry the organization dimension. The user search term org_level_value maps directly to this view. ORG_LEVEL_ID identifies the level definition, ORG_LEVEL_VALUE holds the member value, and the PK columns carry the corresponding surrogate/primary key references used in source-level joins.
  • PRD_LEVEL_* — Product dimension, with PRD_PARENT_LEVEL_* providing the parent product hierarchy reference.
  • GEO_LEVEL_* — Geography dimension.
  • REP_LEVEL_* — Reporting/source dimension.
  • CHN_LEVEL_* — Channel dimension.
  • UD1_LEVEL_*, UD2_LEVEL_* — User-defined dimensions one and two.
  • TIME_LEVEL_ID, QUANTITY, AMOUNT, PRICE, END_DATE — Fact-style measures and the time reference. QUANTITY and AMOUNT are the core planning measures; PRICE supports valuation; END_DATE bounds the record.
  • CS_DEFINITION_ID, CS_NAME, INSTANCE — Identify the consumption/scenario definition and the planning instance to which the row belongs.

Common Use Cases and Queries

The principal use case is the Audit report referenced in the documentation. A typical audit extracts organization-level planning data for a scenario:

SELECT cs_name, INSTANCE, ORG_LEVEL_ID, ORG_LEVEL_VALUE,
       TIME_LEVEL_ID, QUANTITY, AMOUNT, PRICE, END_DATE
FROM   APPS.MSD_CS_DATA_V1
WHERE  ORG_LEVEL_VALUE = :org_level_value
AND    CS_NAME = :cs_name
ORDER BY TIME_LEVEL_ID;

A second common pattern reconciles fact measures against scenario definitions:

SELECT CS_DEFINITION_ID, CS_NAME,
       SUM(QUANTITY) total_qty, SUM(AMOUNT) total_amt,
       MIN(END_DATE) first_date, MAX(END_DATE) last_date
FROM   APPS.MSD_CS_DATA_V1
GROUP BY CS_DEFINITION_ID, CS_NAME;

Because the view exposes the converted ATTRIBUTE_43 as a proper DATE, reports can apply date range predicates without additional formatting logic. Integration programs may also use the view to stage audit extracts into external systems, relying on its VALID status and stable column list. Note that the view is read-only and performs no filtering; consumers should apply any scenario, instance, or organization predicate explicitly.