[feat] Hierarchical BOM

[buzzy84]

Problem / motivation

OpenMES currently supports single-level BOMs where each BOM line references a material directly.

This is not sufficient for products composed of internally manufactured subassemblies. In these cases, the manufacturing structure must represent relationships such as:

• finished product;
• subassembly;
• child subassembly;
• purchased component or raw material.

Without hierarchical BOMs:

• MRP cannot recursively calculate leaf-material requirements;
• subassemblies cannot be managed as independent manufactured items;
• parent and child work orders cannot be linked consistently;
• genealogy cannot clearly preserve the full assembly hierarchy;
• the exact multi-level product structure used by a released work order cannot be snapshotted.

This is a different requirement from selecting between multiple alternative BOMs. It concerns recursive parent-child BOM structures.

Proposed solution

Extend the BOM model so each BOM item can reference either:

• a material or purchased component; or
• a child product or subassembly with its own BOM and process template.

The implementation should support:

• recursive BOM structures with multiple levels;
• detection and rejection of circular references;
• quantity, unit of measure and scrap percentage at each parent-child relationship;
• optional association of each BOM item with a process step;
• distinction between purchased materials and internally manufactured subassemblies;
• an expandable tree view in the UI;
• REST API endpoints for reading and maintaining the hierarchy;
• backward compatibility with existing single-level BOMs.

Material requirement calculations should recursively explode the hierarchy and correctly accumulate quantities and scrap percentages through all levels.

When a work order is released, OpenMES should snapshot:

• the complete BOM hierarchy;
• the selected product and subassembly revisions;
• quantities and scrap factors;
• the associated process templates.

Actual consumption and genealogy should preserve the relationship between:

• finished product;
• manufactured subassembly;
• consumed material lot or serial component.

Suggested acceptance criteria:

• a product can contain a manufactured subassembly with its own BOM;
• at least three BOM levels can be created and displayed;
• recursive requirement calculations return correct leaf-material quantities;
• circular references are rejected;
• work-order snapshots preserve the complete hierarchy;
• genealogy can be traced through subassembly levels;
• existing single-level BOMs and API clients remain functional.

Affected roles

• Operator
• Supervisor
• Admin

Alternatives considered

Flattening the BOM in the PDM or ERP before sending it to OpenMES was considered.

This approach may support basic material calculation, but it loses important manufacturing information:

• the identity of internally manufactured subassemblies;
• parent-child relationships;
• independent routing and production of subassemblies;
• revision control at each assembly level;
• complete as-planned and as-built genealogy.

Creating separate, unrelated work orders for each subassembly was also considered, but without a structural parent-child link this does not provide reliable planning, revision control or traceability.

Additional context

Example structure:

ASSEMBLY-1000
├── SUBASSEMBLY-1100 × 2
│   ├── PART-1110 × 4
│   └── PART-1120 × 1
└── PART-1200 × 6

Related to issue #104, but different in scope:

• issue [feat] Change order with multi BOM #104 concerns selecting among multiple or alternative BOMs;
• this request concerns recursive, hierarchical parent-child BOMs.

The current MRP implementation explicitly operates on a single-level BOM, so recursive explosion would require an extension of the existing requirement-calculation service.