Search Results msd_dp_calendars_u1

Overview

MSD.MSD_DP_CALENDARS is a transactional table in the Oracle E-Business Suite 12.1.1 / 12.2.2 environment, owned by the MSD schema. It stores Demand Plan related Calendars, acting as the association layer that binds a specific calendar type and calendar code to an individual Demand Plan. Within Advanced Supply Chain Planning and Demand Planning, calendars define the working-day and time-bucket patterns that drive forecasting, planning horizons, and bucket-based aggregation. This table therefore determines which calendars are available to a given demand plan and how non-seed calendar records are governed.

From a heuristic Data Vault modeling perspective, the table is classified as satellite-leaning. This reflects its structure: the composite business key (DEMAND_PLAN_ID, CALENDAR_TYPE, CALENDAR_CODE) sits at the core, and the remaining attributes are largely descriptive or governance flags, which is characteristic of a satellite attached to a demand-plan hub rather than a true hub or link in its own right. Treating it as a satellite is a modeling suggestion, not a physical constraint enforced by EBS.

Key Information Stored

The table contains 15 documented columns. The most significant are the business-key constituents and the descriptive and governance attributes that surround them.

• DEMAND_PLAN_ID (NUMBER, 15) — The Demand Plan identifier. This is a mandatory business-key column and is also the foreign key that links the row to its parent demand plan.
• CALENDAR_TYPE (VARCHAR2, 30) — The type classification of the calendar (for example, a planning or manufacturing style calendar category). Part of the composite business key.
• CALENDAR_CODE (VARCHAR2, 30) — The specific calendar code assigned to the demand plan. Part of the composite business key and the practical identifier planners reference.
• ZD_EDITION_NAME (VARCHAR2, 30) — The edition name associated with the record, used to scope the row within an edition-aware context. Also included as the trailing column of the unique index.
• DELETEABLE_FLAG (VARCHAR2, 15) — Indicates whether the record may be deleted, protecting seeded or system-managed associations.
• ENABLE_NONSEED_FLAG (VARCHAR2, 15) — Indicates whether fields for non-seeded records should be disabled, supporting controlled maintenance of user-created rows.
• Who columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN.
• Extended who columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, capturing the concurrent program context of the last change.

The physical primary key is MSD_DP_CALENDARS_PK, defined on (CALENDAR_CODE, CALENDAR_TYPE, DEMAND_PLAN_ID). The unique index MSD_DP_CALENDARS_U1, defined on (DEMAND_PLAN_ID, CALENDAR_TYPE, CALENDAR_CODE, ZD_EDITION_NAME), is the principal business-key candidate and differs from the PK only by including the edition-name column. The user query for msd_dp_calendars_u1 corresponds to this unique index.

Common Use Cases and Queries

Typical uses include validating which calendars are attached to a demand plan, auditing seeded versus non-seeded calendar rows, and bulk reconciliation across plans.

• List all calendars for a plan: SELECT calendar_type, calendar_code, deleteable_flag FROM msd.msd_dp_calendars WHERE demand_plan_id = :plan_id ORDER BY calendar_type, calendar_code;
• Identify protected rows: SELECT * FROM msd.msd_dp_calendars WHERE deleteable_flag = 'N';
• Canonical full extraction: SELECT demand_plan_id, calendar_type, calendar_code, creation_date, created_by, last_update_date, last_updated_by, last_update_login, request_id, program_application_id, program_id, program_update_date, deleteable_flag, enable_nonseed_flag, zd_edition_name FROM msd.msd_dp_calendars;
• Trace the originating concurrent request: SELECT demand_plan_id, program_id, request_id, program_update_date FROM msd.msd_dp_calendars WHERE program_application_id = :app_id;

Because the unique index leads with DEMAND_PLAN_ID and CALENDAR_TYPE, equality predicates on those columns yield the most efficient access paths.

Related Objects

The documented dependency data shows a single outgoing relationship and a sibling internal object.

• MSD.MSD_DEMAND_PLANS — Parent table; joined via MSD_DP_CALENDARS.DEMAND_PLAN_ID = MSD_DEMAND_PLANS.DEMAND_PLAN_ID. This is the only documented foreign-key reference. [documented]
• MSD.MSD_DP_CALENDARS# — The internal object referenced by this table. [documented]
• MSD_DP_CALENDARS_PK — Primary-key constraint/index on (CALENDAR_CODE, CALENDAR_TYPE, DEMAND_PLAN_ID). [documented]
• MSD_DP_CALENDARS_U1 — Unique index on (DEMAND_PLAN_ID, CALENDAR_TYPE, CALENDAR_CODE, ZD_EDITION_NAME). [documented]

In practice, demand planning calendar logic also intersects with the broader MSD calendar and planning tables (such as planning calendar definitions and demand plan headers) and with the MSC/MRP collections interface. Those links should be confirmed against the target instance. The table does not reference any other database object, confirming its relatively self-contained dependency footprint.