For a SO of 300 lines, when confirmed, it takes 195s to process stock
moves for the SO, which is an insane amount of time for any kind of
process in Odoo.
This happens because stock.move is a heavy model with lots of fields,
prefetching all these fields at once can hinder performance when
processing a lot of stock.moves.
To reduce the processing time, the prefetching is disabled in the
specific scenario of processing stock moves and pickings on SO
confirmation.
This patch increases the performance of SO validation (with stock
installed) by ~30%.
Pre-patch: 195s (300 SOL)
Post-patch: 135s (300 SOL)
closesodoo/odoo#28835
This field is a dependency of some computed fields, and has to be searched on
for triggering recomputations. Without the index, the creation of stock moves
becomes slower as the table grows.
closesodoo/odoo#28757
commit c6b0d36622 introduced a wrong
domain. The readonly should be added if the show_operations is false
OR state is done AND is_locked is true.
close#28595
1. Product A - on stock 5 pcs.
2. SO - 7 pcs. of A
3. Generated picking has reserved 5 pcs.
4. Increase stock to 7 pcs. (Update qty on Hand)
5. Run procurement scheduler
6. Picking still has reserved 5 pcs.
The scheduler should take into account the moves partially available.
Fixes#27874
opw-1895622
closesodoo/odoo#28136
Stock moves show a detailed operations icon if the tracking, locations, or
consignment allow to be configured.
However it did so on a per move basis, only displaying it if the considered move
has some of these features.
This fix makes it that the "detailed operations" icon is always displayed if at
least one group of group_tracking_lot, group_stock_multi_locations, or
group_tracking_owner is active, or the move is tracked,
unless the move picking type already does show detailed operations.
opw 1893106closesodoo/odoo#28072
Before this commit:
Reserved column appeared with 0 qty when Delivery Order goes to done Stage
After this commit:
Hide Reserved column when Delivery Order goes to done stage.
This task is related to #1888361Closes: #27223closesodoo/odoo#28409
Usecase to reproduce:
- 6 units in stock
- reserve 3 units on a move
- reserve 3 units on another move
- validate a third move with 1 unit
It raise the error could not reserve more than you have in stock.
It happens because when free reservation stole reservation from
an exisiting move with too much quantity available, it continues the
loop instead of stopping.
This commit stop the loop once we have enough quantity taken.
opw-1895578
closesodoo/odoo#27935
Typically if you use an onchange method to retrieve values on the server
and convert them to write it will also try to write empty values like
[(6, 0, [])] and this will crash as it has also the length of 3 but no
dictionary but a list
closesodoo/odoo#27937
On delivery order, it happens that when it contains more than 40
products and multiple pager. The quantity done are only saved on
the first pager and on the other everythings is reset to 0.
This issue is not deterministic.
The reason is because on the picking view, both stock.move and
stock.move.line are present. When the user write the quantity done
on a stock.move it exists a function inverse that write qty_done on
stock.move.line. However during an onchange, inverse function are not
trigger and every field present in the view is returned to the client.
It means that data after the onchange are inconsistent since the
quantity done write on the move is different than the quantity on the
move line. When the user save the form view, the write could be trigger
in different order. If the write on stock.move is trigger first, it will
write the qty_done with the inverse function but it will be erase by the
write on stock.move.line that is trigger after.
In order to fix it, we set the stock.move.line as readonly when they are
not needed, so they are not send to the server.
closesodoo/odoo#27903
The field lot_name is not initialised in many cases.
Steps to reproduce the bug:
- Set your user in the group called "Display Serial & Lot Number in Delivery Slips"
- Create a new stockable product P with setting tracking "by unique serial number"
- Create 10 serial numbers for P
- Purchase 10 units of P and select the 10 serial numbers created
- Create a SO where I selected 1 unit of P with its serial number and confirm it
- Go to the delivery slip and print the delivery slip
Bug:
The serial number was not printed in the delivery slip.
opw:1900735
closesodoo/odoo#28076
Usecase to reproduce:
- Create a BoM for a product with route Manufacture
- Use replenish wizard in order to fill your stock
It traceback due to an infinite loop.
It happens because when the production order creates the raw
moves, it does not set a product template. However a default_product
template is in the context and is used as default value. So it creates
a raw move with the component as product.product and the production product
as template. Since they are related it will modify the product_tmpl_id
of the product.product. It result by having a component with the
finished product as template and it will use the same stock rules and
bom again and again.
This commit clean the context before running procurement rules.
opw-1890661
The stock refactoring between version 10.0 and 11.0 changes lots of views
in the inventory app. The picking form view lost in the refactoring the
'note' field.
This commit put it back in the view under the 'Additionnal info'. It was
not been removed from the pdf reports
closesodoo/odoo#27658
Accessing one2many items by their index seems to produce issue regarding the order. This commit fix the potential issue in the test by summing the two quant quantity instead of comparing them one by one.
closesodoo/odoo#27627
Usecase to reproduce:
- Archive a stockable product with quantity on hand
- Start an inventory with all products.
-> Archived product is displayed
It happens because the search is an SQL request that is build
and it thus does not benefits from the automatic search on active
objects.
This commit add an active search on quant for inventory lines.
Fixes#27302closesodoo/odoo#27384