# Bill of Material Management

## Overview

Bill of Material Management defines the production recipe for a finished good or subassembly. A `BillOfMaterial` specifies which component items are required, in what quantities and units, under which version or effectivity window, with which expected scrap assumptions, and with which `bomType` explosion behavior. The feature supports multi-level manufacturing by allowing a component line to reference another manufactured item that has its own BOM.

The BOM is manufacturing-owned master data, distinct from product templates and item identity. Product-management may describe the commercial definition of a product, and item-management owns the SKU that transactions reference, but manufacturing owns the recipe used to turn component stock into finished output. Production orders resolve and snapshot a BOM version at release time so future engineering changes do not silently alter in-flight work.

Each `BillOfMaterial` must declare `bomType` as one of `MANUFACTURE`, `PHANTOM`, or `KIT`:

- `MANUFACTURE`: The parent item is produced through the normal manufacturing path. BOM explosion preserves the parent as a make item, and released production orders may create lower-level production demand for manufactured child components according to planning policy.
- `PHANTOM`: The parent item is a logical subassembly used for engineering structure, but manufacturing does not create a separate production order, WIP bucket, or finished-stock receipt for the phantom itself. BOM explosion flattens the phantom's child lines directly into the nearest released parent production order.
- `KIT`: The parent item is an issue or packaging structure, not a shop-floor build recipe. BOM explosion produces component demand and picking or issue requirements only; it does not create routing-based work orders or a standalone manufacturing execution path for the kit parent.

## Business Purpose

- Provide a single manufacturing-owned source of truth for how a finished good or subassembly is built
- Support multi-level production by reusing subassembly BOMs inside higher-level BOMs
- Classify BOMs by explosion behavior so the same structural master data can support make, phantom, and kit scenarios without redesign
- Preserve engineering change control through versions and effectivity windows rather than destructive edits
- Enable material requirement explosion for production-order planning and inventory handoff
- Capture expected scrap or yield assumptions used for planning and variance comparison
- Prevent inactive, circular, or invalid component structures from entering production execution

## Process Flow

```mermaid
flowchart TD
    A[Create BillOfMaterial] --> B[Select finished item and company or site scope]
    B --> C[Set bomType: MANUFACTURE, PHANTOM, or KIT]
    C --> D[Add component lines with quantity, UoM, and scrap factor]
    D --> E{Subassembly component?}
    E -->|Yes| F[Reference manufactured child item BOM]
    E -->|No| G[Use purchased or stocked component]
    F --> H[Validate structure, effectivity, and circular references]
    G --> H
    H --> I{Valid?}
    I -->|No| J[Correct line or version data]
    J --> D
    I -->|Yes| K[Activate BOM version]
    K --> L[Production order or issue flow selects BOM]
    L --> M{bomType?}
    M -->|MANUFACTURE| N[Keep parent make item and snapshot recipe]
    M -->|PHANTOM| O[Flatten child components into nearest parent order]
    M -->|KIT| P[Explode to component issue list without work orders]
```

## Scenario Patterns

- **Standard assembly recipe**: A planner defines the component list and quantities for a finished good that is assembled repeatedly using the same standard recipe
- **Multi-level subassembly reuse**: A manufactured subassembly is defined once and referenced by several parent BOMs so planning can explode common lower-level demand consistently
- **Phantom subassembly flattening**: A logical intermediate assembly is maintained for engineering readability, but its children are exploded directly into the parent production order without generating a separate shop-floor order
- **Kit structure definition**: A bundled item keeps a BOM-owned component list for issue or packaging purposes while explicitly bypassing routing-based manufacturing execution
- **Engineering revision cutover**: A new BOM version becomes effective on a future date while the previous version remains valid for already released production orders
- **Site-specific recipe difference**: The same finished item has different default component mix or yield assumptions at two sites due to local equipment or supplier differences
- **Scrap-aware planning**: A BOM line includes expected process loss so planned component requirements better match real production behavior
- **Change freeze at release**: A production order snapshots the active BOM at release time so later BOM edits do not mutate in-flight manufacturing instructions

The `bomType` classification is part of the released BOM snapshot. A released order must preserve not only the selected component structure, but also the explosion semantics that were in force when the order was released. Later edits to convert a BOM from `PHANTOM` to `MANUFACTURE`, or from `KIT` to `MANUFACTURE`, must not retroactively rewire previously released orders.

## Test Cases

- Creating a BOM for an ACTIVE finished item with at least one ACTIVE component line should succeed
- A BOM must require `bomType` to be one of `MANUFACTURE`, `PHANTOM`, or `KIT`
- A BOM line must require a positive component quantity and a unit of measure compatible with the component item definition
- A BOM must reject direct or indirect circular references between parent and child manufactured items
- Overlapping active BOM effectivity windows for the same finished item and scope should be rejected unless one version is explicitly non-default
- Inactive items must not be added as new BOM components
- A BOM can reference both stocked raw materials and manufactured subassemblies
- Releasing a `MANUFACTURE` BOM should preserve the parent item as a producible order output rather than flattening it away
- Releasing a `PHANTOM` BOM should flatten its child requirements into the nearest non-phantom parent order and must not create a separate production-order requirement for the phantom parent
- Selecting a `KIT` BOM should explode component demand without generating routing-based work orders for the kit parent
- Editing a BOM that is already snapshotted by a released production order must not change the snapshotted order recipe
- Editing `bomType` on an active BOM after release must not mutate the type semantics already snapshotted onto open production orders
- Deactivating a BOM version used by open production orders may prevent new selection but must not invalidate existing snapshots
- BOM explosion for a multi-level structure should produce the correct lower-level component requirements
- Only authorized manufacturing users should be able to create, revise, activate, or deactivate BOM versions

## Reference Links

- [Odoo Manufacturing BOM configuration](https://www.odoo.com/documentation/19.0/applications/inventory_and_mrp/manufacturing/basic_setup/bill_configuration.html)
- [Oracle Manufacturing work definitions overview](https://docs.oracle.com/en/cloud/saas/supply-chain-and-manufacturing/25c/faumf/how-you-create-work-definitions.html)
- [Rootstock manufacturing ERP overview](https://www.rootstock.com/manufacturing-erp-software/)