Working with variants

[DanielDango]

Hey all,

I was wondering whether it is intentional that variants do not show up in a template parts stock history (stocktake) data graph. I understand, that the data is recorded when performing a stocktake on the template part. However, the stock history tab only shows entries of stock from that exact part. To me, this behavior would seem unexpected as variant stock is included in the stock overview of the template part, and even displayed above the stock history graph.

Other instances where I noted similar unexpected handling would be, that "On order" only includes instances of the part, but not variants. Also, unit conversions do not seem to be taken into account when summing up the stock of variants in the template part.

I suppose when #8671 and #8594 are completed, it would be quite straight forward to include variants in the stock history view as a personal plugin, even if the current behavior is intended.

[SchrodingersGat]

@DanielDango I do not think that the behavior you are seeing is intentional - likely an oversight or mistake in the code. You are welcome to submit a PR to address this :)

[DanielDango]

When I am picking this up in a public PR, I'd like to know, where you see this issue addressed.

In my opinion, the API endpoint part-stocktake-list should include variants already, as part-stocktake-create does so too. I have not taken a detailed look at the different charts provided by Mantine yet. I suppose a stacked chart type will be usable.
The main conflict I am seeing is the existence of variant stocktakes for dates without template part stocktakes. If they are included in the result of part-stocktake-list for the template part, the result would be more accurate but requires additional filtering or interpolation when working with the data. I would love to simply exclude them, however I can see this impacting another edge case.
If a stocktake is performed around midnight, I believe it might be possible that the dates of the template part stocktake and (some of) the variant parts stocktake do not match.
For such "problematic" dates, I think instead the last known stocktake of missing template or variant parts should be used to display in the history graph.

Alternatively, if you think that part-stocktake-list excluding variants is intentional, stocktake data for variants can be requested separately.

Lastly and most fundamentally, variants could just be included when recording stocktakes. Currently, variants are excluded as otherwise "stocktake entries will be duplicated". I can see why you would do this. However, I think excluding them is not desirable, as historical connections (X is variant of Y) will not be preserved across stocktakes of template and variant part. Even when summing up variant stocktakes historical values would be displayed as higher or lower than they actually were perceived at that time, when a part X was still considered as a variant of the template part Y or vice versa.

[matmair]

Changing the business logic of stocktakes to such a degree warrants a much more informed and structured discussion. An instance can have a nearly unlimited number of nested parts in variants.
The current mechanism is in production and any change to it is breaking.

[DanielDango]

Am I understanding correctly, that this is only concerning changing the API spec or how stocktakes are performed? So modifying the frontend to include stock history across variants of the template part would be the preferred solution?

[matmair]

your original request and the answers were for frontend changes. Breaking changes to business logic need to be discussed and clearly laid out if you want them merged. Non-breaking changes to the API should be fine generally but we need to see the implementation details to judge that.