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
We force the user to select only one picking at a time. The reason is that we
can choose the number of products to return for every picking, so it does not
make sense to group the returns in one picking.
opw-640030
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
Transfers were slowed because of the continuous
computation of pickings remaining quantities.
This revision delay the computation at the end of the transfer,
so the computation is performed only once, and it
therefore leads to a huge performance improvment.
opw-634416
Make sure that appropriate fields are emptied when switching to in between inventory filters.
This prevents incoherent results due to hidden fields which were filled in a previous selection.
opw-634388
Fixes#6512
This reverts commit a1da6c2132.
This revision was a temporary patch to solve function fields
computation issues, solved thanks to the commit b7f1b9c01e
In the case of sets, several stock moves can have
the same procurement.
Therefore, appending procurements in the list `procurement_ids`
without checking if the procurement isn't already in the list
could lead to having several times the same
procurement in that list,
and could therefore lead to the check of the same procurement
over and over, leading to performances issues and the fact you cannot
call `write` on a list having several times the same id.
See models.py 3875
Using a set instead of a list solve this issue
opw-634393
Revert c06a96 "[FIX] stock: force recomputing transfer information on picking"
and unlink packoperations only when move lines are changed (fix opw 620636).
c06a96 introduced a regression as it prevents to plan moves (e.g. assigning lots
through the barcode interface) before the reception.
The previous filters didn't take timezones into account, and
returned stringified naive datetime values in local browser
time. Those would then be interpreted by the server-side as
UTC date, and depending on the current timezone offset vs UTC,
yield partially incorrect results.
By returning directly a datetime.datetime object instead of
a stringified version (see previous commit 76881fb),
we can get the expected result regarless of the timezone.
Fixes#2972Closes#6229
opw-621282
When creating a chained picking, the first move has no sequence, this is because
there is no sequence for stock.picking.internal.
Set the sequence before the chained move so that the sequences are in the right
order. opw 621261
When clicking on the Transfer button on a picking the packoperations should
always be recomputed.
If the pack operations are only computed the first time, the picking could be
modified (e.g. notice wrong quantity) and still display previous operations when
reloard the transfer button. opw 620636
The same holds for the inverse history_ids relationship. When an object is copied,
the many2many fields their links are copied.
When we copy a done move as is done in the return wizard to create the reverse, it copied also
the relationship with the quants. This is problematic as this field indicates the quants that
were transferred by the move and the new move will think it will have returned all the quants
even before it is done.
`product_qty` field is not recomputed at record creation.
Force field recomputation at any change
Removing the trigger on `product.product` should not be a problem as
product uom can't be changed once there are move lines.
opw:629650
When the theoretical_qty of the stock is calculated, we should only consider the location itself, not its children.
That way you can have correct inventory for e.g. iPads that are both in Stock and Stock/Shelf 1
The inventory should work with packs. If a pack is not indicated
in the inventory line, it means we correct the quantity for the product
that is not in a pack.
Also, when the lot is False, it should not behave as normal stock moves.
It should correct for the quantity that has no lot.
We try to reconcile the negative quants in the pack also.
Only when the picking is partially available, the system will only show the amount of products available.
That way, when working with paper, the warehouse operator will only get what is available. This is the case
where we did not launch the bar code interface or the transfer wizard.
When changing e.g. from 3-step to 2-step, we would like to deactivate a location,
but maybe the user still wants to use that location e.g. in a rule on the product, so do a check
if it is not used in some route not related to the warehouse.
In order to do that, we change the theoretical quantity into a functional stored field.
Therefore the on_change changes, but the old still work.
The UoM of the inventory line is also taken into account
[IMP] Manual selection, no theoretical qty compute on import, comments
If the date_done field of the model stock.picking is already filled in
it means the user do wanted to have this date of reception date
instead of the moment when the user clicked the receive button.
opw-627219
It makes no sense to allow inventories in supplier locations as it won't anyway
reduce the Inventory if we want to downsize the inventory. This makes
the Inventory act weird.
Ex:
1. Initial situation: 20 units of stock A at supplier's location
2. Makes an inventory stating there is in fact 0 qty of product A at that
location (in the hope to remove some quants).
3. Still 20 units in Suppliers location + 20 units in Inventory loss...
Managing specific suppliers destination is currently not supported.
Same issue with production locations.
Fixes#5052
The tracking reference and other delivery references are not relevant to
duplicated pickings. Overwrite copy to remove carrier_tracking_ref, volume and
number_of_packages.
Add fallback on stock.picking.in and out to use copy method of stock.picking.
For partial delivery, the duplicated picking is the delivered order and
the existing picking is the backorder of the delivery (why so much hate?).
This means we have to switch the delivery info between the backorder and
the delivered picking.
Combo opw 615593 and 618802
Only admin was able to create product.putaway records. Gives all access
to warehouse manager.
If a putaway strategy was present on a location, a warehouse user was not able
to transfer goods as he had no access to the rule lines (no read to
stock.fixed.putaway.strat). Give read access. opw 619774
Goffin Simon
Alexis de Lattre
Nicolas Martinelli
Leonardo Pistone
Odoo Translation Bot
Martin Trigaux
Olivier Dony
Christophe Simonis
Wolfgang Taferner
Thomas Groutars
Denis Ledoux
Nicolas Lempereur
david.beal@akretion.com
Rucha Dave
rmu-odoo
Yannick Vaucher
Akash Balar
fka-odoo
Josse Colpaert
Nicolas Piganeau
Denis Michiels
David Monjoie
Antoine Huvelle
qdp-odoo
Xavier Morel