Results for “msc_exception_details_u1”

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

Overview

MSC.MSC_EXCEPTION_DETAILS is the detail-level persistence table for exceptions generated by Oracle Advanced Planning and Scheduling (APS) and the Oracle Supply Chain Hub. Where the parent exception header identifies that an exception was raised against a plan, this table records the granular facts associated with a single exception occurrence: the plan, the source instance, the organization, the item, resource or department involved, the exception type, the quantity, and a set of generic typed columns (DATE1–DATE6, NUMBER1–NUMBER8, CHAR1–CHAR2) that carry exception-specific attributes without requiring schema changes. In Oracle EBS 12.1.1 and 12.2.2, the table is owned by the MSC schema and is documented as VALID.

From a modeling perspective, the mined foreign key structure suggests a Data Vault classification of link. The table predominantly intersects business keys from multiple hubs — plan, inventory item, organization, department, resource, supplier, customer, and source instance — and carries descriptive, exception-contextual attributes rather than serving as a pure hub of a single business concept. This classification is a heuristic derived from the FK topology and should be treated as a modeling suggestion rather than a documented Oracle design statement.

Key Information Stored

The primary key is MSC_EXCEPTION_DETAILS_PK, defined across PLAN_ID, SR_INSTANCE_ID and EXCEPTION_DETAIL_ID. The unique index MSC_EXCEPTION_DETAILS_U1 (PLAN_ID, EXCEPTION_DETAIL_ID, SR_INSTANCE_ID) is the business-key candidate that enforces this combination; EXCEPTION_DETAIL_ID alone is the surrogate detail identifier but only becomes unique in combination with the plan and source instance. The most significant columns include:

• EXCEPTION_DETAIL_ID — surrogate identifier for the exception detail record.
• PLAN_ID — the plan under which the exception was generated; a leading column in the primary key and in every documented index.
• SR_INSTANCE_ID — the source application instance, essential when multiple source systems feed the planning schema.
• EXCEPTION_TYPE — numeric classification of the exception (resource, material, and similar categories).
• QUANTITY — the exception quantity associated with the detail.
• ORGANIZATION_ID, INVENTORY_ITEM_ID, RESOURCE_ID, DEPARTMENT_ID — the supply chain context resolved through the supporting indexes.
• SUPPLIER_ID, SUPPLIER_SITE_ID, CUSTOMER_ID, CUSTOMER_SITE_ID — trading partner context for order-oriented exceptions.
• ORDER_NUMBER, ORDER_REL_NUMBER, ORDER_LINE_NUMBER and the END_ORDER_* variants — order lifecycle references.
• ACTION_TAKEN, ACTION_TAKEN_BY, ACTION_TAKEN_DATE, CAUSE, NEW_EXCEPTION — resolution and root-cause tracking.
• FIRST_GENERATED_DATE, PART_CONDITION, ZONE_ID, TRANSACTION_ID, DEMAND_ID — lifecycle, warehouse and demand linkage.
• DATE1–DATE6, NUMBER1–NUMBER8, CHAR1–CHAR2 — generic overflow columns for exception-type-specific data.

Standard Who and concurrent Who columns (LAST_UPDATE_DATE, CREATED_BY, REQUEST_ID, PROGRAM_ID and peers) are also present.

Common Use Cases and Queries

Typical usage centers on exception reporting and resolution tracking. A frequent pattern joins the detail table back to the plan and item context:

• Listing all exceptions for a plan by type: SELECT e.exception_detail_id, e.exception_type, e.inventory_item_id, e.quantity FROM msc.msc_exception_details e WHERE e.plan_id = :plan_id AND e.sr_instance_id = :instance_id ORDER BY e.exception_type;
• Identifying unresolved exceptions: filtering on action_taken IS NULL combined with FIRST_GENERATED_DATE to age open issues.
• Exception aggregation: GROUP BY exception_type, organization_id to summarize exception counts and quantities per organization or item.
• Audit and provenance: joining REQUEST_ID, PROGRAM_ID and PROGRAM_UPDATE_DATE to trace which concurrent program generated the exception.
• Warehouse-specific exceptions: filtering on ZONE_ID for zone-level conditions.

Because EXCEPTION_TYPE drives semantics, the generic DATE*/NUMBER*/CHAR* columns must be interpreted in conjunction with the type value; reports should document the mapping appropriate to each exception category.

Related Objects

The documented foreign keys and supporting structures connect this table to the following principal objects:

• MSC.MSC_ITEM_EXCEPTIONS — joined on PLAN_ID; the exception header/master that this detail row elaborates.
• MSC.MSC_SYSTEM_ITEMS — joined on INVENTORY_ITEM_ID to resolve item descriptions and attributes.
• MSC.MSC_DEPARTMENT_RESOURCES — joined on PLAN_ID for departmental resource context.
• BOM.BOM_DEPARTMENTS — joined on DEPARTMENT_ID to resolve department or line descriptions.
• WMS.WMS_ZONES_B — joined on ZONE_ID for warehouse zone attributes.
• MSC.MSC_EXCEPTION_DETAILS_U1 / _N1 / _N2 — the unique and non-unique indexes that drive plan-, item- and exception-type-based access paths.

These relationships make MSC_EXCEPTION_DETAILS the practical entry point for diagnostic and resolution reporting across APS and Supply Chain Hub exception processing.