Search Results msc_bom_temp_pk

Overview

MSC_BOM_TEMP is a transient staging table within the MSC schema, owned by the Oracle Advanced Supply Chain Planning (ASCP) module. The table's documented description, "BOM Temp Table," identifies its purpose: it serves as a session-scoped workspace where bill of material (BOM) structures are denormalized and held during planning data collection and plan execution. ASCP's memory-based planner reads engineering and manufacturing BOMs from the transactional tables (BOM_BILL_OF_MATERIALS, BOM_COMPONENTS_B, BOM_STRUCTURES_B) and materializes the flattened, effective-dated component relationships into MSC_BOM_TEMP so that the planning engine can explode dependent demand without repeatedly querying the source EBS tables.

The object is registered as VALID in the ETRM repository and contains 16 documented columns in release 12.2.2. All rows are keyed by SESSION_ID, which scopes the data to an individual planning run, concurrent request, or refresh session. Because the content is regenerated on each collection cycle, the table should be treated as volatile rather than as a permanent record of the BOM. The heuristic Data Vault classification mined from the foreign-key structure is standalone — that is, the metadata does not identify it as a hub, link, or satellite, but rather as an isolated staging object with no enforced referential relationships to other MSC tables. A modeling exercise would therefore treat MSC_BOM_TEMP as a transient staging artifact rather than a candidate for dimensional or Data Vault modeling.

Key Information Stored

The primary key, MSC_BOM_TEMP_PK, is a composite surrogate constructed from SESSION_ID, ASSEMBLY_IDENTIFIER, ASSEMBLY_ITEM_ID, and COMPONENT_ITEM_ID. None of these columns individually identifies a row; together they uniquely locate a component line within a planning session, which confirms that the true grain is "one BOM component per session."

• SESSION_ID — the partitioning column that isolates each planning run; it is both part of the PK and the most selective filter in any query.
• ASSEMBLY_ITEM_ID and COMPONENT_ITEM_ID — the internal item identifiers for the parent and child, joinable to MTL_SYSTEM_ITEMS_B.INVENTORY_ITEM_ID.
• ASSEMBLY_IDENTIFIER and COMPONENT_IDENTIFIER — text identifiers carried alongside the numeric IDs, useful for diagnostics when item master joins fail.
• QUANTITY — the component usage quantity per assembly, the core multiplier in any BOM explosion.
• FIXED_LT and VARIABLE_LT — fixed and variable lead time offsets applied during cumulative lead time calculations.
• PRE_PROCESS_LT — pre-processing lead time, relevant to supplier and manufacturing scheduling.
• EFFECTIVE_DATE and DISABLE_DATE — the validity window governing whether the component is included in a given planning horizon.
• ATP_CHECK and ATP_FLAG — availability-to-promise indicators controlling whether the component is considered for ATP processing.
• WIP_SUPPLY_TYPE — identifies how the component is supplied, for example push or pull, driving supply propagation logic in the plan.
• SMC_FLAG — the supply model consolidation flag used during sourcing rule evaluation.
• SOURCE_ORGANIZATION_ID — the organization from which the component relationship was sourced, essential for multi-org planning.

Common Use Cases and Queries

The predominant use case is troubleshooting plan output. When a planner observes an unexpected component in a plan, querying this table for the relevant session reveals exactly what the planning engine read.

• Session inspection: SELECT assembly_item_id, component_item_id, quantity, effective_date, disable_date FROM msc_bom_temp WHERE session_id = :session_id ORDER BY assembly_item_id;
• Component trace: filter by COMPONENT_ITEM_ID to find every parent assembly that consumes a given item within a session.
• Lead time auditing: compare FIXED_LT plus VARIABLE_LT against values in the source BOM to validate cumulative lead time calculations.
• Date-range validation: confirm that EFFECTIVE_DATE and DISABLE_DATE values bracket the plan horizon correctly.
• Multi-org verification: group by SOURCE_ORGANIZATION_ID to verify that components were collected from the intended organizations.

Because the table is session-scoped, reports should always constrain on SESSION_ID and should never be used as a historical record — data is refreshed with each collection.

Related Objects

The metadata classifies this table as standalone, so no enforced foreign keys exist. Practically, the following objects are the most significant points of contact:

• MTL_SYSTEM_ITEMS_B — joined on ASSEMBLY_ITEM_ID and COMPONENT_ITEM_ID against INVENTORY_ITEM_ID for item attributes.
• BOM_BILL_OF_MATERIALS and BOM_COMPONENTS_B — the transactional source of the staged relationships.
• BOM_STRUCTURES_B — supplies the parent-child structure and effective dates reflected here.
• MSC_SYSTEM_ITEMS — the MSC-side item snapshot used during plan explosion.
• MSC_BOM_COMPONENTS — the persistent planning BOM table that typically supersedes this temporary staging object within the planner.
• MSC_SESSION (or the relevant collection session table) — provides the SESSION_ID context that scopes every row.
• ORG_ORGANIZATION_DEFINITIONS — resolved via SOURCE_ORGANIZATION_ID to translate organization codes.

Developers writing diagnostics should join through the item master and MSC session tables rather than assuming relational integrity, since none is declared on this staging object.