Search Results low_level_code

Overview

BOM.BOM_LOW_LEVEL_CODES is a table in the Oracle Bills of Material (BOM) module, documented in ETRM 12.2.2 with 10 columns and a status of VALID. Its description states that it stores "temporary data for low level item codes." In practical terms, the table supports the low-level code (LLC) rollup process used by Oracle Bills of Material and Oracle Planning. The low-level code of an item represents the deepest level at which that item appears anywhere in the product structure across all bills of material in an organization. Because an item can appear at multiple levels in different assemblies, the LLC must be derived iteratively, and this table holds the intermediate working set generated during that rollup before the final codes are written to the permanent item master or planning tables.

From a Data Vault modeling perspective, the mined relationship data classifies this object as standalone, meaning it is not linked to parent or child tables through enforced foreign keys in the documented schema. A modeling suggestion would therefore be to treat it as a transient staging construct rather than a durable hub, link, or satellite: it holds short-lived rollup state keyed by item and rollup run, and its contents are typically replaced on each regeneration cycle rather than accumulated as historical fact.

Key Information Stored

The primary key BOM_LOW_LEVEL_CODES_PK is composite, spanning ROLLUP_ID, INVENTORY_ITEM_ID, and LOW_LEVEL_CODE. The unique index BOM_LOW_LEVEL_CODES_U1 is defined on the same three columns, so the surrogate PK is effectively the business key here; unlike many EBS tables, there is no separate meaningless sequence identifier. ROLLUP_ID identifies the particular rollup run or process instance, allowing concurrent or successive rollups to be distinguished. INVENTORY_ITEM_ID is the item reference into the inventory item master. LOW_LEVEL_CODE is the computed depth value that gives the table its name.

The remaining documented columns carry derived planning attributes. CUMULATIVE_TOTAL_LEAD_TIME and CUM_MANUFACTURING_LEAD_TIME hold cumulative lead time accumulations computed during the same traversal. PLANNING_MAKE_BUY_CODE records the make-or-buy classification of the item at the point of processing. The standard concurrent-program audit columns are present: REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE, which allow the generating request to be traced through the concurrent manager.

Common Use Cases and Queries

The table is primarily consumed by Oracle's own low-level code rollup and planning programs rather than by end-user reports. Analysts nevertheless query it to verify that a rollup completed and to inspect computed lead times. A typical pattern retrieves the current low-level code for a given item:

• SELECT rollup_id, inventory_item_id, low_level_code, cumulative_total_lead_time FROM bom.bom_low_level_codes WHERE inventory_item_id = :item_id ORDER BY rollup_id DESC;
• Aggregating maximum depth per rollup to validate a planning run's scope: SELECT rollup_id, MAX(low_level_code), COUNT(*) FROM bom.bom_low_level_codes GROUP BY rollup_id;
• Joining to the item master to produce readable output: SELECT m.segment1, l.low_level_code FROM bom.bom_low_level_codes l, inv.mtl_system_items_b m WHERE l.inventory_item_id = m.inventory_item_id;

Because the data is temporary, queries should always be scoped by ROLLUP_ID to avoid mixing results from different runs. Purge or truncation behavior is controlled by the owning concurrent program.

Related Objects

The documented schema exposes no enforced foreign keys, so relationships are logical rather than declarative. The most relevant associated objects are:

• INV.MTL_SYSTEM_ITEMS_B — joined on INVENTORY_ITEM_ID to resolve item numbers and descriptions.
• BOM.BOM_BILL_OF_MATERIALS and BOM.BOM_COMPONENTS — the structures traversed to derive LLC values; joined through assembly and component item references.
• BOM.BOM_STRUCTURES_B — the flattened structure view used during rollup.
• MRP.MRP_SYSTEM_ITEMS — the planning table that ultimately receives low-level codes for MRP and MPS processing.
• FND_CONCURRENT_REQUESTS — joined on REQUEST_ID to identify the concurrent program that populated a given rollup.

These objects together form the lineage through which low-level codes move from temporary working storage into the permanent planning record.