Search Results msc_x_exception_details




Overview
Explore in AI Chat

Overview

MSC_X_EXCEPTION_DETAILS is a transactional table in the MSC schema belonging to the Oracle Advanced Supply Chain Planning (ASCP) product family, with specific relevance to Oracle Collaborative Planning. The table stores the exception detail records generated during collaborative planning runs, capturing the discrepancies, threshold breaches, and planning anomalies that planners and trading partners must review and resolve. Each row represents a single exception instance tied to a plan, an entity (company, site, supplier, customer, or item), and a set of contextual attributes describing the transaction or order that triggered the exception.

In the ETRM 12.2.2 schema documentation, the table is owned by MSC and contains 86 columns. Under the heuristic Data Vault classification derived from its foreign key structure, MSC_X_EXCEPTION_DETAILS is modeled as a standalone table, meaning it does not participate in a parent-child hub-and-link structure within the mined relationship data. From a practical modeling standpoint it behaves as a satellite-style detail table anchored on its own unique key, holding descriptive exception attributes rather than serving as an integration point between business entities.

Key Information Stored

The surrogate primary key is EXCEPTION_DETAIL_ID, which is also the sole business-key candidate documented through the unique index MSC_X_EXCEPTION_DETAILS_U1. This column uniquely identifies each exception detail row and is the correct join key for downstream references.

Identifier and context columns establish which plan and instance produced the exception: PLAN_ID, SR_INSTANCE_ID, TRANSACTION_ID1 through TRANSACTION_ID3, and VERSION. Classification columns describe the nature of the exception: EXCEPTION_TYPE, EXCEPTION_TYPE_NAME, EXCEPTION_GROUP, EXCEPTION_GROUP_NAME, EXCEPTION_BASIS, and REPLENISHMENT_METHOD. Party and entity columns identify the affected trading relationship: COMPANY_ID, COMPANY_NAME, COMPANY_SITE_ID, COMPANY_SITE_NAME, SUPPLIER_ID, SUPPLIER_NAME, CUSTOMER_ID, CUSTOMER_NAME, and OWNING_COMPANY_ID. Item context is carried by INVENTORY_ITEM_ID, ITEM_NAME, ITEM_DESCRIPTION, TRADING_PARTNER_ITEM_NAME, CUSTOMER_ITEM_NAME, and SUPPLIER_ITEM_NAME.

Order-level detail is captured in ORDER_NUMBER, RELEASE_NUMBER, LINE_NUMBER, END_ORDER_NUMBER, END_ORDER_REL_NUMBER, and END_ORDER_LINE_NUMBER, with corresponding dates in ORDER_CREATION_DATE1, ORDER_CREATION_DATE2, and DATE1 through DATE7. Quantitative thresholds and constraints are stored in NUMBER1 through NUMBER10, LEAD_TIME, ITEM_MIN_QTY, ITEM_MAX_QTY, and THRESHOLD. Twenty USER_ATTRIBUTE columns provide extensibility, while standard audit columns CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN track row lifecycle.

Common Use Cases and Queries

Collaborative Planning exception reports are the primary consumer of this table. A typical query retrieves all exceptions for a given plan and exception type, joined to item and party names for planner review:

  • Select EXCEPTION_TYPE_NAME, ITEM_NAME, CUSTOMER_NAME, THRESHOLD, NUMBER1 FROM MSC_X_EXCEPTION_DETAILS WHERE PLAN_ID = :plan_id AND EXCEPTION_GROUP = 'SUPPLIER';
  • Aggregate exception counts by company or site to drive workload dashboards: GROUP BY COMPANY_ID, COMPANY_SITE_ID.
  • Filter by SUPPLIER_ID or CUSTOMER_ID to produce partner-facing exception extracts for supplier collaboration or customer demand review.
  • Use date ranges on ORDER_CREATION_DATE1 or DATE1 through DATE7 to isolate exceptions arising within a planning horizon.

Because PLAN_ID and SR_INSTANCE_ID are present, queries are typically scoped to a single planning run and its source instance to avoid mixing results across plans.

Related Objects

Two documented foreign keys anchor this table to party master data: COMPANY_ID references PN_COMPANIES_ALL and COMPANY_SITE_ID references PN_COMPANY_SITES_ALL. These joins resolve company and site names where denormalized values are not populated. Beyond the documented relationships, exception detail rows logically align with parent exception and plan structures in the MSC schema, and with item master data through INVENTORY_ITEM_ID referencing MTL_SYSTEM_ITEMS_B. Reporting layers frequently join MSC_X_EXCEPTION_DETAILS to MSC_PLANS and MSC_SYSTEM_ITEMS for plan and item metadata. As a standalone table in the mined FK model, it has no dependent child tables documented, so it functions as a leaf-level detail repository consumed by concurrent programs, OBIEE-style reports, and custom planner dashboards rather than as a parent for further relationships.