Search Results msd_deleted_level_values




Overview
Explore in AI Chat

Overview

MSD.MSD_DELETED_LEVEL_VALUES is a table within the Oracle E-Business Suite Demand Planning module (product code MSD). Its documented purpose is to store information about level values that have been deleted, capturing both the system-generated primary key and the associated level value attributes. A defining characteristic of this table, noted explicitly in the ETRM metadata, is that its contents are not stripped by the Demand Plan Id. This means the deleted level value records are retained independent of any specific demand plan, distinguishing it from tables that are segmented or purged on a per-plan basis.

From a data modeling perspective, the metadata classifies this object heuristically as standalone based on its foreign key structure. Under a Data Vault interpretation, this suggests the table behaves more like a satellite-style record set, holding descriptive and auditable attributes around a level reference rather than acting as a hub or a link between multiple business entities. Its single documented foreign key (LEVEL_ID to MSD_LEVELS) reinforces this, pointing to a single parent dimension rather than a junction of several.

Key Information Stored

The table exposes 16 documented columns. The most significant are summarized below.

  • LEVEL_ID — The foreign key referencing MSD_LEVELS. It identifies the planning level to which the deleted value belonged and is the primary business-key candidate for joining back to level definitions.
  • LEVEL_VALUE — The actual value of the level that was deleted, i.e., the descriptive content preserved for audit or reconciliation.
  • SR_LEVEL_PK — The system-generated primary key (surrogate key) for the deleted level value record. This is the system-level unique identifier.
  • LEVEL_PK — A primary key reference associated with the level, complementing SR_LEVEL_PK in identifying the parent level instance.
  • INSTANCE — Identifies the instance context of the record.
  • LAST_UPDATE_DATE, CREATION_DATE — Standard audit timestamps marking when the deleted value record was last changed and originally created.
  • LAST_UPDATED_BY, CREATED_BY, LAST_UPDATE_LOGIN — Standard EBS who-columns identifying the user and login session responsible for the record.
  • REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Concurrent program context that identifies which batch or request last touched the record.
  • LAST_REFRESH_NUM, CREATED_BY_REFRESH_NUM — Refresh-sequence counters that track the refresh cycle in which the record was created or last updated.

No unique index is documented beyond the surrogate key, so SR_LEVEL_PK should be treated as the reliable primary key, while LEVEL_ID and LEVEL_VALUE serve as descriptive business attributes.

Common Use Cases and Queries

Because the table retains deleted level values outside the demand plan scope, it is primarily used for auditing, recovery, and reconciliation of level definitions. Typical queries include retrieving the deleted values for a given level and auditing who removed them.

  • Listing deleted values for a level: SELECT LEVEL_ID, LEVEL_VALUE, SR_LEVEL_PK, LAST_UPDATE_DATE FROM MSD.MSD_DELETED_LEVEL_VALUES WHERE LEVEL_ID = :level_id;
  • Auditing deletions by user or date: filter on LAST_UPDATED_BY and LAST_UPDATE_DATE to trace when values were removed.
  • Correlating with concurrent program runs using REQUEST_ID and PROGRAM_ID.
  • Reconciling surviving level values in MSD_LEVELS against their deleted counterparts via a LEFT OUTER JOIN on LEVEL_ID.

Related Objects

  • MSD_LEVELS — Parent table referenced through LEVEL_ID; holds the level definitions to which deleted values belong.
  • Standard EBS audit and concurrent program tables (e.g., FND_USER, FND_CONCURRENT_REQUESTS) implied by the who-columns and REQUEST_ID.
  • Demand Planning level and plan views that surface level values, which may conflict or reconcile with this deleted-value staging table.

As a standalone, plan-independent retention table, MSD_DELETED_LEVEL_VALUES serves a focused historical and auditing role within the Demand Planning schema.