[FR] BOM support for cut-to-length parts (profiles, cables, tubing)

[TehDmitry]

Please verify that this feature request has NOT been suggested before.

• [x] I checked and didn't find a similar feature request

Problem statement

I am trying to use InvenTree for production, and I have a case where a structural profile (e.g. extrusion 20×20) is cut to different lengths.

I would like to create a single Part, e.g. “Profile 20×20”, and then use it in a BOM where I specify the required cut lengths.

Currently, the BOM only has a single Quantity field. This works well for items that are counted in pieces, but not for items that are consumed in cut lengths.

Example: if I need 10 pieces of 250 mm, I don’t want to enter 10 separate BOM lines with “Profile 20×20” — that clutters the BOM. If I only enter the total length (2.5 m) as Quantity, then the purchasing/production step will think I need a single 2.5 m piece, not 10 × 0.25 m pieces.

How do other users handle this situation today (cut-to-length parts like profiles, cables, tubing, etc.)?

Have there already been any discussions or Pull Requests related to this feature?

Suggested solution

Introduce two new optional fields on BOM items: Piece count and Piece size.

Piece count: number of pieces required. Piece size: size/length/volume/mass of a single piece (depending on the unit of the Part).

The Quantity field would then be automatically calculated as Quantity = Piece count × Piece size

This approach preserves compatibility with existing BOM items that are used as whole units (where Piece size = 1), while allowing proper handling of cut-to-length or measured materials.

Describe alternatives you've considered

