[FR] Decrementing Non-Tracked Stock When Completing Build Output

[wdueease]

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

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

Problem statement

Hello! For my workflow, I would find it useful to have untracked, allocated, stock decrement as build outputs are completed for a build order. Is there a use case or workflow reason why that's not currently implemented?

I'd like to be able to have "long lived" work orders, I.e., "make 100 in february" or similar, but when I do this, as parts get used when creating outputs tied to the work order, the "in stock" amount of raw materials stays the same, while the "in stock" amount of the widgets (correctly) goes up.

Correctly, the "available" amount of the raw material is accurate since it's allocated in the build orders, but if I sell one of the widgets that came from the build output, those raw materials aren't really "allocated" they're gone.

I'm very happy with how the tracked parts are auto-installed into parts as outputs are completed, and this behaves exactly as I'd like.

Thanks for any assistance! I really tried to search for docs or other issues pertaining to this and couldn't find much, so please forgive me if this isn't the correct venue for this question/FR

Suggested solution

Implement similar behavior for allocated, non-serialized parts as exists for serialized parts

Describe alternatives you've considered

Not using "long lived" build orders but make many smaller ones.

I'm not totally opposed to this, but the existence of arbitrary number of intermediate build outputs attached to a single build order implies that build orders are able to support this behavior

Maybe I'm supposed to use child build orders connected to my "main" one? I'm happy to adjust my workflow if I can achieve the desired result of having "in stock" raw materials track real life as build outputs are completed

Examples of other systems

No response

Do you want to develop this?

• I want to develop this.

[matmair]

I am not sure if a change of the behavior would cause issues but the proposed change sounds logical.

@SchrodingersGat is this something we should make configurable or do we just change the default behavior and mark it as breaking?

[wdueease]

I can see some obvious friction points in the workflow already:

• What happens if a build output is completed but no parts have been allocated? Do we block the output? or decrement the part anyway?
• Selecting which allocated stock item(s) to decrement from might be tricky to track since each item doesn't have a distinct DB entry like the tracked items do.
• If parts are decremented as build outputs go along, what happens when the parent build is moved to "complete?" does it also decrement? Is it user selectable?
• How does the line item allocation/required bar get updated as the outputs are completed? is there some kind of third state of "allocated, consumed"? Maybe this is already handled in the tracked item behavior

Anyways, I'm understanding if this is a complex change, and frankly I'd rather change my workflow than load more work onto your team. :)

I'd also be happy to help develop it, if that's at all helpful!

[SchrodingersGat]

Now that we can perform partial build comsume this could be achieved.

An optional selection field added to the "complete build output" form to "consume untracked stock"

However this would require some consideration of complex situations where stock is allocated from multiple sources, and how we determine "which" stock to consume, in this case?

[matmair]

Maybe the allocation uses a picking engine / solver? That way you could have a flow like this:

1. UI requires base settings
2. Solver runs (there be plugins?? / global / workplace settings) -> outputs proposal for consumption
3. UI presents solve and asks if the pick should be done -> user can accept or change settings (repeat 2)
4. User accepts -> solved solution is executed / consumed / allocated

This would also have the benefit that we get a new class / module that only does solving and can be moved out of stock / part / BOM considerations. And CI testing would be easier / faster. But would be a bit of work.

[SchrodingersGat]

@matmair that seems reasonable to me

[matmair]

@SchrodingersGat how should we milestone this? 2.0 / horizion?