In "stock.move" model the fields location_id and location_dest_id
are required. But when disabling "Manage Multiple Locations and Warehouses"
in Technical Settings, these fields became hidden in stock.move.form and
then it was impossible to add an new product to consume in mrp.production.form.
In 8.0, to be in group_stock_user implies to be in stock.group_locations.
Introduced by e58b16a
opw:660032
This commit improves performances of the scheduler when the database
is big (lots of products with lots of fields). This avoids prefetching
all the fields for every 1000 products while we only use 2 of them.
If the method do_enter_transfer_details is called form the new API, the context
is a frozendict and can not be updated and the previous code would crash.
Copying it before updating.
Closes#9872
When routes are defined for the variants of a product, the total number
of routes is not computed correctly. The total number of routes for a
product template should be the sum of the routes of its variants.
opw-657471
Add a related field to the partner_id of the picking. Note that
partner_id on stock.move is different from partner_id on stock.picking
in case of dropshipping, therefore we need to show both fields.
opw-656298
Locations were search & read each time you changed
the quantity of a product in a picking.
Once the locations loaded the firs time, this is unlikely
the locations will change during the operation. It shoudln't,
at least.
Therefore, for performances, we avoid to load the locations
each time the picking is reloaded.
opw-648529
Fixes#8344
When the user validates a picking without going through the manual
reservation process, Odoo tries to assign the picking then performs the
transfer. However, if the picking could not be assigned, no pack
operation is created and the picking will simply be set to done.
The fix raises an error if the picking could not be assigned completely.
Another solution is to use a force_assign instead of action_assign, but
that could lead to the creation of negative stock moves without warning
the user. We therefore prefer to stay on the safe side and force the
user to manually handle the reservation.
Note: the original issue was that the Owner of the picking was not
copied on the quant when validating right away. The reason was that no
pack operation was created.
opw-654423
`stock.move` & `stock.product` have multi-company rules.
There is therefore no reason why `stock.quant` could not have one.
Besides, this could lead to access rights issues,
when a user went to the `Quants` list,
in Warehouse > Traceability > Quants,
while there were quants for products in a company different
than the user company.
opw-653188
`partner_id` is not the `supplier` of the stock move,
this is the destination address:
`Optional address where goods are to be delivered,
specifically used for allotment`.
The supplier would be a related to the `partner_id`
of the `picking_id`.
Nevertheless, displaying the `supplier` in the `stock.move` list
is not useful. You should use the pickign list for that matter.
opw-656985
Closes#9219
When all the products need to be reserved before doing the picking,
the pack operations were not shown, but still created.
This is not necessary (and did not work as it tried to reserve according to
existing pack operations), as you will need to reserve again when there is
sufficient stock to put the picking in available state and then
the pack operations will be generated and made visible.
`Recheck availability` must ignore
the done or cancelled moves.
Otherwise, it raises the warning telling you cannot
unreserve a done move.
https://github.com/odoo/odoo/blob/856b31719c69e7f022143ce39df7c6c43688beb9/addons/stock/stock.py#L1899
To reproduce the issue:
- Create a delivery order,
with 10 stockable product A
& 10 stockable product B,
mark as todo.
- Create a receipt,
with 5 stockable product A,
mark as todo & transfer.
- Cancel the move of stockable product B from the delivery order,
in Traceability -> Stock Moves.
- Come back to the delivery order, `check availability`,
then, `recheck availability`
Closes#9550
Martin Trigaux