[FR] Summarise stock requirement for a BOM and it's children

[LavissaWoW]

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

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

Problem statement

Having complex, deep multi-level BOMs creates somewhat of an issue with production planning. If several of a given BOM's child BOMs use the same part, the toplevel BOM can't paint a picture of how many of itself you can build. As when you start creating Build Orders, and allocate stock, the stock that the top-level BOM thought it could use is eaten by its children.

This also applies to looking at any given BOM with child BOMs. The "Can build" field is based on the completed stock of the child, not how many of the child you can build. So, if BOM A has a line that is BOM B, and you have 0 of BOM B in stock, then BOM A claims you can build zero of BOM A. However, perhaps you actually have the stock to build 10 of BOM B. So you could actually make more than 0 of BOM A.

This is very difficult to discern as the structure works today.

Suggested solution

Listing some ideas:

1. Implement some sort of lookahead to a BOM, to determine if there's stock to build a given child.
2. Add calculations that can be rendered in a report
3. Implement a mechanism to calculate how many of a given part can be built given current stock status, and what builds will be needed to meet this quota. List what parts have insufficient stock for this goal to be met

Describe alternatives you've considered

Manual math

Examples of other systems

No response

Do you want to develop this?

• [X] I want to develop this.

[SchrodingersGat]

This would be very difficult data to present "live", but a report would be a good option, as it can be generated offline and then presented to the user.

[github-actions[bot]]

This issue seems stale. Please react to show this is still important.

[LavissaWoW]

Not stale

[github-actions[bot]]

This issue seems stale. Please react to show this is still important.

[LavissaWoW]

Not stale

[SchrodingersGat]

This sort of "on demand" data would be perfect for a custom report or plugin. I do not think there is much I would want to add to the API / default user interface here.

[cbenhagen]

@SchrodingersGat I see this has come up several times over the past years (https://github.com/inventree/InvenTree/discussions/5517, https://github.com/inventree/InvenTree/discussions/4201, https://github.com/inventree/InvenTree/discussions/8046, https://github.com/inventree/InvenTree/issues/4212#issuecomment-1410734775). May I ask why you would not want this feature in the default UI?

[matmair]

@cbenhagen this is very difficult to get performant and right. It would also need close monitoring for performance problems going forward so the required effort is not worth the pay (0 at the moment)

[cbenhagen]

@matmair thanks for the quick answer! Maybe I should have been more precise. I agree that this could be tricky to get right and / or performant. It was suggested to only provide this information on demand which at least could solve the performance concerns.

If money or time is the main reason for this not being wanted, then the issue could be left open and tagged with #funding and #help_wanted. But the comment by @SchrodingersGat made me wonder if there are other reasons for not wanting this feature in the first place.

That being said, I am well aware that development time is a scarce resource especially in open source projects and that if I want a certain feature or issue solved, I might need to get my hands dirty or consider funding it which I both regularly do. If you or someone else wants to work on this I am happy to discuss sponsoring this as a core feature or a custom plugin.

[matmair]

There is immense complexity in generalising this for all possible use cases due to InvenTree's flexibility in BOMs. You can have variants, multiple suppliers and manufacturers for each part, stacked nearly unlimited times down within an assembly and its subassemblies. The same part can be contained in multiple branches of the BOM so it becomes hard computationally and from a UX perspective (there is about 50 pieces of information per BOM-line if InvenTree is fully utilised).

This would best be handled in a report or custom plugin that focuses on the interests and processes of the specific user group/company. I (and AFAIK @SchrodingersGat) do not think for that reason that this feature has a place in InvenTree core currently.

-- We have had similar(ish) features before and it made the overall user experience bad. Having a very slow on-demand feature still leaves a bad UX, especially if the complexity is hard to communicate to casual users

[jaminy5]

@cbenhagen In reference to your question to me on #8046, I did not make any real headway on implementing this. The complexity grew more quickly than my bandwidth. Also, the capabilities of invenTree are far beyond what I need, and the need to set up cascading build orders to accomplish inventory propagation through a small build (often completed at product order time) was going to be excessive overhead for my application. FWIW, I was able to implement something that does the deep build-tree analysis using Grist. In case it might be useful for someone else, the implementation is here.