I do not fully understand your question, nor if you have the product_cost_history module activated or not. But I will explain the behaviour:
In both cases the cost price of the product is 17.5€, so if you have 2 units the cost value is 35€ (first example) and when you have just 1 unit, the cost value is the same as the cost price.
You buy a product for 5€ on 15/01/2023 and then you buy the same product for 10€ on 15/04/2023.
If you want to see an inventory based on date 15/01/2023, you will want to see the cost value on that date (5€/u. in this example), not the cost value taking into account the moves it had after that date.
The information they want to see is by location and not by products, that’s why they don’t use product_cost_history in that case.
If you do not activate the product_cost_history module the cost value will be computed using the last cost price of the product. If you want to have the cost at a specific date, you need to activate the product_cost_history module.
Activating the module will afect the behaviour of both product and location views.
That’s right. But validating this behaviour with the module product_cost_history activated I think I found a bug. When you have the following scene:
Product X default as FIFO cost method.
On 01/01/2023, a unit is moved in with unit price: 5
On 01/04/2023 a unit is moved in with unit price: 10
On 18/04/2023 a unit is moved OUT
When consulting the inventory, the result is:
On date 01/01/2023
Quantity: 1
Cost value: 5€
Result: OK
On date 01/04/2023
Quantity: 2
Cost value: 15€
Result: OK
On date 18/04/2023
Quantity: 1
Cost value: 5€
As FIFO says, first units are in, they are also first out. So on 18/04/2023 the cost value should be 10€ because on 18/04/2023 a unit with cost value: 5€ was out.
On the product form, it is always the average cost price that is displayed because there are no other possible value.
What you must check is the cost price on the outgoing move, it should be the correct one.
The cost price on the outgoing move is correct and I agree.
The problem is that on the product form having product_cost_history activated is not showing the average cost price, but showing the cost price from the last unit that was out, in the case I exposed is 5€.
So with this example, on 18/04/2023 having 1 unit at 10€/u, if you move out this unit you will have in the inventory cost price: 10€ and that is not correct.
The cost price stored on the product is also right. I’m referring about the inventory you can consult in the view Product by Location.
Going to my last example:
Product X default as FIFO cost method.
On 01/01/2023, a unit is moved in with unit price: 5
On 01/04/2023 a unit is moved in with unit price: 10
On 18/04/2023 a unit is moved OUT
When consulting the inventory from Product by Location, the result is:
On date 01/01/2023
Quantity: 1
Cost value: 5€
Result: OK
On date 01/04/2023
Quantity: 2
Cost value: 15€
Result: OK
On date 18/04/2023
Quantity: 1
Cost value: 5€
But if you consult the cost price stored on the product on date 19/04/2023 is 10€, that is the correct value.
Additionally, if you consult the cost price history from the model product.product you see:
01/01/2023: 5€ → OK
01/04/2023: 7,5€ → OK
18/04/2023: 5€ → KO
The problem is that when a product is moved out, the cost price history is set as the cost price from the last move, but it should be set as the cost price from the move is still in stock.
In that case, it should be 10€, the same value from the cost price stored on the product.
Despite this fix that we also have applied, it doesn’t solve the problem with the inventory cost value when a method cost from a product is FIFO and the module product_cost_history is activated.
The problem is still the same, so is not correct the following scene:
When a product is moved out, the cost price history is set as the cost price from the last move.
It should be set as the cost price from the move is still in stock.
This strange because the code in modules/product_cost_fifo/move.py set the cost price to the average cost price.
Is the cost re-computation fix the problem?
The cost price is set with average when there are units in stock that there are in different unit prices and I agree that’s right.
But also when a product is set as FIFO, when for example you have:
10 units in at 10€
10 units in at 11€
You will have as a cost price: 20 units at 10,50€
In this moment is used the average computation and it’s okay.
When 10 units are out, the cost price on the product will be 11€ instead of the average because all the units that were in at 10€ are gone.
So when the cost price stored on the product is 11€ on this example, it also has to be 11€ when you consult the inventory. But currently, we found that is set as 10€ because it takes the unit price from the last move was out and that’s what isn’t correct.
Indeed compute stock value using an historized FIFO cost price does not make a lot of sense because it is only valid for before that date (and not after).
I’m wondering if it makes sense to not do perpetual stock accounting with FIFO cost method.
Despite using stock account with FIFO cost method you still would need to consult the stock value for each product and that’s why you need the value of the inventory computed by FIFO cost price.
If you use the stock account and you want to consult the cost price value for each product you will have to create one account for each product created.