WO are released in confirmed state, but the help message says that they are released in draft.
opw-2609040
closesodoo/odoo#78954
X-original-commit: 3244944d0b6ccf7d18d8bb852183d14282674097
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Stock.location is ordered by "complete_name" which is possible to be the
same (i.e. default production locations for different companies). This
may result non-deterministic order. Add "id" to avoid it.
closesodoo/odoo#79181
X-original-commit: 94a8ad3fae914b046064bb7ce17572be8280f6e0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Fix a small logic bug which made it so draft outs would only show only
if there were also draft ins.
closesodoo/odoo#79067Fixes: odoo/odoo#78872
X-original-commit: c764709715f0a86ac531f3be6d73ecadacbdeafc
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
"Material Availability" vs "Component Availability" label means
the same thing but it shouldn't.
- Rename these and add a help string for both fields.
- Change decoration to be green if the MO Readiness is
'ready'.
- The logic of `_compute_*_availability` doesn't take in account the
'ready' `(reservation_)state` to distinct clearly both fields
(`(reservation)_state` vs `*_availability`)
task-2668922
closesodoo/odoo#79033
X-original-commit: acc385137a6a59f3632d91a7fcabd5ab42e8bc7f
Signed-off-by: Tiffany Chang <tic@odoo.com>
It may happen that there is a property defined on some field that is not
the default property, but rather the property associated to a record.
For example
```
=> select id,name,company_id,fields_id,value_reference,res_id from ir_property where name like '%property_stock_inventory%'
+------+--------------------------+--------------+-------------+-------------------+----------------------+
| id | name | company_id | fields_id | value_reference | res_id |
|------+--------------------------+--------------+-------------+-------------------+----------------------|
| 528 | property_stock_inventory | 1 | 4665 | <null> | product.template,752 |
| 6 | property_stock_inventory | <null> | 4665 | stock.location,5 | <null> |
+------+--------------------------+--------------+-------------+-------------------+----------------------+
```
In this case the property with id=528 is not a default property since
res_id is not NULL. Alternatively the property id=6 is a default one.
The issue here is that when searching for the missing locations we do
not filter out the properties with res_id not NULL, thus we may get that
a company has the location define while in fact it doesn't. Following
the example above, this means that we incorrectly get property id=528 as
the one defining the location for the company id=1 here:
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L107
This not only prevents the creation of the correct default property but
also the default locations
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L36-L51
On this patch we fix the domain search for default property. This allows
for the correct creation of the default locations and associated
properties.
This issue was observed during upgrade 40921, where it prevents the
upgrade to 15.0
closesodoo/odoo#79000
X-original-commit: b9d98950826e7272b1df4f6f2467d1d2d14dcc64
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Hide the "Clear All" button next to "Assign Serial Numbers" button when
there are no move lines to clear.
Follow up to task: 2426281
closesodoo/odoo#75676
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Due to floating point limitation, the quantities displayed in the
forecasted report should be formatted to ensure the rounding.
Issue example:
(Need stock)
1. Create a storable product P
2. Update its quantity to 7.1
3. Consult the Forecasted Report
Error:
Quantities are "7.1000000000000005 Units". In this case, the
floating-point issue comes from the method `float_round()`
Another example:
(Need purchase_stock)
1. Create a storable product P
2. Update its quantity to 0.1
3. Create a PO with 0.2 x P
4. Consult the Forecasted Report
Error:
The "Forecasted + Pending" quantity is 0.30000000000000004 Units. This
field is directly computed while rendering the report, it's the sum of
0.1 and 0.2 which, in python, results in 0.30000000000000004
(floating-point issue)
Since the rounding of these quantities are actually based on the decimal
precision of the UoM, this commit may slightly change the report.
Suppose the generic precision is .001 and the precision of "Units" is
0.01: if the quantity is 12.34, one zero will be added in the report:
12.340. However, these unnecessary zeros do not change the information
that is initially displayed. Moreover, the UoM precision can not be
greater than the generic precision, so we will never lose a part of the
quantity to display.
OPW-2611892
closesodoo/odoo#78853
X-original-commit: f4df8b5eec788cf701e58b02a4be58266d5ddc71
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
- Improve _search methods of stock/product by using subqueries
- Improve efficiency _search_on_hand of stock.quant (see
odoo/odoo#77190)
closesodoo/odoo#78847
X-original-commit: 82562cc25c10500d30056ca19d816c1d211a24eb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Sets the `inventory_quantity_set` as an editable field (not readonly)
and creates its own compute to avoid to override it each time the
`inventory_quantity` is modify and we set the `inventory_quantity_set`
aside (before this commit, this field new value was always overrided by
the `inventory_diff_quantity` compute).
This is useful when we want to write on the quants from the Barcode App
as we can write on `inventory_quantity` and `inventory_quantity_set` at
the same time.
task-2632818
closesodoo/odoo#78719
X-original-commit: 489e76ade600f7983a9a1976c04529ac542fdd44
Related: odoo/enterprise#21810
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
The allocation order is not based on the pickings order
To reproduce the issue:
(Need sale_management,mrp)
1. Create a storable product P
2. Create a BoM for another product dummy_P and add 1xP as component
3. Create and confirm a SO with 1x product P
4. Create and confirm a MO for 1x dummy_P
5. Process a receipt transfer with one P
Error: On the SO, the reserved quantity is still 0. The product has been
reserved for the MO, even if the picking of the SO has been created
first
The default order of several SM is based on the sequence and the
identifier:
https://github.com/odoo/odoo/blob/abc9fdaae2927214d98082f391a1dc0fc75e4c77/addons/stock/models/stock_move.py#L26
The default value of the field `sequence` is 10:
https://github.com/odoo/odoo/blob/abc9fdaae2927214d98082f391a1dc0fc75e4c77/addons/stock/models/stock_move.py#L26
When creating a SO, the field isn't defined so its default value is used
(10). However, when creating the MO, the field is defined thanks to the
sequence of the related BOM line:
https://github.com/odoo/odoo/blob/864d90a064f093bd6ba24d8464ee491a443a320e/addons/mrp/models/mrp_production.py#L940
Which, in our case, is equal to 1
As a result, when allocating the quantities in `_action_assign`, the
recordset will contain first the SM of the MO and then the SM of the SO.
This commit ensures the order will be based on the priority, the date
and the identifier (the latter allows the search result to be
deterministic)
Side note: this commit also adds the identifier to the search in
`_run_scheduler_tasks` to keep consistency between the different
flows
OPW-2524205
closesodoo/odoo#78497
X-original-commit: da2b336d467d95cda8ed21707535fb7119f5d777
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Creating lots of production lot can take a huge amount of time if the
mail message follower is added on each chatter.
This commit removes this functionality to speed up the creation as
there is no real need to have the lot creator as follower of it.
closesodoo/odoo#78547
X-original-commit: 9b0e669216948da2710e2e16007f03e47fb7e704
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Searching the stock move line candidate to update at reservation can be
shorten by breaking the loop once one is found
X-original-commit: 93df2568914bee307209e1e739912976c23e1f1d
Part-of: odoo/odoo#78547
The recomputation of stock move state is often done with already
the correct state (for instance in the case of move line deletion only
one of the deletion will change the state).
This commit check the move state before changing it only when it's
necessary.
Task: 2507143
X-original-commit: 80033446a091ff3ba98c58ba44ad665bfba30c98
Part-of: odoo/odoo#78547
Co-authored-by: Remy Voet <ryv@odoo.com>
Process operations in wave transfers exists in community edition.
closesodoo/odoo#78461
X-original-commit: f078b9f69341405d14a268d5371c9360aa66475d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit makes the picking search by product more consistent with
the general product search as the following case could happen:
- Have a product with two variants;
- Each variant has the following internal reference:
- Variant 1: 'SoMething'
- Variant 2: 'SomethingElse'
- Create two pickings, each one containing one of the variant;
- Then filter pickings by product and the result will vary:
- Searching for 'SoMething' -> Found one picking
- Searching for 'Something' -> Found two pickings
The expected behavior is to find the two pickings in both cases.
opw-2646214
closesodoo/odoo#78451
X-original-commit: d0090ee01fc3d105ad87d6764733fe332b36db56
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
How to reproduce:
- Create a product tracked by lot;
- Create two receipts for this product;
- Use the same lot name in the two receipts;
- Try to validate the two receipts in the same time
=> `ValidationError` will trigger in the `_check_unique_lot`
constrain of the production lot.
task-2646107
X-original-commit: cf018e9f215336ef19e0a517d4e116f0da26850e
Part-of: odoo/odoo#78189
scrap_qty field was missing the digits attribute, and therefore the user
could not create a scrap with a quantity with more than two decimal places.
With this commit, scrap_qty will follow the 'Product Unit of Measure'
precision setting, just like any other quantity fields.
closesodoo/odoo#78338
X-original-commit: d9ed98f56e00f38cb3fd87bc9b7cad981a1c4400
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The generate serial number button uses the stock.lot.serial sequence by default
(default value for name of stock.production.lot)
Serial Mass Produce (and other parts) allow to generate serial numbers
starting from a user supplied initial value.
This fix makes the button generate the next serial number
according to the last generated.
task 2647238
closesodoo/odoo#78258
X-original-commit: b80259dff3aaafb9d11af9d936f5106bdf5ed781
Related: odoo/enterprise#21641
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Jean-François Aubert <ajf-odoo@users.noreply.github.com>
In large database with unique serial number. The index add performance.
closesodoo/odoo#78087
X-original-commit: ccefa18bb2873412e6b0ac9e0f5e61ac82ccc51e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Remove unused method get_theoretical_quantity
- Remove unused args of _get_domain_locations_new and simplify it
closesodoo/odoo#78078
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When increasing the quantity of a validated Sale Order, the reserved
quantity in the related pickings aren't updated to match the new
quantity set in the Sale Order. It requires to either let the scheduler
run or clicking the 'Check Availability' button to update the reserved
quantity in those pickings.
If the reservation_method for this picking_type is set to 'at_confirm',
this is not the intended behavior as this picking is already confirmed,
so it should be updated without user input.
The reason is that when the new moves (which adds to the quantity) is
merged to the old one, its status is changed to 'partially_available'
because at that moment, the product_qty is bigger than the
reserved_quantity, which needs to be updated to match the new needs.
closesodoo/odoo#76752closesodoo/odoo#78070
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Allow the quantity decrease of Sale Order line of a MTO product.
When increasing de quantities, the related pickings, RFQ / PO are
increased as well, but it wasn't the case if decreasing the quantity.
It should allow the cascade of the decrease in the related pickings as
it would work for the increase. Also modifies a related Purchase Order
if it wasn't yet validated (and thus still a RFQ).
merge_moves was modified so it would allow the merge of negative moves
with positive ones, while trying to "deplete" as much quantity as
possible for each mergeable move.
But negative moves don't always have all required properties to be
compared to the positive ones (some keys might be missing, such as
'created_production_id'). That means we will merge strictly the positive
moves at first as it was done before. But then we try to merge them "less
strictly", using less keys to compare.
Let's say we have those moves (and all other relevant keys matches) :
- move_1 : {qty : 5, created_production_id: 1}
- move_2 : {qty : 3, created_production_id: 2}
- move_3 : {qty : -6, created_production_id: False}
move_1 and move_2 cannot be merged as they don't share the same
created_production_id. But to merge move_3, we'll need to merge it into
move_1 and move_2. It will then deplete move_1 and decrease move_2.
Which will leave us with :
- move_1 : {qty : 0, created_production_id: 1}
- move_2 : {qty : 2, created_production_id: 2}
move_3 will be unliked as its purpose is done.
Task-2513592
Part-of: odoo/odoo#78070
By setting a company on the package type, this makes it so the package
type isn't selectable for packages without a company (i.e. Put in Pack
without validating a picking = package without a company). For the sake
of demos, let's make it so any company can use these package types.
Task: 2623434
ENT PR: odoo/enterprise#21179closesodoo/odoo#77597
X-original-commit: 7ec72c3d838dd40aad921b65b998b68c59225e01
Related: odoo/enterprise#21349
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Steps to reproduce the bug:
- Create a product and enable serial number option
- Create one “on hand qty” with SN e.g: “001”
- Create a SO for SN product
- Confirm SO and check the delivery order
- In the Operations tab > Enable Serial Number field
- “001” SN is already reserved in Detailed Operations and the qty done is 0 but the Serial Number field in “stock.move” is empty
- Edit and add “001” in the SN field
- save
Problem:
- The SN is deleted and the quantity done in the `”stock.move.line”` is not updated
Solution:
Update the quantity done in the `“stock.move.line”` linked to the selected SN
opw-2623101
closesodoo/odoo#77564
X-original-commit: abc9fdaae2927214d98082f391a1dc0fc75e4c77
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Avoid traceback when click on priority widget
- Also, fetch directly the lazy column if the web client read one record
(happen when we modify a single record).
closesodoo/odoo#77402
X-original-commit: eb26406cff7a0c61768c287a0525c2b6bc123f9e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Avoid some useless read_group on stock move (fetch too much qty fields
in product.product) and use a query object to avoid fetching data.
To compute 11K of forecasted information of stock move (multi-warehouse
):
- Before: 1.704 ± 0.046 sec and 174 SQL request
- After: 1.554 ± 0.012 sec and 134 SQL request
X-original-commit: 338edd616c2afe1d7a08a06a0b0278c3d7083c05
Part-of: odoo/odoo#77402
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
- create Tree warehouses, WH1, WH2, WH3, with three different address
- add route 2-1 to resupply WH2 from WH1, complete partner_address_id on rule with partner_id of WH2
- add route 3-1 to resupply WH3 from WH1, complete partner_address_id on rule with partner_id of WH3
- create a product
- add orderpoint, WH2/Stock with route 2-1 and min_quantity to 1
- add orderpoint, WH3/Stock with route 3-1 and min_quantity to 1
Lauch scheduler.
Issue:
You have 1 out picking of WH1, with qty = 2. It doesn't make sens because WH2 and WH3 have not the same address.
With this PR, 2 out picking are created.
closesodoo/odoo#77151
X-original-commit: 26833a045e48a88bbc41857110f310acd4fa5335
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When creating a wizard `stock.return.picking` and call
`_onchange_picking_id`, the creation of return picking line will perform
a write on move linked with it, due to `uom_id` being set as related with
`readonly=False`. Set `readonly` to `True` to avoid it
closesodoo/odoo#77242
X-original-commit: 6bdc99f8b67da069c8d26c73b5499d0b0c019c1e
Signed-off-by: Tiffany Chang <tic@odoo.com>
Merge duplicate code of `_check_move_lines_map_quant_package` (of
`stock.picking` and `stock.package.level`.
Also remove unused `_get_contained_quants` method in
`stock.quant.package`
task-2648449
closesodoo/odoo#76761
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
Improve the performance/scalability of the forecasted compute.
Duplicate the code of the `_get_report_lines`
(`_get_forecast_availability_outgoing`) and specialize it to only
compute necessary information for the `_compute_forecast_information`.
It is mandatory to readd 'Component/Product Availability' (MO/picking)
which aggregate the result of `_compute_forecast_information`.
Note that with this refactor, it is still too slow to add in the
view normally. We should fetch it with a lazy way.
With a DB populate with 3 company and 6 warehouses (2 for each company),
50 locations, 30K stock moves, 9K quants and 1700 products.
Before fix:
To read 40 confirmed stock move (with forecast information):
35 SQL request, 0.031 ± 0.0004 sec of SQL, 0.204 ± 0.008 sec of Python
=> 0.235 sec
To compute 7300 forecast information (52 draft MO - 99 confirmed MO):
382 SQL request, 1.334 ± 0.052 sec of SQL, 6.807 ± 0.223 sec of Python
=> 8.141 sec
After refactor:
To read 40 confirmed stock move (with forecast information):
35 SQL request, 0.029 ± 0.0004 sec of SQL, 0.074 ± 0.003 sec of Python
=> 0.103 sec
To compute 7300 forecast information (52 draft MO - 99 confirmed MO):
369 SQL request, 0.550 ± 0.009 sec of SQL, 0.969 ± 0.012 sec of Python
=> 1.519 sec
task-2579011
Part-of: odoo/odoo#77092
- Clean the `report_stock_forecasted` for the next commit.
- Add some test about the `_compute_forecast_information` to ensure
the correctness of the forecasted widget.
task-2579011
Part-of: odoo/odoo#77092
The `_compute_warehouse_id` wasn't never batched (never prefetch)
because of the `recursive=True` in its declaration.
Remove the recursion depends and add manual
invalidate cache to stay consistent.
It avoids extra SQL request by prefetching correctly
the `warehouse_id` fields.
task-2579011
Part-of: odoo/odoo#77092
Improve 'Component Availability' and 'Product Availability':
Add these fields in form and tree view (the performance issues
is addressed in next commits and these fields will be load lazily)
task-2579011
Part-of: odoo/odoo#77092
The `_compute_json_popover` of (`mrp.production`)
was slowing down the tree view of MO (because it loaded
every move due to `production.move_raw_ids` even if there
isn't `delay_alert_date`.
Make it more lazier: we gain a speed up
when the there aren't any delay_alert_date
(always when the setup is simple)
To read 150 MO (7500 moves behind):
Before: 0.099 ± 0.002 SQL sec, 0.224 ± 0.005 Python sec (37 SQL requests)
After: 0.060 ± 0.0008 SQL sec, 0.096 ± 0.002 Python sec (29 SQL requests)
Also, unify the code with `stock.picking`.
task-2579011
Part-of: odoo/odoo#77092
The reserved and the done column doesn't have any sense for
draft picking and the forectasted button was always green.
-> Fix it
Also we add forectasted information for draft move in mrp
(281e1a57b3).
-> Use it also for outgoing picking
task-2579011
Part-of: odoo/odoo#77092
In multi-warehouse, when we open the forecasted report from a component
line of MO, the default warehouse in the forecast_report was always the
first of the company. Because it took destination location warehouse
(== False because it is destination location == subcontracting location)
instead of the source location in case of MO.
task-2579011
Part-of: odoo/odoo#77092
roen-odoo