The location_id and warehouse_id fields on product.template are just
dummy field intended to add something in the context that will be used
to compute the data being rendered (eg. for location, the quantity
displayed is the quantity of the product in the searched location).
But the feature was broken at a point, and has been solved in 11.0 with
7c7b099273.
This solution was not implemented in 10.0 up to saas-15 since this is
not acceptable for a stable version.
This changeset is only for 10.0 up to saas-15 to implement the fix
differently.
opw-1945417
closes#31475
Improve performance (*3) on _compute_product_availability
`mapped` makes use of orm prefetch, which is inefficient in this use
case when facing high volume.
closesodoo/odoo#30545
Calling `search` on `product.product` without specifying an order
will sort the products by name.
As the product name is a translatable field,
it requires to make a join on the translation table to sort
the product by their translated name.
This join is costly, and in this case it was completely
irelevant to do it, as the goal was simply to compute
a domain with only a list of product ids, for which
the order simply did not matter.
By forcing the order on the id,
we avoid the sort on the product name,
and therefore the join on the translation.
The performance is therefore improved.
opw-1930010
closesodoo/odoo#31066
- Go to Inventory > Reports > Inventory Valuation
- Select the pivot view
The top row (containing the Total) has an empty 'Inventory Value'.
This is because there is no domain on the line, so it is skipped.
We fall back on the global domain instead.
opw-1933191
closesodoo/odoo#31280
- Activate:
'Track lots or serial numbers'
'Manage several Warehouses, each one composed by several stock locations'
'Advanced routing of products using rules'
- In the main warehouse, activate Pick + Ship
- In Stock Locations, create 'WH/Stock/Shelf 3' and 'WH/Stock/Shelf 4'
(1 and 2 already exist, use the same config)
- Create a new product 'Foo', activate Tracking By Lots
- On Foo, use 4 times the "Update Qty on Hand" (order is important):
Add 1 on Shelf 2, create a lot
Add 1 on Shelf 1, use the same lot
Add 3 on Shelf 4, use the same lot
Add 1 on Shelf 3, use the same lot
- Create a SO, set a partner
- Ensure that YourCompany is used as warehouse
- Add several SO lines (order is important)
a line with 1 product Foo
a second line with 1 product Foo
a third line with 4 products Foo
- Confirm the SO, you now have 2 deliveries, 1 Pick, 1 Out
- Open the Pick, all moves should be available, you should have:
4 operations:
Shelf 2, quantity 1
Shelf 4, quantity 3
Shelf 1, quantity 1
Shelf 3, quantity 1
3 moves:
A, quantity 1
B, quantity 1
C, quantity 4
- On each operation, select the lot created before and set the quantity
to be fully done
- Validate the Pick
The moves end up like this:
- Move A with qty 1: is done and linked with a quant of 1
- Move B with qty 1: is done and linked with no quant
- Move C with qty 4: is done and linked with a quant of 1, a quant of 3,
a quant of 1 (sum is 5)
In the Out picking, the move linked with the source move (B) with no
quant stays in "Waiting another move" even if the source move is done.
This outgoing move will never be available.
In the method `recompute_remaining_qty`, we loop on operations, and
match them wih the moves. However, the operation with the largest
quantity (Shelf 4, quantity 3) is processed before the move with the
highest quantity (C, quantity 4). Therefore, when we later loop on move
C, `qty_assign_cmp` is larger than zero, which sets `need_rereserve` and
ultimately triggers `rereserve_quants` in `do_transfer`.
A first part of the fix is to check for the location of the quants when
matching moves and operations. This fixes the original issue, but
inconsistencies can still arise since a quant which is taken partially.
therefore, we make sure to never take more than the quantity on the
link.
opw-1932624
closesodoo/odoo#30857
Before this commit, the customer is allowed to change picking type after the
stock.picking record is moved from draft.
But it doesn't make the changes in the stock moves and operations as the
procurements are already created for initial demand.
To avoid confusing the user, it can now only be modified in draft state.
Authored by SodexisTeam
opw 1848252
opw-1934814
closesodoo/odoo#30865
- When using perpetual inventory valuation, the accounts used for scrap, manufacturing,
and inventory adjustment operations are set on the corresponding locations .
- In a multicompany environment, you will have a separate chart of accounts for each company.
- Account fields on locations are not property fields.
- Therefore, in order to separate the accounting of manufacturing, scrap, and inventory
adjustment operations, you must use a location for each operation for each company.
- Set up one location for each company for scrap, production, and adjustment
locations, setting the company field on each.
Bug:
- When attempting to create a MO, inventory adjustment, or scrap order while signed
in to the second company, you will receive a permissions error on stock.location.
Fix:
- Now the right location is taken according to the company of the user.
Backport of this commit: c7526407ab
opw:1817339
In the original commit 19116cc878, `action_assign` was called
on all `move_ids`. However, after API conversion, moves are filtered.
Closes#25886
opw-1868834
The to_refund attribute is set to copy=False.
However when splitting a move to create a backorder, a new move is created as
a copy with the remaining work to do.
This attribute is needed so that the backorder refund is consistently applied.
Essentially a backport of commit:
https://github.com/odoo/odoo/commit/c5ffca151160f9d99bec036330def108e4e91e0b
opw 1865324
Before, when we created a picking manually with MTO+buy products,
put a scheduled date in the future and did "mark as todo", the
date on the po was related to now instead of that schedule date.
The scheduled date of the picking was passed to the date_expected
of the move, but not to the date of the move, which was passed to
the date_planned of the created procurement. By passing the
date_expected instead of the date of the stock_move to the
date_planned of the procurement, the po will have dates in function
of the scheduled date of the picking.
Courtesy of chienandalu. Closes#25223
Usecase to reproduce:
- Enable multiple languages and companies
- Set one language on the admin and another on the demo user.
- Create a product and a translation for its name (both languages)
- Create an inventory adjustement in a company A for this product
- Switch on demo user (inventory manager rights but in company B only)
- Create another inventory adjustement for company B
- Add the invenory line with the product and save
The Inventory Line multi-company rule raise an access error
because the system set product_name on the inventory_line that is
a related field. Since it changes the product name with its translation
it will update it on other inventory line that have this product. The
other inventory line is in company A and the user don't have access to
it thus the access error is raise.
This adds readonly on the product_name since it should not be update
with an inventory line.
opw-1855137
As for consumables stock levels are not that important,
it should be ok to scrap a consumable at all times,
even if the stock becomes negative.
Tests were added to check what happens with a consumable/stockable
product if stays positive/goes negative.
Suppose we have a delta between two datetimes:
delta = dt1 - dt0
If delta is negative but less than a day, ``delta.days`` returns -1 (which is
compensated by positive seconds). In order to avoid this surprising effect,
use ``delta.total_seconds()`` to compute the number of days.
When the reception route of a warehouse company is deleted by the user
e.g. My company, Chicago Receipt in 1 step is deleted,
and then changing the given warehouse `Incoming Shipments`
multiple times
e.g. from `one_step` to `two_steps` multiple time,
the reception route is created again and again and again.
This is because the reception route which is created for the
warehouse is not being assigned to the warehouse
as the `reception_route_id` once newly created.
opw-1836544
When the reception route of a warehouse company is deleted by the user
e.g. My company, Chicago Receipt in 1 step is deleted,
and then changing the given warehouse `Incoming Shipments`
multiple times
e.g. from `one_step` to `two_steps` multiple time,
the reception route is created again and again and again.
This is because the reception route which is created for the
warehouse is not being assigned to the warehouse
as the `reception_route_id` once newly created.
_update_routes should work the same way than _create_routes,
it should return new value to write on the warehouse.
based on preliminary by Denis Ledoux
opw-1836544
When hitting the picking button in the valuation report, there was a
"form view could not be loaded" error. This is because we try to
open a picking with a stock move id.
master bug 1817491
Fixes#17226
IT was not possible to differenciate between variants as using the
product.template name in the message.
Same for the location were it was using the last level name (e.g. 'Shelve 42')
instead of the full path
Closes#20174
At stock installation, the warehouse0 has the name of the first company found
(order "sequence, name"), while the comapny_id field is
`_company_default_get('stock.inventory')` (the company of the user installing
the stock module).
In a multi-company environment, it is possible than both results are different
and having name = 'Company A' and company_id = 'Company B'.
Use the name of the default company as default value for the field name.
Note that 'stock.inventory' is not needed in _company_default_get call but
kept to match the default of company_id (in case of override).
Using a default on the field will impact all the future records but should,
hopefully, not be problematic as it is a valid default value.
Closes#19563
Christophe Simonis