[FR] Configurable "in stock/available" behavior per stock item status/installed in stock item

[turist79]

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

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

Problem statement

1.1 Stock items are deemed available/not available based on the fixed set of statuses and fixed relation betveen status and availability. It is described here https://docs.inventree.org/en/latest/stock/status/ . Availability means generally if the item is usable in it`s current state for production, sale etc. Currently the "damaged" status with the description "Stock item is not functional in its present state" is considered as available. I can imagine that it could be so in some scenarios but find it somewaht confusing.
1.2 Stock item in "not available" status (for example, Quarantined) counts both as not being available and not being on stock which is incorrect. See screenshots

See solution section 1

2.1 Stock item installed into other stock item (which in turn is in stock) is considered to be not in stock. Furthermore, the "Installed in Stock Item 1" information is generally lacking most of usefull information
2.2 When Part stock table data is being saved, for the installed item its original (before the installation, INFR) location is being shown in the location column, while column Installed in shows the id of the stock item it is installed in.

See screenshots.

Suggested solution

1.1 provide the interface to customize availability on per-status base (with default setup being equivalent to current layout) where Yes/No are toggles.
1.2 item is still on stock but is unavailable for whatever reason, it should be included in "in stock" condition and in other places where stock quantity is counted and not availability

2.1 provide the configuration option to treat installed items as being in stock while the item containing them is in stock. Expand the location info for such items to something like "I/O @ installed in ThinkSystem SR630 V3 (J901ZERA)" where I/O is location of the item ThinkSystem SR630 V3 with serial number J901ZERA.
2.2 downloaded report should indicate location for such stok item to be the location of the recepient stock item (I/O in this case)

Describe alternatives you've considered

Nothing really, i don`t see how it could be worked around unless plugins are able to correct that behavoir.
Does the current plugin api provide the possibility to alter the presentation of table columns aor adjust how stock items quantities/locations/availability are calculated and presented?

Examples of other systems

No response

Do you want to develop this?

• I want to develop this.

[turist79]

Regarding how the system treats "availability": i have just stumbled upon another realworld use inconvenience - i have "quarantined" part, it is "not available" and the system does not allow to transfer it to another location, but it has to be done to reflect how the part moves from its bin to the diagnostics/repair location.

Part being unavailable (for production orders, for sale etc) should not mean that it is not in stock (it still should be able to move between locations for example, count towards total stock quantity etc). Actually, it makes sense to always show two quantity columns (stock and available) in "Stock Items" overview similar to how it is done in Openboxes https://help.openboxes.com/article/14-quantity-available

**Quantity On Hand** represents the total quantity in inventory at a given location. It encompasses all product including lots or quantities that may be on hold, allocated to requisitions, or committed in some other fashion.

**Quantity Available** represents the uncommitted portion of the inventory. To determine this number, we take the quantity on hand and subtract any product that is on hold, already picked for stock movements/stock transfers, or is recalled. Quantity available is very important, as it will determine whether we have enough uncommitted inventory available for our desired transaction.

Of course there are many ways to do things but having the possibility to have all items which are physically in stock listed in the report/interface is curicial for wms system.

[SchrodingersGat]

Your point regading "status" vs "availability" is a good one. The stock status field grew from its original intent which was just as an agnostic label. I would love a clear path forward to allowing greater flexibility here. Perhaps we could allocate a disticint "this status is available" flag, which is determined against each status type? We have recently extended status flags in general to allow for custom status flags - so this should be accounted for too.

There are a number of other issues you raised here which would need to be tackled separately:

• Enable movement of "unavailable" stock (agreed, this is an issue)
• Display separate "on hand" vs "available" columns in stock table

Would you be willing to look at implementing either of these? I am happy to give you pointers

[turist79]

Your point regading "status" vs "availability" is a good one. The stock status field grew from its original intent which was just as an agnostic label. I would love a clear path forward to allowing greater flexibility here. Perhaps we could allocate a disticint "this status is available" flag, which is determined against each status type? We have recently extended status flags in general to allow for custom status flags - so this should be accounted for too.

Very glad to hear that.

We need to track which items have been shipped (assigned) to the customer and later only after some formalities to "write them off" making them unavailable, so here custom status "written-off" with available=no would come in handy.

There are a number of other issues you raised here which would need to be tackled separately:

• Enable movement of "unavailable" stock (agreed, this is an issue)

I would say this comes from general difference between being "in stock" and being "unavailable".
actually, all statuses should have not one but two attributes - availability and counted as in stock.
And despite it being not a status but ahemm a state, same approach (with configurable count as availabile/in stock ) would make sense for:
being installed in other item (depending on it`s stock/availability);
being assigned to customer;

probablymatrix with "internal stock", "external stock", "installed in item", "assigned to customer" being column "headers" and statuses being row "headers" with yes/no for "avaiability" and the same for "count as in stock" would make very flexible tool.
Add status-to-status transition matrix on top of that and this will provide almost unlimited configuration power.

• Display separate "on hand" vs "available" columns in stock table

Would you be willing to look at implementing either of these? I am happy to give you pointers

Frankly speaking i have zero knowledge in using git and very basic python understanding.
I feel that there is lot of self development potential here but commiting to anything would be too ambicious for me at this point.

I would like to start with plugins - it could be done in more slope learning curve and not touching main app code.
Currently my colleagues are quite sceptic because of limited inventree reporting capabilities - this is something to look into as well.

[matmair]

@turist79 we have an extensive report generation framework, not sure what your colleagues are sceptical about.

@SchrodingersGat Making everything dynamic could blow up the computational expense, this should be well-architected. The custom states are built in a way where the dynamic bits do not touch business logic - this made it possible to keep the computational and logical burden low.

[turist79]

@turist79 we have an extensive report generation framework, not sure what your colleagues are sceptical about.

not intended to sound rude in any way.

i made myself familar with the documentation https://docs.inventree.org/en/latest/report/report/ , framework provides a lot of possibilities but since it is template based it is

• understandably not especially userfriendly in terms of end-user customisation possibilities (user being able to quickly create needed report in some kind of visual report builder
• output to pdf means that those are aimed more for like realworld paper "reports", not the reports which data is used for further reporting/analysis
  There is an option to download data from any individual list to xls, but it is somewhat cumbersome.

Anyway, it is copmletely understandable, that inventree is small purpose-built tool maintained by small group and setting priorities here is vital. Thanks for your efforts by the way :)
Since connecting to PostgreSQL via ODBC works like a charm (one should not forget to expose corresponding port on the db container if running in Docker and creating separate read-only user for the db would be defenitely great idea) it is fast and easy way to provide users with the ability to build the reports to their liking in more familar way (Excel Power Query in my example).

Reporting is off-topic here, so those were just my 2c , probably sombody will face same questions and it will be of some use for them

@SchrodingersGat Making everything dynamic could blow up the computational expense, this should be well-architected. The custom states are built in a way where the dynamic bits do not touch business logic - this made it possible to keep the computational and logical burden low.