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
`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
`Recheck availability` must ignore
the done or cancelled moves.
Otherwise, it raises the warning telling you cannot
unreserve a done move.
856b31719c/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
Set no_recompute to True
in order to speed up barcode picking UI
This is done for the same reason than
7b306fc17a
merged through #6754.
The remaining quantities will be computed in the
`do_transfer` method, thanks to the call
`picking_recompute_remaining_quantities`.
There is therefore no need to recompute
the remaining quantities for each pack operation.
Closes#9142
opw-645883
In a multi-company environment, you might not
have the access to the stock location
`stock.stock_location_stock`,
in such a case, you should not set it as default value.
This is a regression of revision 9bf6f0310e
opw-652387
When delivering partially a picking in which the moves
had an owner (`restrict_partner_id`) set,
the owner were not kept in the backorder moves.
Closes#4693
If you set WH B to be resupplied from WH A, then the scheduler will
generate a procurement with warehouse_id = B and location_id = B.stock.
Running the procurement will find the resupply rule, and this will
create another procurement with warehouse_id = A and location_id =
transit location.
However, without this patch, the resupply route is not part of the
route_ids of warehouse A, and so the 2nd procurement goes in exception
because if cannot find a rule (the search will force a rule linked to a
route which is part of A.route_ids).
Closes#7956
When the user specifies a Date of Transfer ('date_done') and only transfers the
order partially, we must keep the value instead of overwriting with today's
date.
opw-646908
Instead of rounding the availability and reversation
of a delivery order line to the current UOM rounding,
we round to the generic Product of measure precision.
This is to have the real availability, even for a unit
of measure that normally cannot be split.
For instance, for a product for which the default
uom is 'Unit(s)', but for a specific delivery order
you deliver 1 'Dozens' of this product,
if you have 6 Units available, it will now display
that 0.500 'Dozens' is available and reserved, which
is what is actually happening.
Before, it displayed that 1 dozens was available, even
if only 6 units were available, on the 12 needed.
opw-643312
When pack operations generate extra moves, they should
take the same procurement group as those of the picking.
That way, when invoicing, they will be put on the same
invoice when there is a different invoice address on the
sale order.
By default, the argument to pass the record values is `vals`,
not `values`.
Besides, it's not mandatory to provide the argument name
when it's not optional.
opw-646374
It is necessary to round the quantities with the appropriate precision. Indeed,
since onchange_quantity and onchange_uos_quantity trigger each other indirectly,
it is quite easy to fall in an infinite loop if the uom and uos precisions are
different.
Follows commit 6e346f0adb
opw-643651
To be consistant with the results of _get_stock. Otherwise search made on
stock_available may not display results with the same value than the search
criteria.
Fixes#3976