[FR] Part count estimation helpers for stocktake

[NetSpida]

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

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

Problem statement

When taking stock counts, there are several other ways besides counting to take stock. For example, with hardware like screws, taking the weight of a number of stock items and dividing by the individual item weight is a common practice, for SMT reels, measuring spool inner diameter, tape thickness, part spacing and then for each stocktake the remaining tape thickness is also widely used.

Suggested solution

It would be nice to add such part counting helps to the stocktake dialogue, and store the necessary base data (in above examples the individual item weight or the inner spool diameter, tape thickness and part spacing) and the type of partcount estimation helper (weight, smt reel turns, smt tape length, ...), with the stock item

Describe alternatives you've considered

It is possible to always count parts, which is error prone and in some case more time consuming than necessary for the desired degree of accuracy. It is also possible to use external part count estimation helpers such as the tool linked above, but that requires to store the necessary base data and paste it into that tool.

Examples of other systems

reel part count estimator

Do you want to develop this?

• [ ] I want to develop this.

[matmair]

I have not seen this in other PLMs but that should be doable. Requires some new APIs, models and a few things in the frontend but I do not see clear showstoppers. Personally, I am not interested in developing it but we would probably welcome this as a PR. Maybe some of the other devs want to jump in.

[SchrodingersGat]

@NetSpida would you be interested in implementing this as a plugin? It would be useful feature for some users but not everyone has electronics for example.

But a plugin with a user interface for inputting reel dimensions, (for example) would be cool!

[wolflu05]

This may integrate with location types.

[NetSpida]

@NetSpida would you be interested in implementing this as a plugin?

I have not yet gained enough insight into the InvenTree source code to feel able to do this, especially not as a plugin, but I am looking into it.

It would be useful feature for some users but not everyone has electronics for example.

I agree with that, but in most cases, the "by weight" estimator should be universally applicable. It even works for fluids, but depends on the precision of the scale.

But a plugin with a user interface for inputting reel dimensions, (for example) would be cool!

I can see several ways to do that:

1. modify InvenTree to have the basic infrastructure for estimators, maybe even integrate the "by weight" estimator. then add all other estimators as plugins
2. put all of that into a plugin without modifying InvenTree

Which way do you prefer?

This may integrate with location types.

@wolflu05 I assume that this comment is related to storing the data needed for the estimators (for example the individual weight for the "by weight" estimator, spool diameter, spacing and thickness for the reel estimator, ...). Initially I assumed that such data would best be stored with the part, as the weight of a part would likely be always the same. however this assumption already breaks for the "by weight" estimator, if you add a tara/offset for a box/bag/packaging, which may be different by vendor. otoh, I would like to spare re-entering data that is likely constant for a wide range of parts, as I would assume for example that smt tape thickness and part spacing would be identical for for example all 0805 components.

Do you have suggestions where which part of that data should be stored?

• weight with the part
• packaging (weight offset, smt spool data) with the vendorpart
• method used for stocktake (implying level of accuracy) with the stocktake

[github-actions[bot]]

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

[SchrodingersGat]

Not stale. @NetSpida any further interest in this?

[NetSpida]

Yes, still interested. Which way do you prefer?

I can see several ways to do that:

• modify InvenTree to have the basic infrastructure for estimators, maybe even integrate the "by weight" estimator. then add all other estimators as plugins
• put all of that into a plugin without modifying InvenTree

Which way do you prefer?

[SchrodingersGat]

I think that a plugin would be a better approach here, rather than bloating the "core" codebase with this :)

[github-actions[bot]]

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

[NetSpida]

Yes, I am still interested

[github-actions[bot]]

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