When you have push rules on move having a 'production_id', the
'production_id' is copied on the generated moves. So it generate a
traceback when we check the tracking method of 'product_id' on
produce_move.
This issue is caused because we get multiple produce_move instead of
one.
To fix this issue, we don't copy the production_id anymore on moves
generated by push rules.
In function _get_top_level_packages, when checking that all the products
have the same destination, the destinations must be stocked in a set
instead of a list because with different products it could return a list
with duplicated destinations.
opw:725720
When we validate a SO with an MTO product, then an RFQ and a delivery
picking are created. The status of the delivery picking is in state
'confirmed', but should be 'waiting' as the delivery waits for a
specific delivery input.
The problem is caused by the unreserve method, which is called in the
'procurement_jit' module. This method only checks that a move has
ancestors to determine if the move should be in waiting or in confirmed,
which is not the case for our delivery move because the RFQ has not been
validated yet so there is not ancestors yet.
To fix this issue, we check the 'procure_method' of the move, and if it
is in 'make_to_order' we put it in 'waiting' instead of 'confirmed'.
We also fixed the function recalculate_move_state that could cause the
same problem.
- Create a kit (phantom BOM), composed of 2 different products A and B
- Create a SO, sell a random stockable product, confirm and validate the
picking.
- Edit the SO, add the kit and save.
Two pickings are created, one for product A and one for product B.
Commit 8fe8ca9948 forces the recomputation of the stock moves, in order
to be able to find a newly created picking. This should actually be done
after each picking creation.
opw-725929
When you have multiplle global push rules with the same source location,
a traceback is raised because the '_apply' method of
"stock.location.path" is called with more than one record, and doesn't
handle multiple record.
To fix this, we limit the number of records returned when a global rule
is searched to 1 (as for other 'search' of push rules in this file).
This bug has been introduced during migration in rev: https://github.com/odoo/odoo/commit/cb486d7eb6353a66eea2cb3610141b4f3a778791
opw-725874
It is still possible to have negative and positive quants in the same
location because of returns: if you send something to the customer that
is not there and you return it, you will still be able to reserve the
returned goods to send to another client.
Before, if you would do an inventory adjustment, it would not take into
account these returned quants and their negative counterpart, which made
them difficult to get out of the system.
This fix takes them into account by creating two movements for one
inventory line: move the positive counterpart to the inventory location
before getting back from this location the same quantity.
This way, even if you have 0 as quantity on hand but you have those 2
quants, it will eliminate them. (if you are increasing the stock, part
of the process might have done it automatically already).
Test cases contributed by @jir-odoo
When creating a stock.picking, the related fields picking_type_entire_packs and
picking_type_code were both updated.
This was an issue was required write access on stock.picking.type (warehouse
manager) to create a stock.picking (warehouse user).
The fields were updated as they were present in the view and filled with the
related value. Even if the value was unchanged, it was triggering a write
anyway.
The two fields were in invisible="1" and used only in attrs for other fields.
Making these two fields in readonly does not prevent to use it in the attrs but
avoid to send a value to the server and trigger a useless write.
Fixes#15769
In method `_check_delivery_resupply`, `new_location` is used in a
`write` call. This expects an integer (id).
However, `new_location` is the result of `_get_input_output_locations`,
which returns a recordset.
opw-716141
The total quantity of an inventory only makes sense if the same product is
counted.
This commit avoids useless recompute of the field when a ligne is changed.
The trigger were missing meaning it was recomputed after any change, slowing
down already unefficiant large inventory.
When making an inventory adjustment in multi company,
the default location_id was all the time taken from
'stock.warehouse0' even if the user was not allowed to read
the warehouse. Inspired from _get_default_location in pos_config.py
Backport of 8955d15e9d
opw:706704
Before this patch, it was not possible to manually process a pack (i.e.
checking the "is_done" box), because the field was always reset
*before* saving. It was still possible to process it by hitting
"validate", but it was not possible to put a pack in a pack.
Manually process a pack means hitting the checkbox "is_done" on the pack
operation. This "is_done" field is a boolean computed field with a reverse
function, and this reverse function set the "qty_done" on the pack
operation to 1.0.
The compute field doesn't have any depends declared, so the value was
invalidated after any changes in the form view. The computed method was
used to check the checkbox is the "qty_done" is set to 1.0. It was
probably used to check the checkbox when opening later a picking for
which the pack was already processed.
The issue is that the "qty_done" was never updated, because the inverse
method is only called when saving, and the compute method already reset
the "is_done" field to False, as the "qty_done" was not updated.
To fix this issue, we do not use an inverse method but an onchange.
Indeed, this was the expected behavior: hitting the checkbox should
change the "qty_done".
We already have a test covering this use case, committed in v9 [1]. It
didn't discovered this regression because the test was using directly
the "qty_done" field on the pack operation, not the "is_done" field used
in the view. We change the test to use the "is_done" field and manually
trigger the onchanges.
This is due to a bad new API migration [2].
[1] rev e248420348
[2] rev d8548e0771
The search on qty_available was refactored twice:
- b9853db8 to split the method
- a989680b to remove the eval operator
At b9853db8 the order of evaluation introduced a bug so that the domain
('qty_available', '=' 10.0)
was evaluated
if product[qty_available] = 10.0:
which crashed (`=` instead of `==`).
Before b9853db8, this code did not crash as the operator was converted via
if operator == '=':
operator = '=='
which is no longer executed after the split
a989680b replaced the eval by a dictionnary that replaced the eval error by a
KeyError when searching with `=` operator.
This commit changes several things:
- replace the `operator in ('==', '>=', '<=')` as this was evaluated before the
operator replacement code mentionned above
- remove the replacement code as no longer justified since a989680b
- replace the OPERATOR key `==` to always match given key
- Enable lot tracking on Product A
- UoM of Product A is kg, but Purchase UoM is lb(s)
- Create a PO for 200 lb(s) of Product A, confirm
- Go in the picking: 200.01 lb(s) shuold be received according to the
pack operation, while 200.00 lb(s) are expected in the stock move.
The field `product_qty` on the sotck move contains the quantity in kg,
but already rounded from the value in lb(s). If we convert it back to
lb(s), there might obviously be a rounding error, since we do:
lb(s) -> kg -> lb(s)
To solve this, we recompute the quantity in the UoM of the product
without rounding, as a temporary computational value.
opw-705259
- Enable lot tracking on Product A
- UoM of Product A is kg, but Purchase UoM is lb(s)
- Create a PO for 200 lb(s) of Product A, confirm
- Go in the picking, specify the lots.
- Validate, and error: 'You have a difference between the quantity...'
This is because `lot_quantities` contains the quantities in kg, while
`operation.product_qty` is in lb(s).
opw-705259
The original issue is the following:
- Configure the warehouse in Pick + Ship
- Activate the packs
- Create a SO with a product which is a consumable
- In the picking from stock to out, add the product in a package, and
validate.
- In the picking from out to customer, the previously created package is
not accessible/propagated as it would be with a stockable product.
The core of the issue is that there are no quants reserved for a move
linked to a consumable product. Since the package information is stored
on the quant, the package cannot be propagated correctly.
The fix is therefore to add the quants reservation feature on consumable
products, but only if the move is propagated from another one (i.e. the
move has ancestors).
That solved our issue, but also makes the workflow more logical. Without
the fix, all pickings are "Available" when created, even though one is
linked to another.
opw-702632
There are some problems in the way the picking compute its state
according to its move lives if the delivery strategy is partial.
When a picking was in a partially available state and then you would
force availability, the state would stay in partial availability.
Therefore, we changed the way the state is calculated more like it was done before.
This issue stems from the new API migration.
If you make an inventory adjustement in mode 'select products manually'
and you add a new line with a product having a different unit of mesure
than the default one, but in the same unit of mesure category than the
default one, the unit of mesure on the line doesn't change because both
are in the same category.
This bug is caused by an 'onchange' which is triggered when the
'product_id' or 'product_uom_id' has been changed. And so we cannot
force to change the value to the product one, because we should still be
able to make an inventory in 'kg', if the unit of mesure is in 'g'.
So to fix this bug, we have set the 'onchange' only on the product_id to
set the unit of mesure set on the product when we create a new line or
change the product of a line. We removed the onchange ont the unit of
mesure, because it was only checking that the unit of mesure is in the
category of the product unit of mesure category, but it's always true
has there is a domain set on the field unit on mesure by the onchange
on product_id
When doing pivot table data visualization, the Unit Cost of several
lines are summed up but there has more meaning if they were averaged.
This will probably still not be perfect (such as averaging two line
with different quantities the quantities would not be taken into
accounts) but it is already slightly better.
opw-694068
The onchange code calls the variable 'partner' before assignement,
this error comes from the migration in rev: https://github.com/odoo/odoo/commit/d45996c9
We fix it by calling the right 'self.partner_id' variable
When making an inventory adjustment in multi company,
the default location_id was all the time taken from
'stock.warehouse0' even if the user was not allowed to read
the warehouse. Inspired from _get_default_location in pos_config.py
opw:695616
If you create a delivery order without partner, its destination location
zone will be set to "Partner Locations / Vendors", which is not correct.
This is due to an error in the onchange_picking_type.
This commit fixes the issue by setting the destination location to
"Partner Locations / Customers". This change has not other implications
more than being consistent.
Let’s say you have 10 units of products item1 and item2 in your stock.
If you create a sale order with two order lines: 1 item1 and 1 item2,
it’ll create one picking with two pack operations: 1 item1 and 1 item2.
Validate the picking, everything goes fine.
Now if you go back to the sale order and increase the quantity of the
two order lines, let’s say you sold now 2 item1 and 2 item2, it’ll
create two picking having each one a single pack operation: the first
with a pack operation for 1 unit of item1, the second one with a pack
operation of 1unit for item2.
The expected result would be that a single new picking with the two pack
operations is created.
This bug is due to the fact that there’s a check on sale order line
write that’ll call _action_procurement_create if you indeed increased
the quantity of any line. This method will at some point call
assign_picking on the model stock move. This method will try to find a
non-done picking with the same procurement group as the one we’re
working (the procurement group for our sale order). For the first write
on sale.order.line, it won’t find one because there aren’t, so it’ll
create one. For the second write on sale.order.line (so, for the second
line) it should find the picking created by the first write, but it
won’t and so it’ll create a second picking.
The fact that it didn't find the picking create by the previous line
is due to the fact that we do not update the computed fields
between write on a one2many field since rev 7b8afc2 and that “group_id”
on the model stock.picking is a computed field (a related).
As we prefer to keep the behavior of not recomputing the computed fields
between writes on a one2many (it’s a trade-off for performance reason,
except in edge cases the recomputation is useless), we explicitly
trigger the recomputation before looking for a candidate picking in the
stock.move action_assign, so that the next searchs on picking.group_id
will be succesful.
This commit also introduces a test for this case.
Closes#14718
* [FIX] base: @constrains parameter on `ir.ui.view._check_xml`
The constraint is never checked because the parameters `arch` and `arch_base`
are not stored. Use `arch_db` to make the constraint work.
* [FIX] stock: @constrains parameter on `stock.warehouse.orderpoint._check_product_uom`
The constraint parameter `product_uom` is not stored.
children_quant_ids is a computed field that does a search based on current
record id. However this causes a traceback when creating a record as
there is no id. This commit fixes this issue.
Those fields were stored computed fields before. However store has been
removed while migrating to the new API. We need a search function if we
want to be able to search on those fields and to use domains.
Domains are necessary to take packages from the right source locations.
The computation is done by searching the packages with the
"location/owner/..." domain and by returning a parent-of domain
in order to include all parent packages too.
- complete_name field should show the entire hierarchy of locations.
However currently it stops at first non view location. This commit
fixes the complete_name computation.
- name_get should correctly handle translations. It is now correctly
computed instead of relying on stored value which could be incorrect
depending on langages. Moreover name_get displays short name like
old implementation of complete_name.
This is an oversight during the port of
3de53fa165
in the forward port revision
3a2147d95c
In the revision 3de53fa165,
the code has not only been moved,
but the variable passed to the method `rereserve_quants`
argument `move_ids` changed as well.
This has been missed during the port of the revision.
This leads to the invalid computation of the `done` quantity
in the pickings in some cases were the quants need to be
re-reserved.
opw-690244
Jeremy Kersten