When checking the replenishments, it sometimes creates a new reordering
rule for a product while another already exists.
To reproduce the error:
(Need purchase,sale_management)
1. Create a product P
- Must be storable
- In Purchase tab, add a vendor
2. Create a reordering rule for P
- Trigger: Manual
- Min: 0
- Max: 0
3. Create+Confirm a SO with P
4. Go to Inventory > Operations > Replenishment
5. On P-product's line, click on "Order Once"
6. Confirm the generated RfQ
7. Repeat 3-4
Error: There are now two lines for P-product. A second reordering rule
has been automatically created but the first one does already the job.
OPW-2431780
closesodoo/odoo#65142
X-original-commit: a9d5bd2ebb28a9bf0aa8d4adb0992582e85c54fc
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Modifying product attributes involves discarding product variants via
the method _unlink_or_archive(), which tries to delete variants, and
archive the ones for which the deletion fails. This process is very
slow when most product variants must be archived. Instead, we filter
out the variants that must be archived anyway (like the ones used in
sales or stock), in order to avoid the variants that cannot be deleted.
On a product with ~200 variants, the time goes from more than 15 minutes
(the request times out) to around 5 seconds!
opw-2440417
closesodoo/odoo#65027
X-original-commit: 63b2f85079404eafac918a74c95e27051539c133
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Avoid to filter in a loop and use a read_group instead to group by
product-warehouse outside.
Also remove costly useless code.
Performance gain
----------------
On a large database (120K stock move, 5k product) where
+- 700 manual orderpoints will be create during the open of the
replenishement report:
Before:
16.14 +- 0.16 sec of python. (SQL time is +- 14 sec)
After:
1.33 +- 0.91 sec of python. (SQL time ==)
task-2390516
X-original-commit: 569b45d5cb139825690a90189b7a360f3fa89815
`o.location_id.id == g['location_id']` =>
`Comparing apples and oranges: stock.location(243,) == (219 ...`
replace by the correct code and avoid warning.
task-2390516
X-original-commit: 461a3e737c4ffe048b738dd09f83571602324257
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to assign.
task-2390516
X-original-commit: e89105144a34ee73981db383ac0625dcaf63b27b
3 fields were useless in `stock.move` (only one store):
- `picking_partner_id` not used and we should use `partner_id` instead
- `backorder_id` not used and no sense
- `note` (store), not used and always empty. remove it.
task-2424248
Related fields are by default readonly and they should be when it
is possible. A editable related field will write on the related
model and will cause extra unwanted write of data. These unwanted write
can cause performance issues in some case (see odoo/odoo#63865).
Then remove the `readonly=False` of some related fields
(where it is useless):
- In 'mrp.workorder' (mrp): `working_state` and `production_date`
should be readonly.
- In 'purchase.order' (purchase): `product_id` should be readonly.
- In 'purchase.order.line' (purchase): `state` should be readonly.
- In 'product.supplierinfo' (purchase_requisition):
`purchase_requisition_id` should be readonly.
- In 'purchase.requisition' (purchase_requisition):
`product_id` should be readonly.
- In 'product.template' (stock):
`route_from_categ_ids` should be readonly.
- In 'stock.move.line' (stock):
`is_initial_demand_editable` should be readonly.
- In 'stock.move' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.production.lot' (stock):
`product_uom_id` should be readonly.
- In 'stock.quant' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.rule' (stock):
`route_sequence` should be readonly.
- In 'stock.change.product.qty' (stock):
`product_variant_count` should be readonly.
- In 'stock.return.picking.line' (stock):
`uom_id` should be readonly and also because it
is forced by `_prepare_stock_return_picking_line_vals_from_move`,
it should be related to the product uom not the one on the move.
task-2424248
To improve the scalability of `_free_reservation` avoid use RecordSet
union. Simplify the parameter `ml_to_ignore` of the method into
`ml_ids_to_ignore` which take only OrderedSet of ids instead of
RecordSet.
task-2424248
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to validate.
task-2424248
Use case to reproduce:
- Go to MO form produce at least 2 units of a product with a component
tracked by serial number.
- Edit the producing quantity to 1.0
- Save
- Edit the producing quantity to 2.0
The move lines are removed.
It happens because the lot_ids field is empty and thus the setter remove
the existing stock.move.line. It's empty because the compute try to do
a match on existing id. However the stock.move in the onchange
could have a new virtual id.
fine tuning of commit 8dfee8cb2d60942641b73eaa6489b02aa378c5ac
closesodoo/odoo#64788
X-original-commit: a3ab5c3a73243e6f4d5662ee27765439ba9b5363
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Prevent duplicate SN through python constraint (requires SN to be
attempted to be created) instead of assigning existing one (and
causing a duplication). Steps to reproduce:
- create a SN tracked product + activate "storage locations"
- assign a SN to tracked product
- create a planned receipt for the tracked product and assign same SN
(i.e. same name).
Warning will pop up about repeat SN, but it is still possible to
validate the picking and create a duplicate SN.
Also add an extra `limit=1` to lot search for performance/safety.
Bug was discovered while working on related task: 1924758
closesodoo/odoo#64714
X-original-commit: cd81b7accad63ec433ff66e58f286626cfc1ac65
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When using a tracked product in a MO, the lot/serial number reservation
disappears even if the product is still reserved.
To reproduce the error:
(Need mrp)
1. Create two products P and P_compo
- Both are storable
- P_compo is tracked by lots
2. Update P_compo's quantity
- Set the on hand quantity of lot L to 5
3. Create a MO
- Product: P
- Quantity: 5
- Add a line: (Product: P_compo, To Consume: 5)
4. Confirm
5. Check availability
- The P_compo's reserved quantity has been updated to 5. If you
click on the line's details, you can see that 5 P_compo has been
reserved from lot L
6. Back to the MO, in edit mode, change the done quantity: 3/5
- There are still 5 reserved P_compo
7. Click on the P_compo's line details
ERR: the line we saw on step 5 disappeared. The MO says that 5 P_compo
are reserved, but when checking which lot is reserved, the latter is
no more visible. Moreover, if you click on "Confirm" (so you leave the
"Detailed Operations" pop-up), the "Reserved" field of the line will be
reset.
The lot reservation should stay so the user can complete the "Done"
field.
OPW-2420347
closesodoo/odoo#64684
X-original-commit: 8dfee8cb2d60942641b73eaa6489b02aa378c5ac
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Free reservation is called each time an extra quantity is
used on a move (and for each immediate transfer). It means
that the function is called many times on a database with an
inventoy activity. Also _free_reservation method do a search
on fields that are not indexed, and is slow on large database.
This index is specific to _free_reservation.
On a live database with an important stock, the queries dropped from 265ms
to 1.5ms.
closesodoo/odoo#64327
X-original-commit: 74ea87d0a354b7414afb76d98ed39ecde45a8fb1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In `run_scheduler`, we are running certain functions as super user to
avoid inter company and access rights issues. This commit adds a
`sudo()` call to the `action_assign()` call, in case some objects
related to the retrieved moves are not accessible.
In addition a commit call is moved up to apply after the
`procure_orderpoint_confirm` call (as it was, it was applied after the
`_action_assign` loop, but there is in fact already a commit in that
loop, this lead to a somewhat random behavior where the replenish rules
were sometimes rolled back and sometimes not, depending on whether the
first iteration of the loop errored out or not)
opw-2394706
closesodoo/odoo#64041
X-original-commit: 592ee14d7fe81e7e5afd23f2bbbdac344eae6060
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
revert commit 72c36aaf90 due to commit 47219e96e1
First commit is now useless and on top of that it ignores the putaway
strategies.
opw-2412699
closesodoo/odoo#64200
X-original-commit: a8db48244f069f9f29ee1120862bdf2c03ec26dd
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In the model `stock.quant.package`, the `_compute_complete_name`
and the `name_get` mimics the default one (`_rec_name = "name"`).
Then remove clean it.
task-2373638
In order to have always a picking_type_id on a stock move (and
consistent with his parent model), make it compute store.
Then clean the call of picking_type_id without change the behavior
(/!\ `move.picking_id.picking_type_id != move.picking_type_id` because
of mrp). Fix some test where the location(_dest) was unset in moves.
Also:
- Clean the mess in the create of `stock.picking` about that
and add a onchange to keep location(_dest) consistent with moves.
- The move `description_picking` is set when the `picking_type_id`
change, not only at the create method.
task-2373638
Add index on the `product_id` of `stock.production.lot` for
several reasons:
- Lot of field domains depending of `product_id`
(e.g. `lot_id` of quant, sml, ...)
- Almost every search on this model contains the field `product_id`
- `product_id` is required and the sparsity is generally high
Performance improvements:
For a DB with 6000 lots, `search_read` with product_id is
x2 times faster.
task-2389380
The `date` fields is only used in the `_accumulate_amounts` of
point_of_sale and is set at now or by the `_prepare_picking` of purchase
(maybe will be remove in the futur).
In all case, and for now, the index is not
used (expected by at a custom search) and should be remove.
task-2389380
A index of a 2 values columns is quite useless, and it is a
lost of storage for nothing. Also, in this
case it will be never used (expected in manual search).
task-2389380
The `name` fields of `stock.move` is use differently (sometimes it is
contains info of related product, other time the parent document, ...).
But in all case we never search directly on the name of the move, then
we remove the index related to.
Also remove useless keyword `index=True` for the `backorder_id`
task-2389380
Indexed of boolean values is quite useless and the one of `priority`
(MO/Pickings) can be only used in filter search view (`starred`).
Then remove priority indexes from `stock_move`, `stock_picking` and
`mrp_production`.
task-2389380
The index on `create_date` was never used in standard expect in
the group_by of the search but onlu visible in debug. Then
remove the index related too (implies to remove the custom definition
in stock_move). Remove invisible create_date fields in views.
task-2389380
About this commit 8e7c0e544a8d3d18c57634750ee7ea03052c84b1
We need to manually invalidate the cache (of the quant) if a error
(other than concurrent ones) is raise from the write. Because
we can't know what the `write` has already put in the cache (e.g.
`write_uid`), we need invalidate it.
opw-2371161
X-original-commit: 7d75745267dada371d421ec93d50fb10b0006457
For validate 5K stock move line with SN:
Without index: 200 sec of SQL execution
With index: 15 of SQL execution
opw-2374846
X-original-commit: 21d7afca292f4c213d1fcfb4a31e0b7157eb941c
Make more scalable the `_action_done` by replacing
recordset/union by OrderedSet/add.
Also add `limit=1` in the lot search.
opw-2374846
X-original-commit: ffe9f204474de832514ab6464947c607a4c92282
In the Barcode app, if the user is on a delivery order, adds a product
and then decreases the product's quantity, when validating the order,
the backorder window is displayed.
To reproduce the error:
(Need sale_management,stock_barcode)
1. Go to Sales
2. Create a SO
- Add one Product P
3. Save, Confirm
4. Check the generated delivery reference R
4. Go to Barcode > Operations > Delivery Orders > R
5. Complete the P's quantity
6. Add Product
- Select a Product P_extra
- Set a quantity (e.g., 1)
7. Confirm
8. Edit the P_extra's line
- Decrease the quantity (e.g., 0)
9. Confirm
10. Validate
=> A window is displayed so the user can create a backorder for the
missing P_extra. Since the SO does not contains any P_extra, proposing
to create a backorder does not make sense.
When adding an extra product to the delivery, it creates a stock move
line with the `product_uom_qty` set to 0. Since there isn't any stock
move associated, it also creates a new one. Here is the issue: the
`product_uom_qty` of the stock move is defined thanks to the `qty_done`
of the extra product. Later, when validating the delivery, the server
uses the `product_uom_qty` of the stock move to check if a backorder is
needed. This the reason why, if the user decreased the quantity, the
backorder proposition is displayed: the `qty_done` is less than the
`product_uom_qty`.
OPW-2411461
closesodoo/odoo#63664
X-original-commit: f5c0990c6af2f44f503de1cc50cc5b094e31976a
Signed-off-by: adwid <adwid@users.noreply.github.com>
In the DB with a warehouse with a lot of stock location.
The forecasted widget return a traceback due to a memory error due
to the `_get_domain_locations_new`
(`_get_report_lines`->`read(['qty_available'])`->`_compute_quantities`
->`_compute_quantities_dict`->`_get_domain_locations`)
how returns a extremely long domain (one expression
by location in the context) to compute child location.
But the locations (put in the context) contain already
children locations because of
`('id', 'child_of', warehouse.view_location_id.id)`.
TO SOLVE
Instead of adding location in the context
(for fix 1aa6a323e04232d24175593718637c6dac295eb9),
add the warehouse in the context before
calling the `_get_report_lines` in the `_compute_forecast_information`.
closes#61666closesodoo/odoo#63377
X-original-commit: f8861e6a63fcd85295affdea4b525af753234b14
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
- Install stock
- Create a Storable Product
- Add an Attribute with Variant Creation Mode set to Instantly (i.e. Color)
- On Product form, click on Variant smart button and open a Product Variant
- Click on "Update Quantity"
The Create button to edit Quantity on Hand is not present.
This comes from the Variant smart button (id: product_variant_action) that adds
'create': False in the context to prevent creation of Variant.
But when navigating to Update Quantity page, it is still in the context and hides
the Create button.
opw-2412380
closesodoo/odoo#63272
X-original-commit: 3d671ef824fec9dc8ee7d3666b6e528a3c794226
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Currently, when we update the Quantity from the 'Update quantity'
button on a variant formview the product_id is not set due to
reset of the context for product template.
so in this commit, set the default product_id on update quantity
wizard when open through the product form view and also keep
default behaviour when called from product template.
closesodoo/odoo#63141
Taskid: 2387310
X-original-commit: 49b8f1bfde1792079c0fd9cdb218eab20f344be3
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Set the Delivery in 2 steps in the warehouse
- Create a 'wave' route:
- Sequence: 5
- Apply on Product Categories
- Rules:
- Action: Pull From
- Operation Type: San Francisco: Pick
- Source Location: WH/Stock/Chairs
- Destination Location: WH/Output
- Supply Method: Take From Stock
- Propagation of Procurement Group: Fixed
- Fixed Procurement Group: Chairs
- Create a 'Chairs' product category, apply the wave route
- Create a 'Chair' product:
- Category: Chairs
- Storable
- Make some stock in WH/Stock/Chairs
- Create a SO for 1 Unit of Chair, confirm
=> a picking from WH/Stock/Chairs to WH/Output is created
- Create a SO for 2 Units of Chair, confirm
=> the 2 units are added to the previous picking
However, the 2 stock moves are not merged.
It happens because `date_deadline` prevents the grouping.
opw-2390630
closesodoo/odoo#62983
X-original-commit: c4505b704489db7ef47dd9a201def536a99d03f3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Changing a product type from Consumable to Storable usually gives
unexpected results once some stock movements have been performed
(negative inventory, wrong valuation...).
While it should remain possible to do it (as long as the user knows what
he is doing), it is worth pointing the fact that unexpected results
are... to be expected.
To do so, we raise a non-blocking warning.
X-original-commit: 383b12977062cacc6ff0f553d7012029268be1ec
Issue:
The `_update_available_quantity` will flush the all environment due to
the savepoint (at each call). When we working with the package,
it becomes bottleneck due to the `_compute_package_info`. Indeed,
it computes two compute store field (`location_id` and `company_id`) and
depends of multiple field of related quants `quants_ids.xxx`. It means
that each time we enter/exit in the savepoint to update quants, this
compute will be execute (because of flush + compute_store).
Solution:
Avoid flushing when enter in the savepoint of
`_update_available_quantity` (`flush=False`)
Performance gain:
To validate a Delivery with 1000 move lines with package (source and
dest):
- Without patch: +- 120 sec
- With patch: +- 17 sec
opw-2371161
closesodoo/odoo#62841
X-original-commit: b2d57323caf9f7fe47c4fe9ac26b0e955d9987b9
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When a picking contains a lot (> 10000) of stock move line, the time
to open the picking become a issue (for 50000 sml, +- 6.5 sec) because of the
`_compute_has_packages`. Use a search with a limit=1 to avoid fetching
all `stock.move.line` with `result_package_id`
(for 50000 sml, +- 2.5 sec).
opw-2371161
X-original-commit: e78ca55997dfbf13c0798c1f59408450071e1452
When there are a lot of stock move line related to a stock move
(> 50000), the `_compute_lot_ids` become a time issue (for 50000 sml,
+- 3 sec).
Use a read_group to increase the performance (for 50000 sml, +- 1.2 sec)
opw-2371161
X-original-commit: b79364910e94bbb0216d3cb682a3c4550713e134
Commit 49b965eb1ec6a7ec6c07fa643cc6ae35ee8b5d91 introduced
`product_tmpl_ids` into the context for displaying kit components but
did not use it in the domain due to a missing `s`.
This commit adds the missing `s` in the domain.
closesodoo/odoo#62870
X-original-commit: aa135eb966810311837f4d446962850bb5aec82d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit, the method who check if the user is in
multiwarehouse wasn't call when a warehouse is archived/unarchived.
closesodoo/odoo#62615
X-original-commit: 1ca34276e7684927d8628df9aa592fad7c1a5871
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
If we try to write on a multi recordset warehouses, we
get a singleton error
closesodoo/odoo#62705
X-original-commit: fc46f26d392d8d9fb499de98d89ce9cef84729a4
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Instead of having a module handle the procurement_jit, we now
incorporate it directly within sale_stock._action_launch_stock_rule and
make it dependent on the new stock.picking.type reservation_method option
rather than applying to all deliveries.
Note that only picking scheduler trigger has been moved to sale_stock,
since the action_assign portion of its moves are now handled directly in
stock.move.
Also we add a new test to ensure new reservation_method logic works
as expected with sale orders.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
nie