Negative on hand inventories do not exist in real life but it's a great feature.
Your use case is not 100% right. If you have 5 apples in your inventory and sell 10, before having done the delivery, you get:
- forecasted quantities: -5
- on hand quantities: +5
It's of course impossible that, in the future, you get "-5" apple in your inventory. But it's a great information since it tells you that if you do nothing, you will be 5 apples short according to what you promised to your customers.
In real life, if your inventory is correct, you will deliver 5 apples to your customer and keep the others 5 in a backorder.
But if, in real life, you force the system and deliver 10, Odoo lets you do it instead of blocking the delivery order operation. (which is correct because if you really delivered 10 apples, your delivery order must be 10 apples, even if Odoo think there is only 5 on hand)
In that case, the on hand inventory becomes "-5". Even if it's not possible in the real life, it's a good information because it tells you that you made a mistake when recording incoming/ship ping operations.
The most probable reason is that you forgot to record an incoming shipment. When you will record the missing incoming shipment (or do an inventory for this product), the on hand inventory will become positive again.
Not that by doing so, Odoo ensure that: "on hand inventory" is always equal to "incoming - outgoing shipments", like in the real life.
Note that putting 0 instead of "-5" would be erroneous as you break this equation. And, when you will record the missing incoming shipment, your inventory will be completely wrong.
On hand will only be greater than equal to 0 if you have no unprocessed inventory movements (deliveries, incoming shipments). Since people make mistakes, and things get backed up, the system if flexible enough so that things don't grind to a halt just because the receiving desk guy went to lunch before entering in the last case of apples to arrive.
Hi, Ray. I understand what the system does and why it does it, I guess my question was more along the lines of why not just develop it to use the forecasted for all those calculations but keep on-hand accurate and realistic.
You are free to change the way the system works if you have a need that is different - that's the best thing about open source systems. For every 'why not do it this way?' there is a 'why do it that way?'. The editor chooses based on design principles, user feedback, community feedback, competing software, etc. Users then create modules that allow for special use cases.