Confusing (possible incorrect) handling of template parts and their stock

[bloemp]

If you look at the demo site, you see 1 item out of stock... "Widget Assembly". But clicking the part you see it has 166 parts in stock (this includes the variants).

So which statement is valid: A) Templates have their own stock, variants should not be included B) Templates and all their variants share a common stock count C) Is there another use case why this correct that I'm missing...

Maybe it is directly coupled to the way you are using a template part (which I'm personally still figuring out). You can have:

Template |- Part 1 |- Part 2

Part 1 (as a Template) |- Variant A |- Variant B

Any thoughts on this would be appreciated.

[matmair]

@bloemp minimum stock required are per-part. So only for the part itself.

[bloemp]

@matmair But in that case a template part should not count his variants as its own stock, correct?

[matmair]

I think the current system makes sense, maybe we need to add some docs regarding this. @SchrodingersGat thoughts?

[SchrodingersGat]

Personally I think that the "low stock" information should take "variant stock" into account (which is not how the current implementation works). Changing this would require a number of fixes to the underlying API

[bloemp]

Having some docs that clear up what the implemented idea behind a template is, could help. At the moment I see a few use cases that all kind of work, but are conflicting at the stock level...

Use case 1: A template part (like a screw) and create variants of this part (same size different screw head types). In this case having low stock on all variants would make sense (in my opinion).

Use case 2: A template part (like a fuse) and create variants of this part (same rating, different dimensions). In this case the template part could be is its own part, or it can even be a real template which only exists to easily make new variants. It would make sense to have the template have it's own stock. It seems that this use case is also used in #3338

Would supporting both use cases be an option by adding a "Include variant stock" option to the part?

[simonkuehling]

I like the objective to clear this up - counting variant stock as stock of the template part (as it is done right now) is generally tricky to meet the consistency expectations of a user in my opinion. If at all this would only make actually sense for pure template parts, where it would still be important to mark as variant stock somehow, since a combined stock of different lengths of screws do not have much use as an information regarding stock levels in the warehouse:

• There is no way to tell if that variant stock could actually be used as a substitute or variant replacement for build orders: the decision if variants can be used as stock for a BOM item is only a parameter of BOM line items, not of the part itself.
• Variant stock is of no informational value for sales orders, because sales order line items refer to specific parts only.

Maybe I am missing something - but I cannot find a good example for where the combined stock level including variant parts would be useful information for a part in lists and such. @SchrodingersGat and @matmair, could you give a fitting example here?

This is how I would suggest to change towards:

• Stock always only counts as the direct stock of the part itself, stock level information is then consistent to all other parts (and can be displayed via stock health level badges consistently throughout the interface as well)
• The Part detail view could get an additional separate table in the Stock tab that lists Variant Stock for informative purpose

As a general guide to determine how stock levels are calculated/displayed, we should maybe first clearly describe the intended use of that information in the daily business. My personal favorite here would be to "give the user actionable information of the stock level health of a part" --> do we have enough? do I need to order? too low but already ordered? etc. (which is pretty much how the new stock health badges in the search forms are working)

[matmair]

I think it should be left up to the user to ensure that all template parts can be used interchangeably. In the use case they assign them. I use them in my personal instance to mark parts in different colors and materials. For example: I have different knobs of the make DIN 6336 - all of them are variants of the master DIN part of a given knob size. If I need only a knob of a given size I use the template part. If I need specific colors or strengths I use that variant part. That way I am more flexible in my use.

[simonkuehling]

@matmair ok, I get your point. That use case sounds like a "hobby/personal" one, compared to "production/business" use case where templates mostly serve as a functionality for nested part creation rather than as a way to group variants into a placeholder part of sorts...

With this in mind, I would agree that both are useful to have - but I think that this should indeed be a configuration option then. In order to work out a clear way of handling stock level display in the UI, I would assume that the user needs to choose one or another, though:

Config option TEMPLATE_INCLUDE_VARIANT_STOCK true) Template parts are templates only (no direct stock), stock is aggregated from all variants. false) Template parts can be parts too, direct stock only - never including variants.

That would present nice solutions for consistent stock display throughout the UI - otherwise, this is getting really hard to improve I guess

[matmair]

@simonkuehling it actually comes from the supply chain woes of the last years in my case, it is very much business oriented. Using variants for nested parts sounds like a very maintenance-intensive process.

A setting sounds good. The tag should be located in the STOCK namespace IMO. STOCK_INCLUDE_VARIANTS of similar.

[simonkuehling]

@matmair I see… don‘t even get me started on supply chain nightmares, totally understand to desire any solution to avoid yet another new assembly revision again…

In my use case I have variants of machine assemblies that are used like a configurator - a core setup that has variants which have other modules added for example. This falls apart quickly if you try to have more than one configurable option (like a color and an optional additional module for example) - so that‘s not a super clean use case in itself as well to be honest…

Let‘s assume we introduce a STOCK_INCLUDE_VARIANTS config setting. Disabling the setting is pretty straight forward for the implementation, that‘s easy.

But how would the logic look like for the enabled setting - as @bloemp mentioned, the minimum stock count values of template parts and their variants interfere with another in the current implementation.

[github-actions[bot]]

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