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
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
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.