When a serial number SN is trying to be consumed and has been unbuilt in the past,
an evaluation is used to check that the # of times SN was unbuilt is equal to
the # of times SN was consumed. However, when counting the unbuild SN it did not take into account if
it was from an unbuild order.
opw:2510294
closesodoo/odoo#72272
X-original-commit: 47d6ff49b19e68d84a68d8c4b999cb6115398805
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The problem arises when a user creates a backorder for a MO after
registering overconsumption of some components through the simplified view.
The quantities of the components of the new backordered MO are then wrong.
Components that were over consumed in the first MO will have smaller
quantities in the new MO, the difference being the amount over consumed.
This problem does not appear in the case of the Tablet View where a proper
recalculation of quantities is done.
closesodoo/odoo#64911
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> fields
1) maintenance.request -> description
2) maintenance.equipment -> note
3) maintenance.equipment.category -> note
4) mrp.workcenter -> note
5) mrp.workorder -> operation_notes
6) mrp.routing.workcenter -> note
7) repair.order -> internal_notes
8) repair.order -> quotation_notes
Task Id: 2499504
X-original-commit: 0cca26b5358cd9d69a65c6b93cfecb33d7e659c5
When planning a Manufacturing Order, if an operation takes place in work
center with a different time zone, the computed date may be incorrect
(the start date may be outside the working hours)
To reproduce the error:
(Use demo data. Current timezone: Europe/Brussels)
1. In Settings, enable "Work Orders"
2. Open an existing Work Center
3. Click on "Standard 40 hours/week"
4. Set Timezone to "Asia/Bangkok"
- Note that all slots are between 8:00-12:00 and 13:00-17:00
5. Create two storable products P_compo and P_finished
6. Create a Bill of Materials BM:
- Product: P_finished
- BoM Type: Manufacture this product
- Components: 1 x P_compo
- Operations: 3 x Operation with existing work centers
7. Create a Manufacturing Order:
- Bill of Material: BM
- Quantity: 100
8. Save, Confirm, Plan
Error: (it depends on the time the test is done) The 'Scheduled Start
Date' of the second operation is incorrect. Adding the time zone
difference gives a time that is outside the work center's timetable
(i.e., outside 8:00-12:00 and 13:00-17:00).
The computations do not consider the time zone of the work center.
OPW-2393330
closesodoo/odoo#71332
X-original-commit: dab24e497f095d0c7857f07d037e9cb16749e2ea
Related: odoo/enterprise#18572
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
In a Manufacturing Order, the components' quantities are rounded using
the rounding precision of the produced product's UoM. This leads to
incorrect values.
To reproduce the error:
1. In Settings, enable "Units of Measure"
2. In UoM, edit Units:
- Rounding Precision: 1
3. Create two products P_finished and P_compo
- P_compo's Product Type: Consumable
- P_compo's UoM: L
- P_finished's UoM: Units
4. Create a Bill of Materials
- Product: P_finished
- 1 Component:
- Product: P_compo
- Quantity: 0.2
- UoM: L
5. Create a Manufacturing Order:
- Product: P_finished
6. Confirm, Mark as Done
Error: Qty to consumes became 0 and consumed qty is 0. Both values
should be 0.2L, but they have been rounded using the rounding precision
of Units
OPW-2529462
closesodoo/odoo#71293
X-original-commit: aff3a2e06801dfb7a58df5180fb4ab5487b27f02
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
With this commit, changing the scheduled date on a planned production
order will unplan the workorders and so highlight the 'Plan' button to
replan them from the new scheduled date.
closesodoo/odoo#71089
X-original-commit: a6783acaef3c7c2224d1cda72717a36c4b38c001
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Batch the bom_search of bom_lines in mrp_bom.explode.
If we represent the bom hierarchy as a graph, essentially
switch from a depth-first to a breadth-first search, allowing
to batch search boms for each depth level, hence improving
the overall performance.
closesodoo/odoo#71137
X-original-commit: 44ae26e4477e1b76b3dbb0f1acd50e8553b14d71
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When updating the quantities available for a product, an inventory move
is generated without setting the product_tmpl_id, as this field is related
to the product_id of the move. However, when creating the move, Odoo will
consider it a default missing value and will try to fill it in the method
default_get.
When navigating to the product variants of a template from the template form,
a default_product_tmpl_id is set in the context pointing to the template. This
context is propagated to the update quantity action to create/update quants for
the variant.
The problem when dealing with kits is that the products available to update
their quantities are the components of the kit. When navigating to a variant
and updating the quantities of a component of the kit variant, the default product
template in the context will be the kit template.
This is causing that, when generating the inventory move, the move is created with
product_id of the component, and product_tmpl_id of the kit template.
This issue creates a critical data inconsistency as the component's template is set
to the kit's template, which apart from making no sense generates a recursion error.
To fix this, when triggering the action to create/update quants for a kit product, it
must be ensured that no default product template is being set.
closesodoo/odoo#71069
X-original-commit: bdeea73dc1efb6ff7d02cc2f58347a69762bcc3c
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
If a MO is validated with all of its (component)
move_raw_ids.quality_done = 0, then when trying to validate the
nonsensical "The quantity to produce must be positive" validation error
will occur. This is due to all move_raw_ids being marked as Cancelled,
which auto-updates the MO state to cancelled, which prevents the
validation from properly completing.
To avoid this error, we prevent the user from having 0 consumption for
all components.
Task: 2422698
Related (v13 fix + bug description) Task: 2463893
ENT PR (test fixes): odoo/enterprise#18355closesodoo/odoo#71068
X-original-commit: 81ba7084aeb3899787d083a2a2568a490f9c53e5
Related: odoo/enterprise#18411
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <ticodoo@users.noreply.github.com>
On unbuild order creation, when the user selects a manufacturing order,
the UoM of the quantity will be defined with the product's UoM instead
of MO's UoM.
To reproduce the error:
(Use demo data)
1. In Settings > General Settings, enable "Units of Measure"
2. Create two products P_finished and P_compo
- Both are storable
- Qty on Hand of P_compo = 12
3. Create a Bill of Material
- Product: P_finished
- Component: 1 x P_compo
4. Create a Manufacturing Order MO
- Product: P_finished
- Quantity To Produce: 1 Dozen(s)
5. Check Availability, Produce, Mark as Done
6. Create an Unbuild Order:
- Manufacturing Order: MO
Error: The unit of measure of the quantity is incorrect, this is
Unit(s), it should be Dozen(s)
The method `onchange_mo_id` defines the product, therefore the method
`onchange_product_id` is also called and here is the issue:
`onchange_product_id` will override the UoM using the product's UoM.
OPW-2467017
closesodoo/odoo#71017
X-original-commit: 1ec10d89ed265e0fb30e98063e80a51a37773ec7
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
This commit makes it so boms are no longer required for a replenishment
of a product via the manfuacture route. This change is related to the
v14 refactoring of the manfacturing app to make it more flexible and
user-friendly. In the refactoring, manufacturing orders no longer
require a BoM, therefore a MO created by a replenishment should also no
longer require a BoM.
closesodoo/odoo#64910
Task: 2422698
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Prior to this commit, MOs would throw a usererror if there were no
components in it. This restriction made it so MOs created by a
replenishment (i.e. `warehouse.orderpoint`) for a BoM with no components
were never confirmed and the `qty_to_order` would accumulate for each
replenishment's new draft MO.
Steps to reproduce:
1. create a bom for a new product (w/ manufacturing route) with no
components
2. create and confirm a sales order for the new product
3. go to Replenishment and automate the product's replenishment
4. create a new sales order for the product
Expected result: 2 confirmed MOs where the quantity of the first MO
matches the first sale order's quantity and the 2nd MO matches the
second sale order's quantity
Actual result: 2 draft MOs where the first MO matches the quantity of
the first sale order and the second MO matches the quantity of the first
sale order + the quantity of the second sale order
This commit makes it so MOs can now be confirmed even when it has no
components. Note this requires changing the logic in a few locations to
ensure expected behavior still occurs including:
- backorders are automatically confirmed.
- `reservation_state` is recalculated when expected (will be blank when
no components).
Task: 2422698
To reproduce:
1. create and confirm a MO with register number checks on operations
2. duplicate the MO
The register number checks won't show up in the new MO
We didn't set copy=False for workorder_id on stock.move, when copy a
confirmed MO, the new moves are linked to old WOs on old MO. New WO
didn't link to any moves.
When create quality checks, we only create "register ..." checks for WOs
with move_id. As a result, new WOs without move_id won't have those
checks.
To fix, set copy=False on workorder_id of stock.move
Task 2484939
closesodoo/odoo#71000
X-original-commit: 6aaf337558e59474efcef937f0175ee531b4b477
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
You can, in a production order, change the quantity done of a stock move
raw and change its initial demand ('To Consume' field) in the same
transaction. This can lead to some issue as changing the quantity done
will update the stock move line and changing the initial demand will
unreserve the stock move thus impacting the stock move lines too.
This commit will split the values to update of a stock in move in case
the two fields have to be updated. First the stock move lines, then the
initial demand.
This commit also remove the default_product_uom_qty in the move_raw_ids
fields. This ensure the onchanges do not create/edit any stock move lines
with some reserved quantity.
opw : 2451298
closesodoo/odoo#70975
X-original-commit: e8c1f6b1a3f58b68181bf4d2599bd37efb83b5c7
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The button plan of in the manufacturing order tree view doesn't
confirm correctly the draft MO selected (but only the related moves).
task-2479111
closesodoo/odoo#70608
X-original-commit: ef9515611ac96368eae14fc941bca15e3724557a
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
If you modify an archived warehouse, it may happen that the associated operations get unarchived. Operations should be active only if their warehouse is active.
closesodoo/odoo#70607
X-original-commit: 63167ac8ae6ac08fa54a133ed9089dd872c7d73c
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit, User can select Cancelled MO before selecting Product.
but it is already blocking since we already have constrains to not allow ubnuilding
Cancelled MO.
With this commit, We are always showing Done MO.
closesodoo/odoo#70316
X-original-commit: 48c0efcc97e35e00ec5803235a89a2c18e821990
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, It was always showing all
Unit of Measures in By Product lines.
With this commit, We are showing UoMs based on Category
of Selected Product's UoM.
closesodoo/odoo#70367
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit there would be trackback (TypeError: unsupported operand type(s) for -: 'datetime.datetime' and 'NoneType') when you will try to remove field Start date as we are using the field to compute duration.
With this commit, we compute duration when Both fields are present.
closesodoo/odoo#70482
X-original-commit: f29597fce37350f1c05d98341b959809bbb160b2
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, Creating Unbuild order using
Unbuild Button was resetting Bom as it was calling
`_onchange_product_id` after setting `mo_id` which was
resetting Bom on Unbuild order.
To Fix Issue, We setting `default_product_id` so It would not
reset `bom_id` when `_onchange_product_id` is called.
Fixes: #70216
Odoo Ticket: 2521788
closesodoo/odoo#70304
X-original-commit: 4de0ae434d1adc97fc1077b8d0f23c7e800ec161
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Without this commit, User was not allowed to create Unbuild Order
for the product without BoMs from Unbuild Orders menu.
But User was able to create Unbuild Order using 'Unbuild Order' button
on MO.
With this commit, We are allowing user to select Products without BoMs
to make this behavior consistent so user can create Unbuild Order from
Unbuild Orders menu.
closesodoo/odoo#70246
X-original-commit: eb332de42a36b7235d5578d39d345a5ff1df7759
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, if any workorder is stared to produce, qty
producing was 0. After this commit, if product tracking is none
then system will suggest the remaining qty of workorder to produce
when user is start it.
TaskId - 2480775
closesodoo/odoo#70207
X-original-commit: 5bbc234d43a415be18fcfa42dad33b1577644719
Related: odoo/enterprise#18086
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
previous implementation works slowly for products with many variants.
Performance Test
================
* ~5 K product.template
* ~14 K product.variants
* ~12 K mrp.bom
* ~414 K mrp.bom.line
Reading time for the field on a product with ~1000 variants
Measuring total request time:
* Before 9,5 sec
* After:
** without module upgrade 1,5 sec
** with module upgrade 0,3 sec
Measuring query execution in psql:
* Before 7,2 sec
* After:
** without module upgrade 0,7 sec
** with module upgrade 0,001 sec
---
opw-2494423
closesodoo/odoo#69293
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Method `_onchange_workorder_ids` will create workorder_ids
for the the selected bom but it was not re-setting it on removing
BoM.
It was causing issue on `_action_confirm` as Bom for the selected
WO will not be found.
closes odoo/odoo#69662
Fixes: #68261
X-original-commit: 13832912daafad7c472d7414eaacede9e302e787
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Usecase to reproduce:
- BOM PROD 1 -> No operation -> KIT COMP 1
- BOM KIT COMP 1 -> at lease one operation
Create a MO and confirm it -> Traceback.
It happens because workorders_by_bom[production.bom_id] will try to
find the bom related to production order. However they don't exist but
it will create the entry [BOM PROD 1] = mrp.workorder()
The [0] will be call on each values of the list afterward and raise
the traceback
opw-2477269
closesodoo/odoo#69651
X-original-commit: edabb86a306c4dda088b39f163de5668b5d90392
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
previous implementation works slowly for products with many variants.
Performance Test
================
* ~5 K product.template
* ~14 K product.variants
* ~12 K mrp.bom
* ~414 K mrp.bom.line
Reading time for field ``used_in_bom_count`` on a product with ~1000 variants
* Before 9,5 sec
* After 1,5 sec
---
opw-2494423
closesodoo/odoo#69341
X-original-commit: a2d63e8ae5d6bc0e822d12d724b5e3ff5a979cad
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Ease bill of material - operation configuration.
- allow to change the BoM of an operation,
- allow to update a BoM by duplicating existing operations(& quality points),
- by extension, changing the operation of a quality point update the products.
closesodoo/odoo#65628
Task: 2413246
Related: odoo/enterprise#16159
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When we deactivate the work orders in the settings, new MOs still
use operations that were assigned to the BoM, it just does not show the
Operations tab. We fix that by archiving the operations when work orders
are deactivated in the settings.
closesodoo/odoo#66108
Related: odoo/upgrade#2344
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When marking an operation as done, the quantity produced may be zero.
Therefore, the duration computation will not work.
To reproduce the error:
1. In Settings, enable "Work Orders"
2. Create two products P_prod and P_compo
- P_compo is consumable and its cost is 100
3. In Manufacturing, edit/create a Work Center WC
- Cost per hour must be 60
4. Create a Bill of Materials BM
- Product: P_prod
- Component: P_compo
- Operation:
- Work Center: WC
- Duration Computation: Compute based on tracked time
- Based on last 3 work orders
- Default Duration: 10:00
5. In Structure & Cost, notice that BoM Cost is 110
- 100 (P_compo's cost)
- 10 (OP's cost based on default time)
6. Do the following 3 times:
- Create a MO with P_prod using BM, Confirm
- In Work Orders, click on Start, then Done
- Edit the Real Duration of OP: 20:00
- Mark as Done
7. Back to BM, open Structure & Cost again
Error: BoM Cost is 110, this is incorrect: OP's cost is still 10, it
should be 20 (from step 6).
The problem is the quantity produced for each operation. Since this
quantity is never defined, it remains at 0. Therefore, when computing
the duration, since there is no quantity, the module keeps the default
value.
This fix changes the behavior. When the user marks the operation as done
from the form view, the module defines the quantity produced using the
quantity in production (this quantity may have been defined by the user
through the tablet mode). If this value is also 0, the module will use
the quantity expected by the MO.
`('qty_produced', '>', 0)` is added to avoid lines with zero quantity
produced, which was possible before this fix. Otherwise, the duration
calculation will give wrong values.
OPW-2453996
closesodoo/odoo#68917
X-original-commit: 93be6c6cfcfb3c4e52790569632dbdcdb1a3ae54
Related: odoo/enterprise#17540
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
We introduced new Smart Putaway Rules.
Locations now can have a storage category, on each storage category,
we can specify the amount of products/packages(with certian package
type) that can be stored in the location.
On putaway rules, we can also set a storage category. Now when apply a
putaway rule, we will find a suitable child location of the out
location according to quantity/weight setting on the storage category.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
To avoid multiple search of the get_warehouse for the same location
and extra SQL request (it happens a lot for complicate flow, e.g.
mrp_mps, replenishment report).
Translate it into a standard compute to use the cache of
the ORM for no-store compute field (`warehouse_id`) and put
some depends to be always correct (even if `warehouse_id` shouldn't
change in the same request).
task-2439019
Some usage of `_bom_find` are performance bottleneck (one request by
product). By example, when the mrp is installed, search products
with fields compute by `_compute_quantities` (e.g. 'Negative forecasted
quantity'). it is due to the override of `_compute_quantities`
in mrp which will make (in the worst case) a `_bom_find` for each
product in the DB.
To avoid this situation the `_bom_find` method become batched
which can handle several products in once. The signature of the method
has changed and uniformize in all module.
Example performance Gain:
------------------------
In a DB with 7000 products (type 'product'), 500 locations, 1800 BoM,
9000 Stock moves, etc. Search in the tree view with filter "Negative
forecasted quantity":
Before: 10879 (nb SQL request) 12.67 +- 0.11 sec (Total RPC Time)
After: 159 (nb SQL request) 1.82 +- 0.03 sec (Total RPC Time)
task-2439019
Considering the MO under consumption situation:
component A, to consume = 2, consumed = 1
Previous, after "mark as done", the MO will have two lines:
component A, to consume = 1, consumed = 1, state done
component A, to consume = 0, consumed = 0, state done
Now, after "mark as done", it will be consistent with picking:
component A, to consume = 1, consumed = 1, state "done"
component A, to consume = 1, consumed = 0, state "concel"
Task 2446915
PR #66583
ENT PR odoo/enterprise#16554
Because kits might never be in stock, it's impossible to fullfil the
quantity of a reordering rule: asking a mini/maxi quantity on a kit
makes no sense.
Odoo will continuously propose to order more to reach the quantity
necessary for the kit, but will never reach the asked qty, as it's a
kit, not a manufactured product.
OPW-2448878
closesodoo/odoo#68362
X-original-commit: c47a9319c081105e46e56f881b25fd6442266089
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Some changes on the MRP workcenter model (`mrp.workcenter`):
- Adds a stat button in the form view to display operations used by
the workcenter;
- Enables the multi-edit on the list view;
- Adds multiple fields in the list view, often as optional;
task-2382256
closesodoo/odoo#62126
Related: odoo/enterprise#17250
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
On the MRP operation model (`mrp.routing.workcenter`):
- Changes the order (ordered by workcenter and BOM in priority);
- Adds computed field, `time_computed_on`, which is only used in list
view (display on how many numbers of work orders the duration is
computed);
- Adds multiple fields in list view (often optional display);
- Adds two groupby (by BOM and by workcenter).
task-2382256
The`picking_type_id` of the stock.rule wasn't take in account in
the search of BoM because the `_get_matching_bom` with a empty `self`.
fix it by call on the current rule.
X-original-commit: d43e9cb9ad8d1c0c020209de0e8f6ffdcbc960a1
The replenishement creation currently calculates the quantity to order
using a default multiple quantity of 1. In case of manufacturing route,
we want to calculate the multiple quantity according to the quantity
produced in the BoMs.
closesodoo/odoo#62766
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Issue:
On DB with a lot of product (e.g. 50K) the MO form is very slow
open/modify. It is due to the `_compute_allowed_product_ids` which
will set the `allowed_product_ids` fields with all product ids possible
(32K), then the `convert_to_record` will take a bunch of time to filter
out no-active product.
Fix:
In your case, to avoid to send bunch of ids to the web framework and
bypass the costly `convert_to_record`, we decided to simply (static) the
domain of `product_id` (`mrp.production`). The flow will be slightly
different (doesn't filter depending of `bom_id`) but still good and
maybe better (we can now modify the product without removing the
BoM/product in the MO form).
Remove `allowed_product_ids`.
opw-2475151
closesodoo/odoo#67753
X-original-commit: a1a4f4548b395127cf7f816379a63f2d47688893
Related: odoo/upgrade#2272
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Add and improve onchange warnings when a duplicate SN is used in
following cases: inventory, picking (any type), manufacturing, scrap,
and "Update Quantity" (i.e. directly edit quants from product form).
Improvement includes:
- include location where the existing SN is
- auto-correct source location when appropriate (e.g. trying to scrap a
SN in the wrong location)
The goal of this is to prevent but not restrict duplicate SNs so users
can have some flexibility (especially if a dupe SN occurs because of an
error such as doing pick-pack-ship out of order.)
closesodoo/odoo#61287
Task: 1924758
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Replenishment is great to replace MTO but misses the direct link between SO and PO (smart buttons on both SO and PO to link to the corresponding PO and SO).
The info is actually there in the forecasted report but it is not accessible directly from the PO and in the case of the SO does not highlight the corresponding line of the SO.
This adds a graph icon in the PO, MO and receipt form to directly access the forecasted report (it already exists for SO and delivery).
The information linked to the SO/PO/MO/receipt/delivery is also sent to the forecasted report to highlight the corresponding line.
Note that in the case of the SO, the information needs to go first through the qty_at_date widget (which contains the link to the forecast report).
The graph icon for the PO, receipts and MO turns red when the forecasted quantity at expected date is negative. This is done using the new 'forecasted_issue' field.
closesodoo/odoo#62264
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When `qty_available` was being called
for a kit and its components at the same time,
e.g.:
- Kit product
- Product 1
- Product 2
The kit product available qty was always computed to `0.0`,
because when computing its component available quantity,
they were computed to `0.0` because they were marked
as `protected` by the ORM when calling the compute method
for these records at the first call.
When the `qty_available` compute method for the kit
then called recursively the `qty_available` compute
method for the component, as the component record
were marked as protected,
the ORM filled their value with the Falsy value `0.0`.
This issue occured particularly in the upgrade integrity unit test
which makes sure the available quantities of the products remain
unchanged after upgrade. This test computes the available
quantities for a bunch of products at the same time,
and its therefore likely a kit product gets its available
quantity computed as the same time than its components.
upg-3185
upg-4215
upg-4228
upg-5558
upg-5745
upg-5856
upg-6012
upg-6064
upg-6076
upg-6306
upg-6514
upg-6588
upg-6729
closesodoo/odoo#65758
X-original-commit: 8e152a567a6003dae4abb3b537b963eec4142d6d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
If a product is a kit and has a storable component, if this component is
already ordered (with sufficient quantity), when running the scheduler,
the ordered quantity of this component will still be increased.
To reproduce the error:
1. Create two products P_kit and P_compo
- Both are storable products
- P_compo must have at least one vendor
2. Create a BoM for P_kit:
- Must be a kit
- Add P_compo to components
3. Set a reordering rule for P_kit
4. Inventory > Operations > Run Scheduler
5. Go to Purchase and find the generated RfQ
- The ordered quantity is correct
6. Repeat 4-5
Error: This time, the ordered quantity is incorrect. While you don't
have any P_kit on hand, each time the scheduler is run, the ordered
quantity will increase.
A similar issue has already been fixed: #63891. The original commit
targets the version 13, but the fix has also been applied to v14 (#64277).
However, here the case is slightly different: the user run the scheduler
twice while the first RfQ is not yet confirmed and received. In such a
case, the scheduler must also check the "quantity in progress". In version
14, it seems nothing computes this quantity for the kits.
OPW-2421841
closesodoo/odoo#65100
X-original-commit: f53ab55000c32fd67c567f01a9533298936daaac
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Add two indexes (on `product_id` and `product_tmpl_id`)
on the `mrp.bom` model to speed up `_bom_find`
which is highly used and it uses always the `product_tmpl_id` and
sometime the `product_id` in the search domain.
Performance Gain:
With a DB with 2K BoM, a `_bom_find` search (`product_id` and
`product_tmpl_id` are in domain): The SQL execution time
is +- 5 times faster.
task-2390516
closesodoo/odoo#64934
X-original-commit: 64861aed03b616820d717bc08e7c38c56145e0f2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
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-2390516
X-original-commit: d9510aee26578e1b345a7700f7c94032d5745bf4
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
Goffin Simon