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)
Field virtual_available on product.product is called Forecast Quantity but was
not on product.template.
This is not an issue to modify in stable as the term is already translated and
the translation of the string of the field is not based on the source (meaning
that, without reloading the translations, people will still see the translation
for 'Quantity Available').
Closes#10443
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
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
Alexis de Lattre
Odoo Translation Bot
Josse Colpaert
Nicolas Martinelli
Goffin Simon
Martin Trigaux
bima
Denis Ledoux
Nicolas Piganeau
Alexandre Fayolle
Matthieu Dietrich