How can I find out how much stock is actually at this second in my inventory?

[winzkigermany]

I'm afraid I don't understand the intention behind inventree's handling of stock.

When I need to find out the stock levels of all items at any given time, I need for each item:

unallocated stock
plus
allocated stock
minus
shipped stock

But I suspect that shipped stock is never deducted from the system, and neither are sub-parts that are contents of a BOM of shipped parts. In the end, I would never know how many parts are available, since sold parts are never removed from stock.

Before adding a feature request, I'd like to know: Is there a way to remove shipped parts from the system, so that they (and their BOM parts) are reduced from stock?
Or am I getting this totally wrong?

[SchrodingersGat]

When I need to find out the stock levels of all items at any given time, I need for each item:

https://docs.inventree.org/en/latest/part/stocktake/

But I suspect that shipped stock is never deducted from the system, and neither are sub-parts that are contents of a BOM of shipped parts. In the end, I would never know how many parts are available, since sold parts are never removed from stock.

They are not deleted from the database, but they are also not counted towards "current stock". You can view the current available stock for a given part from the part detail page. This does not take into account any stock items which have been consumed for a build order, or sold against a sales order.

[winzkigermany]

And for items to be consumed by a build order, the build order must be completed, is that correct?
Because many smaller completed outputs of a larger incomplete build order do not consume stock - at least not in my system.

[SchrodingersGat]

Yes, build items are consumed when the order is completed. Although there are ideas to change this:

• [FR] Allocate "untracked stock" to build order #3012
• Deconstruct / Unbuild a completed build #4487
• [FR] Add ability to scrap a build output #1672

[winzkigermany]

TL;DR: The gist here is to account for planning (intended state) and reality (factual state).

Thanks, @SchrodingersGat, this seems to be a requirement coming up from many directions...
I would also add [FR] Ability to reserve stock #4051 to the list.
And if I had to name my FR, I would call it: Mark stock in use when a partial build output is completed or sales order is pending, so it can be deduced from available stock

I'd like to give my thoughts as an inspiration for what could be a consolidated FR, from a user's point of view:
To me it seems, that there is an additional state missing for stock, think of it being "reserved" or more precise: in use.
That's a state where stock is available only for a specific build or sale #4051, and this stock may either be consumed, or given back #1672 and #4487. In case in use stock is finally part of a completed build or a shipped sale, it could transit to a consumed state according to #3012

For build orders, this would mean: Right now, stock which is allocated, may or may not be already consumed, as long as the build order is not completed.
If I do a stocktake while there are incomplete build orders, I can't tell whether allocated stock is consumed or not.
But with a superimposed state in use for stock, one could easily deduce in use stock from available or allocated stock. This is especially useful when you have long running builds (a year) where you complete output every month or so.
or
If you have two build orders in need of the same part, you would be able to decide which build order to pause, de-allocate its remaining stock which is not in use, and allocate it to the new build order - with both build orders staying incomplete, and both maybe having some completed output.

If you want to scrap a build output, the in use stock could just have the state not in use, or have the in use state removed.
And to make sure that you don't re-stock un-recyclable parts, an additional part property gets destroyed when in use could define, whether a part can be re-stocked or not. For example, a frame of a bee-hive can be reused when unbuilding, but not the honeycombs.

For my own use case, the additional state in use would greatly help in managing long-running builds, where you need to know how many of the parts are actually consumed already, instead of being just allocated to a build: As it is now, I need to complete many smaller builds, just to learn how many parts are consumed already. But with many smaller build orders, I lose the planning for several parallel builds that I need to allocate parts for, in effect losing the opportunity to account for lead times of purchase orders.

This could mean for stock state, that there should be parallel states superimposed:
First, the intended state:
allocated (i.e. allocated to a build order or a sales order) and not allocated (default for new stock or returned stock)
and independently the factual state:
in use (i.e. consumed by a completed build or a pending shipment) and not in use (default for new stock or returned stock), and possibly consumed as the final factual state. (in the far future, possibly also "destroyed", "recycled", "b-stock" and so on...)

I see many ways this could enable great features in the future, like allocating stock to two build orders at the same time, consuming it according to the "first come, first serve" principle, without losing the overview of the number of builds that still can be completed. As a result, you don't need to allocate all stock to all build orders, when it would be sufficient to allocate the same stock to all build orders, and replenish stock as the production of both build orders proceeds. At all times, the "can build" field of a part could benefit from deducting the in use stock from allocated or not allocated stock. (hence, the parallel existence of intended state and factual state)

[SchrodingersGat]

@winzkigermany some interesting ideas here - in particular the "consumed" stock status would be a great approach to use for #3012