Google sheets =(

Examples of other systems

No response

Do you want to develop this?

• [x] I want to develop this.

[SchrodingersGat]

@TehDmitry thanks for raising the issue. There are always going to be limitations with regard to representing the "real world" manufacturing processes. Keep in mind that InvenTree keeps track of the required parts via the Bill of Materials - but not the manufacturing processes themselves.

If we were to add these two extra fields, there would be users who would then be looking for tracking of irregular size multiples, or some other edge case, which might require even more fields to represent.

With this in mind, I would suggest that it should be sufficient to either:

• Have a single quantity entry (which is the total quantity required to build) and then use the "notes" field for the BOM entry to indicate that the "total quantity" must be broken down into smaller sections
• Add a single entry for each shorter length (yes, a bit more tedious)

Rather than expanding the complexity of the BOM support (which then makes it harder to maintain and also for people to use in practice), I'd suggest trying to represent the data with the functionality already available. Typically the "manufacturing notes" / "build notes" would be stored elsewhere anyway

[TehDmitry]

The feature request was not about managing the manufacturing process of cutting structural profiles, but about keeping track of the required parts for purchasing. Profiles are usually supplied by local vendors in the requested lengths.

The additional complexity in the BOM could be hidden from most users. For example, an extra button in the BOM form could reveal two extra fields (or just one field for “piece count”).

IMO, the “single entry for each shorter length” approach would actually increase workflow complexity. Even a small design change would require copy-pasting multiple parts and updating IDs in the CAD assembly.

However the Notes in each BOM line can handle chunk data. Even in JSON

I appreciate the time you saved me from spending on development

[TehDmitry]

Throughout the day I tried to find a solution using the existing functionality, but I couldn’t.

With #10268 I was able to import a BOM with chunks, for example:

Quantity: 0.4  
Note: [{"length": 100.0, "count": 2}, {"length": 200.0, "count": 1}]

However, the Note field becomes unusable in the next steps — Manufacturing and Purchasing. I couldn’t find any place where BOM Notes are visible or aggregated for all required parts.

With the “BOM Note” approach, in order to buy a profile I would have to:

1. Find all active BOs with “chunk” Parts.
2. Open each BOM.
3. Multiply each chunk in each BOM by the BO quantity.
4. Group the data manually by IPN–length–count.

Only after that I could place an order. This makes me a bit sad =\

[TehDmitry]

Alternatively, using the existing functionality (for data availability), I can split a single grouped row like this:

IPN, Quantity: 0.4, Note: [{"length": 100.0, "count": 2}, {"length": 200.0, "count": 1}]

Split into 3 BOM lines:

IPN, Quantity: 0.1  
IPN, Quantity: 0.1  
IPN, Quantity: 0.2

This way, it becomes possible to aggregate the “chunked” BOM into a single table without changing the core BOM logic.

For example, an additional table could be displayed:

• In each Build Order, right after the Required Parts list item.
• In the Manufacturing view, right after the Build Orders list item for the selected BO.

Example output: Global table (after 4 pieces in BO):

IPN, Quantity: 0.1, 8 pcs  
IPN, Quantity: 0.2, 4 pcs

BOM table (per item in BOM):

IPN, Quantity: 0.1, 2 pcs  
IPN, Quantity: 0.2, 1 pcs

Would it make sense to create a PR for this? I think I would also need an is_chunk flag in the Part model to enable this aggregation logic only when required.

[matmair]

How do you draw it in CAD? one large chunk and a note to split it or multiple parts in the right length that then get referenced in instructions? I would use the same approach for the BOM

[TehDmitry]

In my CAD design each component corresponds to a real-world part and is assigned a UUID. For example:

{"ERP_UUID": "11111111-e92a-11ee-8d1e-001b21391651"}

This UUID can be placed either in the component description or in the sketch name.

The length is treated as a computed property of the component, with the description ERP_Length.

Using a plugin, I can extract all components with their ERP_UUID and then generate a BOM in different formats depending on the ERP:

Grouped with chunk data in Notes:

"Component","name","Quantity","Note"
"11111111-e92a-11ee-8d1e-001b21391651","V222LX-V20kh20L v2",0.4,"[{""length"": 100.0, ""count"": 2}, {""length"": 200.0, ""count"": 1}]"

or Split into separate rows:

"Component","name","Quantity"
"11111111-e92a-11ee-8d1e-001b21391651","V222LX-V20kh20L v2",0.1
"11111111-e92a-11ee-8d1e-001b21391651","V222LX-V20kh20L v2",0.1
"11111111-e92a-11ee-8d1e-001b21391651","V222LX-V20kh20L v2",0.2

So the representation depends on the target ERP system.

My first PR was about importing existing UUIDs into BOMs by IPN. Right now I’m trying to migrate from Odoo to InvenTree and at the same time make some of these processes more enjoyable.

Maybe there is a more efficient approach, but the current workflow is born from CAD API limitations.

[matmair]

I would not do any fancy chunking for the BOM but try to keep it relatively similar to CAD, especially for hardware.

Odom has by far more broad manufacturing capabilities, there will be loss of functionality.

While I understand the wish to make your specific workflow simpler I do not think the suggestions made here are thought-through and generalized enough for us to take on as a complexity, maintenance and documentation burden for the core system. Maybe this is a target for plugins support.

[TehDmitry]

I’m a bit surprised that this kind of functionality hasn’t come up before — parts with a “length” parameter are common in many areas of manufacturing.

That said, with the ability to add Parts with the same PK in a single BOM, I can implement a plugin which groups BOM requirements and calculates the total quantity for placing real orders with suppliers. This approach adds a few extra steps, but it’s still easier and less error-prone than manually counting part chunks.

For now, I can’t provide any example of a friendly approach to storing length data while keeping proper DB normalization.

Maybe in the future, if the “chunk lobby” grows, we can come back to this topic and work on more generalized suggestions 🙂

In any case — thanks for building a core system that makes it possible to implement non-standard approaches on top of it

[wolfpackmars2]

Adding an attribute "count" to the BomItem model would probably work here. This would also require updating documentation, unit tests, related views, and stock take calculations.

Count would represent the count of discrete BOM items.

Quantity would remain as is and would represent the amount of each count of BOM item. Quantity would be an SI unit of measure or could be a count of whole items.

Under the proposed implementation...

Count would always represent a count and never a unit of measure.

Count would have a default value of 1.

Count would always be a multiplier of Quantity for calculating stock take.

The migration would apply a value of 1 to each BomItem for the purposes of updating existing instances.

Other considerations:

• Might some users want the option to hide the new count field if they don't need it? In this case, the only change is to the view. The calculations would still use the field, and the field would be populated with the default value of 1.
• This would almost certainly require that SI units are included when entering BomItem quantities. This is mitigated by the fact that at present, stock is tracked in "whole units". If "one unit" of part is "1 pound", then a BOM line item with count 1 of ".5 units" would still effectively be "A half pound of part" in the BOM. This could have implications related to implementing #4922.

[jrobelia]

Here is my third party perspective with the same manufacturing issue: Sounds like you are trying to generate what I've heard referred to as a cut list? I imagine for some types of manufacturing there is a wide variety of cut lengths of specific off the shelf coml (commercial) parts of prefabbed lengths. I can imagine it is important when cutting this material to know how many of given length piece are needed to see how they can be cut from the existing stock material. We haven't found a good built-in way to generate a purchase list in Inventree for these but have found a way to document them in the BOM and then keep track of them.

The idea of Quantity = Piece count × Piece size is a good one and could definitely be useful.

We don't have a high volume of "cut-to-length" parts in our manufacturing process but there are some: tubing, extrusions, wire, etc. and they are fixed for a specific top level assembly. Making a new part for each length is time consuming but it does work.

Whenever we need to make a "cut part":

• We create a new part number and make it an assembly, leaving its default units blank.
• In the "cut part" BOM we add the "coml part" it is cut/made from with the qty being the "cut part's" length.
• The "coml part" is configured with the default unit set to the cut length unit, i.e. ft or mm.
• The "coml part" then has its associated "supplier part" configured with whatever units the commercial part is sold in. These are sometimes different, i.e. we buy tubing in 10ft rolls but spec it in cut lengths as mm.
• The "cut part" can then be added to BOMs with a standard count qty and the total length of underlying material can be tracked.

We use an external python script to recursively traverse an exported BOM to give us total qtys of supplier material in units of length. This isn't a cut list but listing the "cut parts" and sorting by "supplier part" could get you there.

I've seen other software systems (parts&vendors) use a special designation for these types of part items, calling them "made from" parts. Once a part was designated as a "made from" part users could specify the part it is made from and the qty. The above method seeks to duplicate this in a way, however it creates some extra complexity to do so.

TLDR: You want to list the piece count of cut-to-length parts in a BOM without creating a new part for each length. We handle cut to length parts by making a new part number for each length and then adding the base material to it's BOM in the length needed. We can then export the entire top level BOM as .csv and get qtys of base material needed.