search

inventree / InvenTree

Open Source Inventory Management System
https://docs.inventree.org
MIT License
4.32k stars 781 forks source link

[FR] Batch process subassembly builds #4212

Open camiller000 opened 1 year ago

camiller000 commented 1 year ago

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

Problem statement

We have a part with multiple subassemblies which in turn have multiple levels of subassemblies. At this time we do not build any of those subassemblies separate and apart from the main build. We build all parts as we work through the whole build.

In order to allocate stock for all parts within the build, we have to do a build for all of the child builds. Doing a build for each child level is time consuming and requires manually keeping track of the child build creation process to make sure we do build for each subassembly at each level.

Suggested solution

Add a feature that would allow a build to be created for all subassemblies that are part of the BOM for the top level part. This would be similar to the way you can specific the BOM report to include all levels ( (e.g. 0 = all levels).

Describe alternatives you've considered

We could flatten the BOM to have no subassemblies but that would be unruly

Examples of other systems

No response

Do you want to develop this?

matmair commented 1 year ago

I think this option would make sense in core. Especially with the possibility to first prototype a few times and then start mass manufacturing. The changes for this will probably be a bit involved so it might take a bit.

SchrodingersGat commented 1 year ago

@camiller000 a good idea, I think this would save a lot of time. Will require a lot of code both front-end and back-end but happy to support it :)

temmeand commented 1 year ago

Would this also take care of showing how many sub-assemblies could be build from a BOM?

Right now, I have sub-assemblies in a bill of materials. The "Can Build" column shows that I can build 0, meaning build 0 of the parent assembly. This is based of the number of sub-assemblies in stock, not how many sub-assemblies could be built. Currently, if I want to know how many of the parents I can build, I have to go to each sub-assembly, determine how many I can build, then go back to the parent and see if the sub-assembly or a different part limits the total number than can be built.

Some users may not want to know how many sub-assemblies can be built, only have many are built. It may need to be a setting for the entire system or a setting at the BOM level/view.

SchrodingersGat commented 1 year ago

@temmeand I see the point and I run into this with my technical team at work also. The "can build" is a flat calculation of the top level only. Digging any further down would be computationally expensive (prohibitively so). But perhaps there is a way to approach this?

Rincewind34 commented 1 year ago

I'm running into a similar issue. The sub builds are really not ideal right now. Even though the is a button to create the sub build in the correct amount (which might be time consuming but is at least convenient and thought out, especially when there are not many), the pain starts when you have sub-sub-builds - especially ones that require the same part to be built over different sub-builds. It would be truly awesome to have that mechanic built in, that just shows me "You are missing (transitively) 100 self soldered cables for this build". At the moment, this is only possible after submitting all sub-builds and then checking the part screen for the number of missing BOM allocations (and if the part is also used in sub-sub-builds, there is no way to use InvenTree to calculate that - as far as I know).

Just wanna say again, great software!! Everyone in my team is very pleased with it - keep it up!

SchrodingersGat commented 1 year ago

@Rincewind34 for a high level BOM (with potentially multiple sub-levels of builds) this could get expensive (in terms of database hits) to calculate.

What about the following suggestion:

When creating a new Build, there's an option for "automatically generate sub builds", which, if selected, would do the following:

Take the parent BOM, and iterate down through the BOM items, looking for how many are "missing" for the BOM. If they are an "assembly", create a new build order (as a child of the parent build order) and then again drill down into that assembly and so on and so on.

This would all be handled by the background worker process, so the user experience would not be slowed.

Thoughts?

Rincewind34 commented 1 year ago

@SchrodingersGat thanks for getting back to me!! Generally, this would totally solve I think both my problem and the OPs, we don't really need the actual number being visible in some display field.

However, I'm not sure if doing that in background this way is a good idea for multiple reasons. First, you might run into some very hard to catch edge-cases when the user decides to do stuff that is interfering with the background job. Just as an example, what happens when the root assembly is deleted. All these cases will probably need special attention and if you miss one, you might even be able to run into a somewhat unrecoverable database state.

I think adding a command "Create assembly with sub-assemblies" is the wiser choice. It calculates the necessary steps first (maybe show a progress bar) and then presets the user with a dialog of what is going to happen. The user may be allowed to alter the output quantity of sub assemblies and gets a ruff view of how much is in stock, how much is therefore needed to be built. He should also be able to alter a subassembly that's theoretically not needed for completion but would deplete the stock or go under the configured minimum. All that stuff doesn't need to be in the first iteration but I think it would be cool to have that option open.

When the user is done fiddling, the confirm button then kicks off the assembly creations.

SchrodingersGat commented 1 year ago

100% agreed that presenting the user with the actions, and allowing them to tweak it, is a better idea. Perhaps this is all achievable in the "front end" with some more consideration

camiller000 commented 1 year ago

Sorry for long pause. This change as described above would be meet our needs!

walkermc20 commented 1 year ago

Really interested in this as well.