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
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
This commit adds a footer on the package level form view to close it
automatically on button press.
Task : 2329116
closesodoo/odoo#62625
X-original-commit: a3296b46d35ef42e601e4c9c7b8d7a3206ab2998
Related: odoo/enterprise#15051
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Since 29d8fc091a, stock moves in immediate transfers are automatically
assigned. In case of configuration implying to show details action, new
moves disappear in stock picking
Task : 2329116
X-original-commit: 0d3f32988a862bbf13fcfbad37cce903ab4e9d60
You may have inactive warehouses for some companies and then, when recreating missing warehouses, you try to create same warehouses for those companies, but you can't because there is an unique constraint.
closesodoo/odoo#62620
X-original-commit: 9b91f9d1bb41d05f445d745a9b8e5fa63edaf2a9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Multi-warehouse + Multi-company setup
- Create Company A with warehouse and 1-step delivery
- Create Company B with warehouse and 1-step delivery
- Switch to Company A: Set Logistics route on product category
All/Saleable : 1-step delivery
- Switch to Company B: Set Logistics route on product category
All/Saleable : 1-step delivery
- Switch to Company A, make sure Company B is turned-off
- Create new product and set category to All/Saleable
- Save product
Multi-company error is coming.
This is due to the field `route_from_categ_ids` which is a related, and
therefore fetched as `sudo` by default:
https://github.com/odoo/odoo/blob/f0330d92b31bdae4637ae0c26f40ee07282ab449/odoo/fields.py#L368
Actually, the field doesn't seem to be useful since it is only used in a
view.
Fixes#58357
opw-2390983
closesodoo/odoo#62609
X-original-commit: b68b45d5105a4d797da12ee6a5df6162b52b2d61
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The 'On Hand' button triggers action_open_quants on product model. It
do not explode the kit into its component
closesodoo/odoo#62390
X-original-commit: 49b965eb1ec6a7ec6c07fa643cc6ae35ee8b5d91
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit makes it so the quantity of a SN in a location is now
restricted between -1 < quantity < 1 (previously it was only quantity <
1). This change provides stronger protection against a duplicated SN
(e.g. a quantity of -2 means that the SN was somehow moved from that
location twice). This restriction was also relaxed to not include
location.usage='inventory' because this could prevent the user from
fixing a duplicated SN (since they were prevented from creating a
quantity of 2+ in an Inventory Loss location).
closesodoo/odoo#59834
Task: 2336455
Related: odoo/upgrade#1839
Related: odoo/enterprise#14667
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add a new feature to automatically create/update/delete an inventory by
company for products with conflicting serial numbers. The goal
of this is to help track inventory discrepencies and prevent duplicate
serial numbers across different locations.
This follows the same logic as the negative qty count auto-inventory
feature where a dupe SN inventory will be auto-generated / auto-updated
/ auto-deleted when the "Inventory Adjustment" button is pushed and when
the scheduler is run. Note that -1 quantity of an already in use SN
counts as a duplication of a SN.
Note: a new many2many field `lot_ids` was added to inventory to more
easily track which conflicting SNs to do the inventory on.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to automatically create/update an inventory per
warehouse specific to products with negative qty in any of its
locations. The goal of this is to help track inventory discrepencies
and prevent appearance of being out of stock when there is still stock
left. This is done by having the inventories update/create whenever
the "Inventory Adjustments" menuitem is clicked. Since we don't know
when a product's stock becomes non-negative, we always re-write all the
neg products to existing draft neg inventories and remove any
pre-existing draft inventories that haven't been updated since they no
longer have any neg qty products anymore.
Scheduler will also trigger this recalculation in hopes that it will
reduce having a large number of inventories to create when the inventory
menuitem isn't opened very often.
Note: a flag `is_conflict_inventory` was added to avoid conflicts with
manually generated inventories.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to allow automated (as part of scheduler) generation
of inventory adjustments based on user set value for how often they should
be done for 'internal' and 'transit' locations.
- When is the inventory created?
When cyclic frequency is set to a non-zero value, the next date an
inventory should be automatically generated for a location is based on
whether or not a previous inventory for that location was completed.
If an inventory is overdue based on the previous inventory date, one
will be scheduled for tomorrow. If no previous inventory date exists,
schedule the next one based on today's date. A new inventory will be
created by the scheduler if there is not an existing in progress
inventory for the location (to avoid a conflict).
- What about descendant locations?
Descendent locations will not have an inventory created if their
ancestor is supposed to have a cyclic inventory done at the same time.
Note this includes when that ancestory already has an in progress
inventory and isn't having a new one created.
- What about cleaning out of date cyclic inventories?
This automation will also delete existing draft inventories that include
this location (created before the day the scheduler is run) or any of
its descendants (i.e. inventories with only that descendant location
selected to avoid deleting obviously manually created inventories).
Task: 2336455
Upgrade PR: odoo/upgrade#1839
One can set a Unit of Measure precision rounding more
precise than the overall Decimal Accuracy. This can trigger the error
'It is not possible to unreserve more products', as there will be
inconsistencies on reserved quantities due to decimal roundings.
We add 2 warnings on Units of Measure and Decimal Accuracy.
Therefore, users are warned when their UOM/decimal changes can
cause inconsistencies in quants reservation.
Also, we want to prevent the issue at the root by ensuring that both the move
and the quant have the same reserved quantity.
The contrary can happen e.g. when a product is defined in Liters (rounding .001)
but used in an operation in ml (rounding .01, so e.g. 187.5ml).
The conversions between the 2 UOM can cause the differences of reservations.
In _prepare_move_line_vals we make sure uom_quantity_back_to_product_uom
is not more precise than the overall Decimal Accuracy. That way, if
the reserved quantity changes between UOM conversions, the move line created
is in the quant/product UOM, and we do not have move line's reserved quantity >
quantity in stock.
We do the same for _update_reserved_quantity (stock.move), when updating
a move line.
In _update_move_lines, because of UOM conversions, new_quantity_done
can differ from ml.product_uom_qty, which triggers the creation of an extra
move line, leading to reserved quantity > quantity in stock. To prevent
that, we compare the reserved quantities in the product UOM.
opw 2206902 (Example 1)
opw 2171541
opw 2221227
opw 2233937
opw 2198775
and many more
closesodoo/odoo#62279
X-original-commit: 478a42beb5876171afeab7df27fa69548edbf849
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Configure a reorder rule and a restock route for a product A
Go to Inventory / Operations / Replenishment
Remove all filters, find product A and under column 'To Order' input a
quantity, then hit the button 'Order Once'
The user quantity will be overwritten by the '_compute_qty_to_order'.
This is a fine tuning of f505444655
opw-2375317
closesodoo/odoo#61952
X-original-commit: 0d4ab53b3f7400151105461973d54c6015550b2f
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Behavior prior to this commit:
In the following scenario:
- order of 10 widgets
- delivery using an entire package of 15 widgets (by adding the package
under the "Packages" list and checking the "Done" checkbox)
The delivery, when validated, does not update the delivered quantity on
the sales order, and generates a warning about not shipping enough
product. We expect instead the sales order to be updated with the
actual quantity that was shipped (i.e., 15), and a warning about
shipping too many products.
Additionally, when adding the package, the picking reverts to a "Draft"
state and we have to click "Mark as Todo" again.
Behavior after the commit:
When adding one (or more) entire package in the packages list, and
marking them as Done, their entire quantity will be marked as Delivered
on the Sales Order, and no warning about not shipping enough product
will be shown. Of note, if the package also contains products that are
not on the SO, they will be marked as shipped as well (in that case the
picking will indeed revert to draft since we will have added a new
product). However they will not be automatically added to the SO.
Technical details:
When adding a package under the picking it needs to, eventually, reflect
on a stock move. Prior to the commit, the system would add a new stock
move. This had 2 problems:
- the generated move did not carry back to the SO,
- it would flip the picking back to draft (under certain circumstances
it was possible to circumvent that and have a package level, and a move
line, that was not tied to a stock move and thus would automatically
reattach itself when the picking was validated, and sort of work, but
it was more of a happy accident and relying on the steps being followed
in a very precise order).
With this commit, we do not generate the stock move as soon as the
package is added. Instead, that is done when the picking is marked as
done, either by relating it to an existing stock move, or by generating
a new one at this time.
opw-2367893
closesodoo/odoo#62112
X-original-commit: 173bfe6764a554d601d2c7edac2a4c79e2faaa83
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
`do_unreserve` is a action that can be made in the tree view of
`stock.picking` but it was very slow and not batched.
For 80 picking with -/+ 10 `stock.move.line` related each
(calculate on 5 sample of 80 pickings):
It took 17947 +- 2741 SQL requests, 7.37 +- 1.09 sec of SQL
and 8.13 +- 1.31 sec of python execution (+- 15.5 sec in total)
Make some change to speed up the unreservation of
multiple picking/move:
- Batch the call of `_do_unreserve` of move in picking
- Use OrderedSet instead of RecordSet to reduce the complexity of
`_do_unreserve`. (Become significant when len(recordset) > 1000)
- Add `.with_prefetch()` in the unlink of stock move line
to patch issue with prefetching + unlink + cache.
- Batch `_recompute_state`
- Also batch the `do_unreserve` of MO
Result after change in the same samples:
It take now 1438 +- 20 SQL requests, 0.45 +- 0.02 sec of SQL
and 0.68 +- 0.02 sec of python execution (+- 1.13 sec in total,
13 times faster). Note that the gain increase proportionally.
task-2383111
closesodoo/odoo#62083
X-original-commit: e7a43655448db161150d0c62efa14c54ade0a2f6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
* Do not load x records from database when one is enough.
Earlier SQL returns when a matching record is found.
* any() can receive a generator as argument
Do not explicitly cast a generator as list when it is not needed.
Task Id: 2328664
COM PR: https://github.com/odoo/odoo/pull/55525
ENT PR: https://github.com/odoo/enterprise/pull/12250
What are the steps to reproduce your issue ?
1. Install 'stock'
2. Create 'ProductA' with 'Tracking By Lots'
3. Create some 'Lots/Serial Numbers', for example 'CodeA0 and 'CodeA1'
4. Go to 'Reporting/Inventory Report'
5. Remove 'Product > Location' from the search bar.
6. Click 'Create' and select 'ProductA' with 'WH/Stock' Location
What is currently happening ?
When you set 'Lot/Serial Number', the available lots to choose
are not limited to the selected product only.
What are you expecting to happen ?
Show only lots of the selected product.
Why is this happening ?
The domain contained no condition which depended on the product.
How to fix the bug ?
Addition of a condition that depends on the product.
opw-238143
closesodoo/odoo#62046
X-original-commit: 3b33f1d3f5cb5182d5577176640bcf7427757ed2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The compute `_compute_outdated` of `stock.inventory.line` didn't manage
inventory lines of different `inventory_id` because of the
ensure_one of `_get_quantities` (coming from
68518afe33).
Call `_get_quantities` by inventory and save it in a dict to be use in
the loop after.
closesodoo/odoo#62000
X-original-commit: e369f15a9194b530c14ad1c796e4f10b80338260
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a user U with access rights Inventory Amdinistrator
- Try to create an operation type with U
Bug:
An access error was raised because U has no rights to create an ir.sequence
record.
opw:2381272
closesodoo/odoo#61966
X-original-commit: 472fc28255ad29bcaaa7bd2f68a64018361b2665
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
In this commit, creating SM from SML if trasfer is immediate. Due
to which following issues are getting resolve -
For immediate trasfer -
1) Unable to cancel the picking in draft state and SML is created
by view directly (No SM).
2) Unable to see button Put in pack.
3) Picking remains in state draft instead of ready.
task-2275833
closesodoo/odoo#61887
X-original-commit: f933c15794ec733be51d879de2410302d9804121
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Rémy Voet (ryv)