The stock history doesn't take into account internal moves. For example,
in the following situation:
- Receive 1000 products to Internal Warehouse 1
- Move these 1000 products to Internal Warehouse 2
The 1000 products are still recorded on the Internal Warehouse 1.
opw-672277
When the product price is divided per product unit, inconsistencies
may arise between the real stock valuation and the stock valuation
account. This is likely to happen when a product is bought in a UoM
different from the standard UoM of the product.
A numerical example is the following: a box of 13 is bought for 15.00.
An amount of 15.00 is recorded when the products enter the stock. If the
product leave the stock one at a time, 13 entries of 1.15 are recorded
(15.00/13 = 1.153846... ≈ 1.15), which is then equal to
13 * 1.15 = 14.95. In this case, All the products have left the stock
(stock valuation is zero), but 5 cents remain on the account.
This is of course even worse the higher the ratio is. For example, a
box of 4.00 split into 1000 units sold piece by piece will never be
recorded when a product leaves the stock.
The fix is to record the rounding difference on a specific quant. In the
previous example, instead of adding 1.153846... on the unit cost of the
13 units, we do the following:
- 12 units to which we add 1.15 on unit cost
- 1 unit to which we add 1.20 on unit cost
opw-675222
The revision 29bd622521
aimed to improve the performance by changing
the view index, to use a BIGINT instead of a text.
It was assumed that the index used
(`stock_move.id`) could not appear
multiple times with the JOINs and
group bys defined.
This was in fact possible, if a
stock move is associated to
several quants with different costs,
because of the JOIN on the many2many table
`stock_quant_move_rel`
linking quants to moves,
and the GROUP BY
`price_unit_on_quant`
that caused the different moves/quants association
not to be merged within one unique line
if the costs on the quants are different.
Instead of the group by, we now aggregate the quants
costs, using the weighted average, so the index
used can be unique, as expected.
From now, the inventory value per line in
this report view can therefore
be different than what can be found on the quants,
but this report view is based on the stock moves
rather than the stock quants, and this is therefore accepted.
In other words, the inventory value is computed for the stock move
rather than for the stock quant.
opw-658903
When performing a stock valuation at date,
the stock valuation total wasn't equal
to the sum of each line of the report.
This is because the domain forcing the
date wasn't passed to the `search` call
when no group by was applied.
Indeed, when calling
`read_group` with a group by, the lines in the results
contains the domain used for each line, but when
there is no group by applied, this is not the case, the domain
is not included in the line dict returned by `read_group`.
In such a case, therefore, we must use the domain that was passed to
the `read_group` call.
opw-667761
The system showed different Description for product in invoice when you generate invoices based on delivery
orders compared with based on the sales order lines. But the invoice is in the two cases attached with the SO.
Then the description of the product must be the description linked to the SO line.
opw:660723
When cancelling a `stock.move` with as invoice status
`To be invoiced`, the invoice status was left that way.
Therefore, the `stock.picking` to which this `stock.move`
belonged remained in the "Deliveries to invoice" list,
even if all other moves of the picking were invoiced,
and this one cancelled.
Setting the invoice status to "Not applicable" on
the `stock.move` cancellation solves this issue
as the `stock.picking` will no longer be considered
as to be invoiced if all its moves are
invoiced or `not applicable`
opw-660729
The function "_store_average_cost_price" doesn't have to update
the average cost price of a product if qty of the product in the move
is equal to zero.
opw:659329
The list_price field doesn't take the extra price of variations
into account. Actually, it's not even a field of product.product.
The lst_price, however, is defined on both product.template and
product.product and does account for the extra price of variations.
OPW 659330
Using BIGINT id instead of Text
- This doesn't change the behavior, just the variable type,
while being much more efficient.
Using `UNION ALL` instead of simple `UNION`
- This doesn't change the behavior either,
as the ids of each sub select cannot collide
Closes#9197
opw-650598
The function "open_table" is not called when triggering the action
window "Current Inventory Valuation". Then the 'history_date' is not
set in the context.
opw:649168
Odoo Translation Bot
Nicolas Martinelli
Denis Ledoux
Goffin Simon
David Monjoie
qdp-odoo
Nicolas Seinlet