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
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
Incoming shipments are marked red according to creation date which does
not really make much sense.
closes#1061
note: it was already like this in 8.0 with 201f1c323
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