Il during the scheduler an exception append, the error is not correctly logged.
This PR allow to catch the error with logger analyser (like sentry).
closesodoo/odoo#82648
X-original-commit: c68e1d1c13d116bda6b91fcbbcd61a26739a9894
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Suppose a tracked-by-usn and consumed product returns in the stock
thanks to a repair order. Using again this component in a new
manufacturing order will raise an error
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two products P_finished, P_compo
- Storable
- P_comp tracked by USN
3. Update the quantity of P_compo:
- WH/Stock: 1 x Lot01
4. Create a manufacturing order MO:
- Product: P_finished
- Components:
- 1 x P_compo
5. Confirm, Check availability and Mark MO as Done
- (Lot01 should be consumed)
6. Create a repair order RO:
- Product: P_finished
- Parts:
- Type: Remove
- Product: P_compo
- Lot: Lot01
- Destination Location: WH/Stock
7. Confirm RO, Start RO, End RO
- (There should be one Lot01 available in stock)
8. Repeat 4-5
Error: When checking the availability on the MO, Lot01 is correctly
reserved. However, when marking the second MO as done, a User Error is
displayed: "The serial number Lot01 used for component P_compo has
already been consumed" although this lot should be available
When checking the uniqueness of the lot, nothing includes the products
back in stock thanks to the repair orders.
OPW-2701668
closesodoo/odoo#82544
X-original-commit: 3d9355f90fa1dd9436f1745c515c89947ed04de0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Two key are used for the same purpose. Remove one and
use its content directly in the report
clean commit bef1765b197a9e9d510a7d20d0364333402473b0
Part-of: odoo/odoo#82312
use case to reproduce:
receipt a product tracked by lot
produce a lot with a component tracked*
open the traceability report for the lot's component
you have a traceback.
it's due to last_delivery_partner_id field present in the tree view of lots.
it triggers _compute_delivery_ids that call _find_delivery_ids_by_lot in multi.
the call in the recursion(trigger by *) redefine delivery_by_lot and erase the previous result.
so the cache is not correctly update and traceback
closesodoo/odoo#82351
X-original-commit: e6bcc77c58d39adbd782e776eb2f6d5c470eb0e2
Signed-off-by: Arnold Moyaux <arm@odoo.com>
with l10n_mx_edi_stock being introduced in enterprise - we require the unit of measure object in the aggregated lines so that it can be used on the delivery report.
odoo/enterprise#21591
Task-2585661
closesodoo/odoo#82224
X-original-commit: 4d074686c1eb716020b950ea86650ecf2bda08aa
Related: odoo/enterprise#23244
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Current behavior:
Filter "Owner is not set" on Package in inventory app was causing a traceback
Steps to reproduce:
- Go in inventory app
- Go in package
- Apply a filter "Owner is not set"
- You get a traceback
opw-2714726
closesodoo/odoo#82237
X-original-commit: e4b350907f01253a96ddc763d6fdbdd307874e23
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Steps to reproduce:
-Create a quote with 2 lines (same product - different lead time).
-When a partial delivery is made (e.g., 5 of 10), Odoo places the operation related to the remaining undelivered quantity (5), on the last line in the Operations list.
-When the next delivery is made, Odoo deducts the quantity from the first operation in the list instead of from the line whose deadline is closest.
Current Behaviour :
Odoo assign button assign quantity to the first move line in the list.
Behaviour After the PR:
Odoo assign button assign quantity to a move line based on the priority, the closest deadline and the id.
opw-2657048
closesodoo/odoo#82062
X-original-commit: 430f4f2ca1cebaea62415ee72bf4369684abbfaa
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
- Install stock with demo data
- Log in Chicago company
- Chicago partner has inter-company transit set on Customer and Supplier
locations
- Jeff Lawson (partner address of chicago warehouse) has Customer and
supplier locations set instead of inter-company transit.
It prevents the following usecase:
- Enable synch SO and PO between chicago and SF company with automatic
confirmation
- Create a product with route Buy and MTO
- Create a PO in company chicago that buy to SF comapny
- Validate the PO
You have an error with rule since it try to pull from intercompany
transit instead of customer
However if you log in San Francisco company Jeff Lawson has
inter-company transit set while it should not.
It happens because during the demo install the partner is added through
a write and the company is not provided and the code was missing a part
in that case.
closesodoo/odoo#82006
X-original-commit: 46c49ce4f6c9677463425981f01b69117c11943e
Signed-off-by: Arnold Moyaux <arm@odoo.com>
There is 2 major issues with the production of multiple serials number
- Performance issue
- Duplicated code with classic backorder mechanism
The performance issues exist since backorders were create one by one
and `stock.move` and `stock.move.line` are always recomputed. They
are not created in batch neither.
_generate_backorders is removed and replace by _split_productions. The
functionality are the same. Technicaly it does the maximum in batch,
first it creates all the `mrp.production` then all the `stock.move`
and finaly, it splits the existing `stock.move.line` among the new
`stock.move`
It means that the reservation is not recompute anymore during a
backorder process and will remain the same than the splitted production
order.
Performance metrics (10 components):
| 2 | 10 100 1000
before | 0.47s | 2.84s | 32.25s | 580.53s
-----------------------------------------------
after | 0.13s | 0.36s | 2.60s | 35.17s
task 2633369
Part-of: odoo/odoo#77254
Improvements of the Inventory Adjustements page, among which:
- Add a new 'Apply All' button (without the need to select a record)
- Show the date at which the last count was done
- Add warning icon next to duplicated SN
- Allows to change the lot_id when empty and no quantities are set
closesodoo/odoo#78361
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Due to floating point representation, some floats may have some
insignificant decimals. Therefore, `float_compare` should be used when
comparing such numbers
OPW-2699576
closesodoo/odoo#81138
X-original-commit: 7f30ef42717b009ee569db58b885ce863d969a06
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
This commit adds an index on picking_type_id for models stock.picking
and mrp.production.
Filtering on picking_type_id is often done via the Inventory Overview.
This should speed up the list render in case of many object.
Task : 2648449
closesodoo/odoo#80434
Related: odoo/upgrade#3068
Related: odoo/enterprise#22535
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Add a "clear qty" button to revert the change by "set qty" button in
(batch) picking.
On the move, Whenever the qty_done != reserved, we consider it a
manual change from the user. "set/clear qty" buttons won't change the
line with manual change.
Show "set qty" button when there are moves with 0 qty_done and non-zero
reserved. Show "clear qty" button when we don't show "set qty" button
and there are moves with qty done == reserved but the number is not 0.
Task-2659233
closesodoo/odoo#78737
Signed-off-by: Steve Van Essche <svs@odoo.com>
Steps to reproduce:
- Test upgrade request 40290
Issue:
Traceback raised.
Cause:
The _find_delivery_ids_by_lot function can raise a
RecursionError: maximum recursion depth exceeded if
there is a loop in the path of lots.
When running the function recursively for
lot_id contained in produce_line_ids the same lot
can be reached multiple times.
In the case of db 40290:
move_380->move_381
move_381 and move_419 both in lot_1320
move_419->move_423
move_423 and move_380 both in lot_567
move_380->move_381
...(goes on forever)
Solution:
Use a lot_path optionnal argument to test if
a lot has already been visited.
Full Traceback:
```
Traceback (most recent call last):
File "/tmp/tmp81rzi7n7/migrations/testing.py", line 208, in test_check
self.check(value)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 85, in check
self.assertFalse(diff, msg)
AssertionError: [('stock.menu_action_production_lot_form', 195, 'Inventory > Master Data > Lots/Serial Numbers', 310), ('mrp.menu_mrp_traceability', 258, 'Manufacturing > Products > Lots/Serial Numbers', 310)] is not false : At least one menu or view working before upgrade is not working after upgrade.
('stock.menu_action_production_lot_form', 195, 'Inventory > Master Data > Lots/Serial Numbers', 310):
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 879, in get
return field_cache[record._ids[0]]
KeyError: 567
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 882, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'stock.production.lot(567,).delivery_count'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 182, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 293, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 319, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3227, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3247, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 5867, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1106, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1265, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 122, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot()
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
[Previous line repeated 926 more times]
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 197, in _find_delivery_ids_by_lot
move_lines = self.env['stock.move.line'].search(domain)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 1810, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4682, in _search
query = self._where_calc(args)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4438, in _where_calc
return expression.expression(domain, self).query
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 442, in __init__
self.parse()
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 701, in parse
right_ids = comodel.with_context(active_test=False)._search([(path[1], operator, right)], order='id')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4683, in _search
self._apply_ir_rules(query, 'read')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4464, in _apply_ir_rules
expression.expression(domain, self.sudo(), self._table, query)
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 442, in __init__
self.parse()
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 701, in parse
right_ids = comodel.with_context(active_test=False)._search([(path[1], operator, right)], order='id')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4682, in _search
query = self._where_calc(args)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4438, in _where_calc
return expression.expression(domain, self).query
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 431, in __init__
self._unaccent = get_unaccent_wrapper(model._cr)
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 405, in get_unaccent_wrapper
if odoo.registry(cr.dbname).has_unaccent:
File "/home/odoo/src/odoo/15.0/odoo/__init__.py", line 104, in registry
return modules.registry.Registry(database_name)
File "/home/odoo/src/odoo/15.0/odoo/modules/registry.py", line 61, in __new__
return cls.registries[db_name]
File "/home/odoo/src/odoo/15.0/odoo/tools/func.py", line 71, in wrapper
return func(self, *args, **kwargs)
RecursionError: maximum recursion depth exceeded
('mrp.menu_mrp_traceability', 258, 'Manufacturing > Products > Lots/Serial Numbers', 310):
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 879, in get
return field_cache[record._ids[0]]
KeyError: 567
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 882, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'stock.production.lot(567,).delivery_count'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 182, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 293, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 319, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3227, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3247, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 5867, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1106, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1265, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 122, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot()
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
[Previous line repeated 926 more times]
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 197, in _find_delivery_ids_by_lot
move_lines = self.env['stock.move.line'].search(domain)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 1810, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4682, in _search
query = self._where_calc(args)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4438, in _where_calc
return expression.expression(domain, self).query
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 442, in __init__
self.parse()
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 701, in parse
right_ids = comodel.with_context(active_test=False)._search([(path[1], operator, right)], order='id')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4683, in _search
self._apply_ir_rules(query, 'read')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4464, in _apply_ir_rules
expression.expression(domain, self.sudo(), self._table, query)
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 442, in __init__
self.parse()
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 701, in parse
right_ids = comodel.with_context(active_test=False)._search([(path[1], operator, right)], order='id')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4682, in _search
query = self._where_calc(args)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4438, in _where_calc
return expression.expression(domain, self).query
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 431, in __init__
self._unaccent = get_unaccent_wrapper(model._cr)
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 405, in get_unaccent_wrapper
if odoo.registry(cr.dbname).has_unaccent:
File "/home/odoo/src/odoo/15.0/odoo/__init__.py", line 104, in registry
return modules.registry.Registry(database_name)
File "/home/odoo/src/odoo/15.0/odoo/modules/registry.py", line 61, in __new__
return cls.registries[db_name]
File "/home/odoo/src/odoo/15.0/odoo/tools/func.py", line 71, in wrapper
return func(self, *args, **kwargs)
RecursionError: maximum recursion depth exceeded
```
closesodoo/odoo#80606
X-original-commit: acceb903b0487987edd5da9ce343c0f6c3ff44d8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Clean the code for onchange method with putaway rule applied, merge
them into one onchange method.
Task-2614519
closesodoo/odoo#80519
X-original-commit: 5f562895c4d2f9beac7e0458fcee493b0141f1af
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
When applying putaway rules, the qty of all existing assigned SM lines are
summed to calculate the incoming qty of the product to determine if the
capacity has been or will be met. When a SM - that a putaway rule will apply
to - is created, then it will have its SM lines included in this calculation when
it shouldn't. In this case, we need to ignore the qty of those lines
Task-2614519
X-original-commit: 14738c7e5ecfba81e7ccbd401e1204d3bac960aa
Part-of: odoo/odoo#80519
Now when apply putaway rule on a package with package type, we calculate
the weight of the package according to the product in that package
instead of using the max weight of the package type.
Task-2614519
X-original-commit: 0281ebec36dbb9effd3d2913c0d38c88f9f19920
Part-of: odoo/odoo#80519
Package won't have a company_id untill the move is validated.
Previously, the package_type_id on package has the check_company to be
true. This forbiden any package type with company_id to be used on a not
validated package. In this commit, we remove check_company to avoid
this.
Task-2614519
X-original-commit: 66cbccb15368713ef04d2ba0f9e8808b72557b41
Part-of: odoo/odoo#80519
Previously when apply putaway rule, we only count the packages in the
location to check if there is enough space the incoming package. Now we
also count all other assigned incoming packages to that location to
avoid overflow.
Task-2614519
X-original-commit: 21373dbc507e57c3a19b415583a5b0595a66c1a3
Part-of: odoo/odoo#80519
When apply a putaway rule to find a putaway location, we only pass the
product and/or package info to _get_putaway_location. This is not
enough since the putaway rule can also be applied to packaging.
X-original-commit: 9f339938aec075c5385dca349dfc6a7c2d43b6ad
Part-of: odoo/odoo#80519
Put in Pack won't trigger any onchange to use putaway rules. In this
commit, we apply putaway rule in Put in Pack when only one move line
is put in pack. We also check if the ml to put in pack are all in same
package type, if so, we set that package type on the package.
Task-2614519
X-original-commit: 023b69ac2ccac2456bcb1a8b1b66b468e213b86a
Part-of: odoo/odoo#80519
When find putaway location while creating new sml, we didn't consider
the package. Add it back.
Task-2614519
X-original-commit: fcbd4c775248f18c71f9cb0e700ed9934babcdfd
Part-of: odoo/odoo#80519
Previously when the onchange method find a putaway location for a sml, we
find a putaway location of the location_dest on the sml. However, the
location may already be a result of last computation of putaway
location. In this commit, we always find putaway location of the default
destination location.
Task-2614519
X-original-commit: a96fb8e9d2a57b67666ca3b29c9313aba83cdb91
Part-of: odoo/odoo#80519
- Renames "DHL"/"DHL USA Connector" into "DHL Express Connector";
- Changes the orderpoint's constraint message when the user's trying to
create an orderpoint who already exists.
task-2581265
Part-of: odoo/odoo#74695
Before this commit, Reservation Method in `stock.picking.type` form view
was visible for the PoS Orders' Operation type which should not be
visible. So, reservation method will now be invisible in this case.
task-2581265
Part-of: odoo/odoo#74695
Issue, to reproduce:
- Create a product A tracked by serial
- Reciept one product A with a lot without digit
- validate this receipt, Ok
- Create a other receipt for product A,
- You cannot anymore open the detail wizard to enter a
SN/lot : get 'The lot name must contain at least one digit.'
Fix:
Remove the constraint and fallback by adding "0" at the end.
task-2652292
closesodoo/odoo#80104
X-original-commit: 5f75d5b1c8d5d4f37cbdc34daa79514226a17855
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
The packages reservations are not correctly done in case of a backorder
To reproduce the issue:
(Use demo data)
1. In Settings, enable:
- Delivery Packages
- Multi-Step Routes
2. Edit the warehouse:
- Outgoing Shipments: 2 steps
3. In Operations Types > Delivery Order, enable:
- Show Detailed Operations
- Move Entire Packages
4. Create a Pick P:
- 1 x [DESK0004] Desk
- 1 x Large Cabinet
5. Put each product in a separate pack
6. Validate P
7. Create a Delivery Order (Planned Transfer):
- 1 x [DESK0004] Desk
- 1 x Large Cabinet
8. Mark as TODO, Check Availability
9. In Detailed Operations, mark one of the packs as Done
10. Validate the DO, Create a backorder
Error: The not-yet-done pack is still on the delivery order and its
status is "Reserved". This line shouldn't be present anymore. Moreover,
the backorder has a line for this pack, its state is "Draft" (instead of
"Reserved") and the state of the BO is Ready.
When creating the backorder, the packages levels of the not-yet-done
moves are transferred to the new picking (i.e., the backorder) However,
these moves does not have a package level defined (due to
9d758fa2e1). Therefore, when checking the
packs:
https://github.com/odoo/odoo/blob/e7450bee8f018a5334d9628235824f2fc6f32cec/addons/stock/models/stock_picking.py#L822-L832
`package_level_ids` is empty, so a new `stock.package_level` is created
(instead of using the one of the initial delivery order). And
`move_lines_to_pack` is empty too, so the new `stock.package_level`
won't have any move lines and its state will be "Draft"
We should rather transfer the package levels of the moves' lines.
OPW-2659176
closes#77509closesodoo/odoo#80072
X-original-commit: 4fd5cd6f940575090021dedd2159d050b594dd69
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Steps to reproduce the bug:
- Connect as Admin and select “My Company (San Francisco)”
- Create a storable product “P1” and select “My Company (San Francisco)” in the `”company”` field
- Go to inventory settings and enable the “Storage Categories” option
- Create a new “Storage Categorie” > select “My Company (San Francisco)” in the `”company”` field > save
BUG1: Edit and try to add the product “P1” > Edit and try to add the product “P1”
> "P1" is not filtered correctly with domain, because the `”company”` field of the `"stock.storage.category.capacity"` model is not set.
As it's a related field, the “default_company_id” should be in the context so that the “company_id” field will be correctly set with this value
BUG2: Add a new line > create and edit a new product > the product type is “consumable” instead of storable, so we should add the type in the context
BUG3: Add multi-company security rule
opw-2689426
closesodoo/odoo#80061
X-original-commit: f5554fa94d41d7eae62c4a1271e41012178c4d8f
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When a backorder is created, the quantities are not reserved. This is an
issue: the module should try to directly assign these quantities if the
reservation method of the associated operation type is "At Confirmation"
(Forward port of 723d4b35f9fa9c49249c1b4e9b8dc93e51c5d359)
OPW-2658469
closesodoo/odoo#79980
X-original-commit: ae19ae04192d21ad956af05e5739bde8c6bca746
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When changing any option in Settings, the option "Show Detailed
Operations" of almost all operations types will be enabled
To reproduce the issue:
(Use demo data)
1. Open the Operation Type "YourCompany: Delivery Orders" and ensure
"Show Detailed Operations" is unchecked
2. In Settings, enable an option (e.g., "Default Access Rights")
3. Go back to the form of "YourCompany: Delivery Orders"
Error: "Show Detailed Operations" is checked for no reason
With this commit, "Show Detailed Operations" of almost all operations
types will be directly enabled only if one of the three options (Lots &
Serial Numbers, Storage Locations or Packages) is enabled and none of
these options was enabled before.
OPW-2514993
closesodoo/odoo#79843
X-original-commit: 5b165dee6dd61b9d681b0e7ba2bc339edb30c83b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Remove the Purchase Security Lead Time from the computing of the
purchase order's picking deadline to better reflect that the shipment is
actually meant to arrive earlier than date + security lead time.
Also makes sure that receipts and subsequent pickings (multi-step
reception) are planned the earliest possible, not taking the purchase
security lead time into account.
Task-2656397
Part-of: odoo/odoo#79523
Fix the inconsistency of product_{min,max}_qty in orderpoint. Both have
different tooltip saying that the reordering rule would trigger if :
- min: forecasted_qty <= product_min_qty
- max: forecasted_qty < product_min_qty
As the tooltip of the product_max_qty is in fact correct, we adapt the
tooltip of the product_min_qty to match the reality.
Task-2656397
Part-of: odoo/odoo#79523
Previously this setting was an application setting which meant the
report could auto-open at undesired times (e.g. internal picking when
multi-step). Instead we make it more flexible for the user's desires by
moving it to the picking type setting.
Part of Task: 2632884
Upgrade PR: odoo/upgrade#2815
Part-of: odoo/odoo#76147
Currently, the order of transfer lines makes no sense for a picker
(it's in the order of the creation of the line). We want to have the
lines of the detailed operation in the same order as the picker will be
picking the products, so we order by source location, destination
location, sequence, and then by id (i.e. creation time) respectively
instead.
Also the printing report of the batch transfer is on too many pages,
it's one page by location, but we always group on 'from location'.
So it would be better not to split by location and keep the report
on the least number of pages possible.
task-2496324
odoo/enterprise#21921closesodoo/odoo#79446
X-original-commit: 9b120caa2a5cd5e2487d663a180b486b5bdb201b
Related: odoo/enterprise#22144
Signed-off-by: Tiffany Chang <tic@odoo.com>
Simplify user workflow by not showing the "Allocation" button in the
(batch) picking form view if there is nothing to allocate (i.e. when
reception report is enabled).
Also:
- fix the location search condition for the outgoing moves that can
be allocated to (i.e. the same logic used in show_allocation field
compute logic is also used in reception report generation/auto-opening)
- replace ['stock.location'].search() with ._search() for better
performance.
Part of Task: 2632884
ENT PR (for barcode equivalent): odoo/enterprise#20805
X-original-commit: 11ffb85fe7398854e4aefa4f9d0cfbc3b88aad8a
Part-of: odoo/odoo#79408
- When locations are activated, fix not being able to add a quant for tracked products just after
creating one from the 'update quantity' window due to Inventory Adjustment location being auto-selected [since it is the last quant]
- Fix quant not properly making fields invisible after confirming from the stock track
confirmation window
closesodoo/odoo#79338
Pr: https://github.com/odoo/odoo/pull/78768
Task-id: 2674732
X-original-commit: ff26704e7afaa537530c0e092a88b73ee791775f
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: npi-odoo <npi@odoo.com>
Previous task: odoo/odoo#61287 improved warnings for when using a
duplicate SN, including an auto-update of the source location when
appropriate. Unfortunately the auto-update is too risky when registering
a subcontracting SN tracked components.
Instead, we no longer update the source location when in a
subcontracting situation and update the warning message to match the
expected flow to fix the issue.
closesodoo/odoo#79334
Task: 2669180
X-original-commit: a430c4d7d6e2a02ef9b3905b554a779fc1643bcf
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, the Replenishment orderpoints `qty_to_order` are
computed according to a precise forecast which take the time in count.
For example, if you plan a consumption for a product with a purchase
lead time of 2 days for the 2021-12-12 at 12:30, if the current date is
2021-12-10, the orderpoint for this product will have a quantity to
order once the hour is meet too but not before. With this commit, it
will take the forecast for the day regardless the time.
task-2652920
closesodoo/odoo#78712
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>
