Commit 4a0b6f6 slightly improves the performances of `action_assign` by
skipping moves which already have pack operations. However, if the move
is not completely assigned, it prevents the possibility to search for
new quants to assign to the given move.
opw-672069
When transfering the pack, the priority to the moves in state "assigned"
or partially_available(=true) must be given.
Used case (steps):
-set warehouse with three steps to delivery
-create one product A with qty on hand 10
-create sale order with first line product A by qty 2 and the second line with product A with qty 10
-confirm sale order
-check availability
-transfer pick by qty 10
-transfer pack by qty 10
The pack couldn't be transered
Now the pack is transfered.
Closes: #10764
opw:668682
Could incorrectly rename the stock.location.path objects, and in case
the route has push_ids but no pull_ids would crash the method entirely.
closes#10747
The system cannot create two inventory adjustements in state 'in Progess'
with the same product, with the same location, same package, same lot and
same owner.
Example:if two adjustments(ADJ1, ADJ2) are created with the same product(P)
and with the same location(L), let's say:
qty_available for P is 10
in ADJ1: Theoritical Quantity=10 and Real Quantity=20 => a quant with +10 is created
in ADJ2: Theoritical Quantity=10 and Real Quantity=30 => a quant with +20 is created
When ADJ1 is validated then qty_available for P is now 20(that 's ok)
When ADJ2 is validated then qty_available for P is now 40(that's wrong because
the Real Quantity is expected which is 30)
This is why this fix is required.
opw:660658
When writing several times on the same record in the same transaction,
the orm raise a Missing error because the rowcount only gives one
difference.
opw:666470
The `stock.picking`.`state` field is set
to track the change of values
(`track_visibility='onchange'`)
It's supposed to write the state changes
within the picking thread.
It does not work properly for function fields,
as the onchange tracking is designed to work
only with direct user changes, direct
`write` operations on the record, while,
here, the state value changes according to the
picking moves changes, for instance.
To solve this, the tracking changes have to be
hooked within the `create` & `write` methods
of the model on which this function depends on.
Therefore, from now, when changes are
performed in the moves, on the fields that
could lead to the picking state change, we
force the tracking of the picking state.
In addition, we had the `mail_notrack` key
in the context when creating back orders,
to avoid displaying the back and forths
in the state
e.g. when transferring 9 units on 10, the
changes were displayed as below:
Draft -> Waiting availability
Waiting Availability -> Ready to Transfer
Ready to Transfer -> Draft
Draft -> Partially available
Partially Available -> Waiting availability
Waiting Availability -> Transferred
opw-666317
Quants should never be changed or deleted by a user.
We make it not possible anymore in the views.
And also in the code we avoid to unlink without
passing a specific key in the context.
(as we still need to be able to delete quants in case of
negative quants reconciliation)
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
`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
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
If 'Product UoS' has a higher precision than 'Product Unit of Measure', the
method onchange_uos_quantity will be called over and over by an infinite loop
if 'product_uos_qty' doesn't have the sufficient number of decimals.
opw-643651
Ship in 2 steps:
The Packing zone location is inactive but it is used by default as destination
location (instead of Output) in the Pick operation.
opw-643734
This revision is related to 279f225cf0.
`_get_pickings` is used as trigger store method
for several computation fields.
The trigger restriction applied in the above commit should
only be applied on the `min_date`, `max_date` and
`priority` fields.
This rev. is related to 279f225cf0.
The `product_qty` computation priority should be
important, as other compute fields depends on it
such as `weight` and `weight_net` from the
delivery module
This is a performance revision.
Some stored functions field were recomputed uselessly.
In mrp, `hour_total` and `cycle_total` were recomputed
at each write on `mrp.production`, while they should be recomputed
only when there is a change on the `workcenter_lines` field,
or when there is a change in the `hour` or `cycle` field
of these `workcenter_lines`.
In stock, `min_date`, `max_date` and `priority` of
`stock.picking` were recomputed each time a new move
was added to the picking,
wether or not the 'expected_date' of this move
was between the `stock.picking` `min_date` and `max_date`,
and the priority not greater.
In stock, `product_qty` of `stock.move` was recomputed
at each write on the `stock.move`, while it should be
recomputed only when there is a change in `product_id`,
`product_uom` or `product_uom_qty`, as the computation
method only depends on these three fields.
In stock_account, the `invoice_state` of `stock.picking`
was recomputed each time a new `stock.move` was associated
to the picking, wether or not the `invoice_state` of the move
was already the same than the `invoice_state` of the picking.
opw-643560
The procurement created from a move has as source document[by priority]:
[1] move.rule_id.name
[2] move.origin
[3] move.picking_id.name
ps: the internal transfer is created with this procurement.
opw:641887
When the uom(Unit) set by default is not in the same category than the uom category of the product,
the uom of the product is set.
When the uom is changed, the theoretical quantity and the real quantity are recomputed.
opw:641027
When a product is scrapped, we set the reservation_id of the scrapped move on
the quant corresponding to the original move (e.g., the move which brought a
manufactured product from production to stock). By doing so, we will subtract
the quantity to scrap from the appropriate quant.
opw-641852
When scrapping received products, the state of the move will be switched back
from 'assigned' to 'waiting' in method 'recalculate_move_state'. These moves
must be taken into account in 'do_prepare_partial', which is called when
clicking on 'Transfer'.
Note that this bug would only appear if:
- reception in 2 steps is set
- the products are received without scrapping in the first step
- on the second step, we first scrap, then transfer. If we transfer,
cancel, scrap and transfer, it works since the pack_operation_ids have been
calculated correctly during the first click on 'Transfer'.
opw-640415
The group_id of a picking is related to the group_id of the first stock.move
related to it. When a stock.move is added to a picking manually, the group_id
is normally not set. This can be an issue in a very specific case:
- In Settings / Sales, tick "Allow setting a different address for delivery and invoicing "
- Create a SO - Invoicing on delivery
- Customer: Agrolait; Delivery address: Thomas Passot
- Add a line: ice cream
- Confirm the SO
- In the DO, add a line , with an expected date higher than the one of the existing move
- Save
- Mark as todo
- Force reservation
- transfer - transfer
- Create invoice
=> See that two invoices are created, one for Agrolait, one for Thomas passot ( the DELIVERY address )
opw-639955
Josse Colpaert
Nicolas Martinelli
Goffin Simon
bima
Denis Ledoux
Nicolas Piganeau
Alexandre Fayolle
Matthieu Dietrich
Jos De Graeve
Leonardo Pistone
Holger Brunn
Christophe Simonis
Loïc BELLIER
Alexis de Lattre