When calculating the stock_value of a product,
the system will take into account all the locations
that have this company as company. (that way if owner_id
is not set, the company_id on the location is the owner (virtual: not set))
The Qty on Hand field takes into account however
the quantities that are in the warehouses.
This could lead to weird situations where the Quantity On Hand is 0
and so the record is not shown, while the stock value is positive.
(e.g. stock in Transit)
In order to use the same logic for both fields, we pass company_owned=True
in the context.
We add the valuation at date wizard by re-using the quantity at date
wizard and adding a context key to separate the both.
The same view/action is used when openning the current or at date
valuation, only the `to_date` context key is changed.
Kind of switches the behavior for inventory and valuation report,
meaning allows the user to see the quantity at date and disallow him to
see the valuation at date.
The new implementation of stock moves the cost of products from quants to
moves. So we have implemented the FIFO and average cost method based on
those moves instead of using quants.
- When average price is choosed, a field average_price is set on the
product.
- The tests have been completed with an example of how fifo work with
negative stock.
As the use of real price method is really rare, because of the rigor
required on traceability for such method, we removed this functionnality.
- The tests purchase/test/fifo_price.yml have been adapted to use the
FIFO costing method instead of real price.
The old report stock history doesn't exist anymore, and is replaced by
the move view that contains all the cost information.
The methods `get_price_unit` have been moved from the stock to
stock_account.
The methods `_set_default_price_moves` and
`set_default_price_unit_from_product` have been removed from stock.
Explaination of FIFO and average:
- In action_done for an out move in average and fifo, the price_unit and
stock_value are updated.
- For FIFO, it will use the qty_remaining on the in moves to check from
which in moves to take the stock values for the out.
- In case of negative stock in FIFO, it puts also qty_remaining on OUTs.
- In the case of average, it will take the cumulated value of the last
move and divide it by the quantity in stock.
This commit is pretty much a 'work in progress':
- Edit 'done' moves when the costing method is FIFO doesn't trigger the
replay the FIFO stack.
- The landed_costs feature doesn't work.
... for 'compute_at_date' field (default 0, 'Current Inventory').
Before the new views, this value was selected by default by the
FieldRadio, but it was a mere coincidence. Indeed, as the field
had no default value, no value was specified in the default_get,
and for no reason, the widget selected 0 as value.
Anyway, as this behavior was wanted, we simply specify a default
value in the action.
The "Inventory at Date" has several issues:
- graph and pivot views are not available despite their existence
- the views are not linked to an action, thus it is impossible to save
it on the dashboard.
opw-703649
In commit 40bd4a2f05, the counter-part account is made selectable and
required when changing the price of a product.
However, the same wizard is reused for the "Compute from BOM" feature,
in module `product_extended`. This forces the user to set an account
even if the product valuation is not "Perpetual (automated)".
In this commit, the field becomes required only if the product valuation
is "Perpetual (automated)".
opw-697866
When modules `product_extended` is installed, click on "Compute from
BOM" on the product view. It opens a wizard with a default new price of
zero, even if the components of the product have a price defined.
This is an oversight of 191994577. When calling `default_get`, the
default values set thanks to context keys `default_*` have already been
replaced.
opw-693053
Previously we had 'Inventory at Date' (debug mode) and 'Inventory Valuation'
Both have been merged into 'Inventory Valuation' that pops up a wizard asking
whether you want the current one or the one from a specific date.
Depending on which one you choose you will get either report from the previous
menus. (stock.quant or stock.history model)
This method is used only in stock_account that is about to be migrated
into the new API. To ease the migration the method is converted into
a multi method, using a decorator.
When the new standard price is computed from the BoM (thanks to module
`product_extended`), the price suggested is still the standard price of
the product.
When the standard price is changed for a product in perpetual valuation,
the account used is the expense account on the product, while it should
be the Counter-Part Account specified in the wizard.
This adapts the commit 935e61bab5 to work with 40bd4a2f05.
opw-681846
In master , some places the string "Lot" is used and at some places
"Serial Numbers" is used , which is very confusing for the user.
Make a common string "Lots / Serial Numbers" everywhere for the uniformity.
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
Since 27a7cab52b, it may happen that the
stock.history view contains duplicated id (mutliple quants with
different lots for a single move).
Regroup serial numbers in order to keep a unique id per row.
opw-669349
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 a product with costing method = standard price and inventory valuation = perpetual (automated),
the button "Set standard price" in General information in "product.template" is shown if the
product template has only one variant. In the other case, the button is displayed in the variant
view form.
opw:668568
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
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
As the standard price on the product template changed towards the product variant,
we should also change the product price history to be by variant.
Also the inventory value calculated in the Stock Valuation report should be by variant.
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
Josse Colpaert