Steps to reproduce:
-------------------
1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24.
2. Post the move, the deferred entries are created
3. Set the All User Lock Date to 31/12/23
4. Reset the move to draft

- The deferral moves of 2024 are deleted.
- The deferral moves of 2023 are still linked to the move
- The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date)

5. Post the move again

A traceback is raised because of an assert that verifies that we shouldn't regenerate deferral entries if a move already has them.

Solution:
---------
1. The generated reversal of the deferrals of 2023 should be linked to the move.
2. Now that this is done, we can remove the assert because all deferral entries will cancel out each other (i.e. the aggregation will result in no deferral entries).
3. When reverting, we will now use the accounting date instead of the first day after the lock date (if there is one)

opw-3861179

https://github.com/odoo/enterprise/pull/61928

### Steps to reproduce:
- Enable multi-step routes in the settings
- Go to Invertory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a product: - Routes: MTO + Buy route - Variants: Color > Black, White
- In the purchase tab of the product create two lines with: - Vendor 1 sells the Black variant - Vendor 2 sells the White variant
- Create and confirm a sale order with 2 lines: - 1 x Black variant - 1 x White variant

### Expected behavior:

Two purchase order should be created:

- 1 x Black variant sold by Vendor 1
- 1 x White variant sold by Vendor 2

### Current behavior:

Only one purchase order is created so that Vendor 1 as the seller of both procurements even thought vendor 2 is the only real potential seller of the white variant.

### Cause of the issue:

Running the procurements of both lines of the Sale order will trigger the `_run_buy` method which will determine the seller by "default": https://github.com/odoo/odoo/blob/3383d5bd68bfc13b7881f72e5adbb7c27a6df30e/addons/purchase_stock/models/stock_rule.py#L70-L72 using the `_prepare_sellers` method. However, it relies solely on the `seller_ids` field of the `product.template` model https://github.com/odoo/odoo/blob/3383d5bd68bfc13b7881f72e5adbb7c27a6df30e/addons/product/models/product_product.py#L633-L634 Since both variants have the same template they will therefore both be associated with the same default seller.

opw-3940786
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Current behavior:**
Having a storage location with a storage category that has a max quantity acting on some productA, and a putaway rule that will move product from an intermediary location to the location with the category:

Creating a move for productA into the intermediary location that won't hit the cap applied on the second location, then creating an additional move (separate picking) with a demand that exceeds the cap will result in the cap not getting respected during the quant move process.

**Expected behavior:**
The second move will not get assigned via putaway rule to the second location, as its quantity is too large.

**Steps to reproduce:**
1. Create a storage category with a capacity: `product: productA` `quantity: 5`

2. Create an internal location: `parent location: WH/STOCK` `storage category: from step 1`

3. Create a putaway rule: `product: productA` `src location: WH/STOCK` `dest location: from step 2` `storage category: from step1`

4. Create a receipt picking with a move for productA that will not exceed the storage categ. cap -> confirm the picking

5. Create another receipt picking with a move for productA that exceeds the storage categ. cap -> confirm -> fill out the quantity -> validate

6. Go to the storage location and view its quants, see it's more than the max capacity

**Cause of the issue:**
During the picking assignment, the current/pending quantity of the proposed location gets calculated. Prior to the 7dda6bb refactor on the `qty_done` field, this current/pending quantity was stored in the method in a local variable, coincidentally also called qty_done. It got changed to quantity in this commit, which is also the name of one of the method arguments that represents the quantity value of the current move line which is being validated.

Thus, the incoming quantity becomes the current quantity in the location which, of course, does not validate the defined cap.

**Fix:**
Rename the local variable.

opw-3926597

**Steps to reproduce the bug:**
- Create a consumable product “Kit 1” with the following BoM:
    - component: X1

- Create a repair order to repair one unit of Kit 1:
    - Don’t add any part
    - confirm and Start the repair
    - try to end the repair

**Problem:**
A traceback is triggered:
“raise ValueError("Expected singleton: %s" % self)
Value Error: Expected singleton: stock.location()
“

When the "action_repair_end" is called, a move is created with the kit
product, and then we attempt to confirm it:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L80

Since the product is a kit, it is exploded into two moves with products
“X1” and “X2”. We then try to assign them a “repair” picking_type_id:

https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L74

So, the write method is used and since the “picking_type_id” is in the
vals, and the product in the move (X1) is not the same as the one in the
repair order, we consider this product a “Part” of the repair.
Therefore, we try to use its location_id and location_dest_id, which we
fetch based on the “repair_line_type” that will be False because it is
not a part of the repair but rather the product to be repaired:

https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L93-L94

The first error is triggered during the “should_by_pass” check because
there is no location set in the move:
https://github.com/odoo/odoo/blob/c7b947364d34cc6ccfb1eb7a2c16b6bba226d8e7/addons/stock/models/stock_move.py#L1051-L1052

If we fix this error, we will still encounter an error because both
moves will be confirmed. However, we will return to the first loop to
continue calling the “_trigger_scheduler” function for the first move
with the “Kit” product, which will be already deleted because it was
exploded, resulting in a user error:

“odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: stock.move(253,), User: 1)
“

opw-[3942297](https://www.odoo.com/web#id=3942297&view_type=form&model=project.task)

### Steps to reproduce the issue:

1. Create a product with a purchase price and a sales price
2. Create an invoice with the product
3. Create a credit note with the product
4. Go to Invoice Analysis (Pivot view)
5. Tick the margin option in Measures
6. Set the filters to only have the invoice and the credit note in the analysis
7. The margin is positive while the total is null

### Explanation:

The calculation of `price_margin` in `account.invoice.report` is set to 0 if `move_type` is different from `'out_invoice'` or `'out_receipt'`.
Credit notes are categorized as `'out_refund'`.
https://github.com/odoo/odoo/blob/4c8f7c90119caa8fd0d74eb14c4b3496165d4286/addons/account/report/account_invoice_report.py#L109-L112

### Suggested fix:

The credit note and the invoice's margins should cancel each other.
The current calculation of `price_margin` is subtracting `product.product.standard_price` from `account.move.line.balance` regardless of its value which could be negative, as in the case of `'out_refund'` type `account.move`, thus adapating the value using the sign of line.balance.

opw-3862493

Summary
-----
When creating an expense in a currency different from the company's currency, the exchange rate is rounded to 6 decimal places. If the rate and the expense amount are high enough, the rounding error affects the expense amount in the company's currency and later, in the journal entries created after the expense is approved.

Steps to Reproduce
-----
    1. Set a strong currency for the company (e.g., USD)
    2. Add a weak currency in the currencies (e.g., IQD)
    3. Create an expense with a high amount (e.g., 1,000,000 for the IQD/USD pair)
    4. Set the weak currency for the expense
    5. Observe the overly rounded amount in the weak currency

Cause
-----
The error comes from the exchange rate being rounded too much and too early.

Fix
-----
Modify "digits" attribute of the "currency_rate" field to increase precision.

Note
-----
Some inaccuracy remains, but expenses rarely exceed 1000 USD for companies using weak currencies, so the number of issues should be reduced.

opw-3684727

When user tries to close chat window  when current channels/members
 are deleted.

Steps to reproduce error:
- Activate 'im_livechat' and 'website' module
- Open the 'website' module and clicked Contact us menu
- Open chat-bot and start conversation
- Duplicate the tab and Go to the Settings>Technical>Channels/Members in second tab
- Delete the current channels/members from second tab
- Go to the first tab and close chat window
- Error will be generated

sentry traceback-

```ValueError: not enough values to unpack (expected 1, got 0)
  File "odoo/models.py", line 5830, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: discuss.channel.member()
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/mail/models/discuss/mail_guest.py", line 40, in wrapper
    return func(self, *args, **kwargs)
  File "addons/im_livechat/controllers/main.py", line 286, in visitor_leave_session
    member.sudo()._rtc_leave_call()
  File "addons/mail/models/discuss/discuss_channel_member.py", line 297, in _rtc_leave_call
    self.ensure_one()
  File "odoo/models.py", line 5833, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

Here at [1] member got empty value when current channels/members  are deleted from  'discuss.channel.member' model by user.

This commit resolved the above issue by calling  '_rtc_leave_call()' method when a member is available.

[1]-https://github.com/odoo/odoo/blob/952ebac37dc65b3fd62ae211cee1fd45fa63cd47/addons/im_livechat/controllers/main.py#L284-L286

sentry-4719812967






---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce:
-------------------
1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24.
2. Post the move, the deferred entries are created
3. Set the All User Lock Date to 31/12/23
4. Reset the move to draft

- The deferral moves of 2024 are deleted.
- The deferral moves of 2023 are still linked to the move
- The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date)

5. Post the move again

A traceback is raised because of an assert that verifies that we shouldn't regenerate deferral entries if a move already has them.

Solution:
---------
1. The generated reversal of the deferrals of 2023 should be linked to the move.
2. Now that this is done, we can remove the assert because all deferral entries will cancel out each other (i.e. the aggregation will result in no deferral entries).
3. When reverting, we will now use the accounting date instead of the first day after the lock date (if there is one)

opw-3861179

https://github.com/odoo/odoo/pull/164316

**Current behavior:**
A picking with a move for a product with kit BOM that also has some product packaging can be un-openable in Barcode.

**Expected behavior:**
Any picking should be able to be processed in Barcode.

**Steps to reproduce:**
*Enable product packagings*

1. Create a storable product with a kit BOM and a product packaging

2. Make some picking that has a move for the new product, confirm it so the moves for the kit components are created

3. Add stock move lines for each of the moves, fill out their `qty_done` field with the required amount

4. Save the picking record, go into Barcode

5. Try to open the picking -> trace back

**Cause of the issue:**
The Barcode client tries to read the package record of the BOM product/product template but it was never fetched into the barcode cache.

**Fix:**
Ensure any packaging record that could have an attempted access is fetched by the barcode client `onWillStart()`.

opw-3895426

Forward-Port-Of: odoo/enterprise#64750
Forward-Port-Of: odoo/enterprise#64024

**Steps to reproduce:**
	- Install Rental module
	- Check gantt view in Rental > Schedule

**Current behavior before PR:**
We are just showing the products that has orders. This is happening because in those commit https://github.com/odoo/enterprise/pull/37757/commits/0c2f235d4876467df287f30ab3cb09785603cd7f https://github.com/odoo/enterprise/pull/37757/commits/836909419893b522890776d3ec2f16476ae21108 we introduced the group limit and get_gantt_data and rental_schedule has not get adapted with this new behaviour.

So what is happening is that '_read_group_product_ids'
https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule.py#L20
is not called as there is a limit so https://github.com/odoo/enterprise/blob/17.0/web_gantt/models/models.py#L76 This computes to be False so https://github.com/odoo/odoo/blob/17.0/odoo/models.py#L2745:L2754 '_read_group_fill_results' will not get called to call '_read_group_product_ids'

**Desired behavior after PR is merged:**
After override 'get_gantt_data' we are now checking if all products count is more than the limit we just return the products that already have orders.

**Other solution:**
We might just remove the group_limit https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule_views.xml#L54 and just go with the '_read_group_product_ids'.

opw-3959031

**Steps to reproduce:**
- Install l10n_es_reports
- Switch to a Spanish company (e.g. ES Company)
- Create some invoices/bills and credit notes using different types of taxes
- Go to "Accounting / Reporting / Statement Reports / Tax Report"
- Select "Generic Tax Report"
- Click on "VAT Record Books (XLSX)" to download the report

**Issues:**
1) Credit notes appear as positive in the report
2) Withholding taxes (having type "Retencion") are not handled.
They should appear in the dedicated column.
3) Intra-European bills have a tax that is reverted. So the tax amount
should be 0, but it is not reverted in the report.
4) If an invoice has 2 lines that use 2 different taxes of type
"Recargo de Equivalencia", one of them will not appear in the report.
5) Advanced combinations of taxes on several invoice lines are not supported.

**Solution:**
This fix changes the way of generating the Libros Registro de IVA report.
Before this fix, the report was generated based on the tax lines.
One line of the report was corresponding to a regular tax line, which didn't
support advanced combinations of taxes on several invoice lines.
This fix analyzes the taxes repartition on the invoice lines and tries to respect it when generating the report.
A line of the report corresponds to a combination of taxes of different type:
(IVA + surcharge tax + withholding tax)

**Limitation:**
Having 2 taxes of the same type on the same invoice line is not supported.
The total and the tax amount will be correct but not the tax rate because
a report line has only one column to display each type of tax.

opw-3844967

Versions
--------
- 15.0+

Steps
-----
1. Sync with Google Calendar;
2. create a recurrent all day event in google calendar;
3. make sure it shows as "busy";
4. make an appointment via website on that day.

Issue
-----
You are allowed to make an appointment on slots that overlap the synced event.

Cause
-----
Recurrent day events synced via Google Calendar have their start & end date equal to each other, so the event's "end date" could be 24 hours before the actual end.

Commit ad4219876cee4f4b996a7cc72fd176b51be3a063 added an the `_slot_availability_prepare_values_meetings` method, optimized to not include conditions on `start_date` and `allday`. Instead, it filters event by date ranges.

In our scenario, an `allday` event with start & end dates set to something like `2022-02-14 00:00:00`, may get excluded from the search when this is also the value of the starting point of the search, due to `stop` not being strictly greater than the starting point.

Solution
--------
Do an inclusive range search instead of an exclusive one.

opw-3793009

Forward-Port-Of: odoo/enterprise#65023
Forward-Port-Of: odoo/enterprise#63761

To reproduce:
- Create an asset linear yearly.
- Reevaluate it next month, while decreasing the residual amount. 

=> The amounts don't make sense, the decrease move has been deleted.
     Idem for the move before the reeval.

The issue is that we delete all the moves that are draft. 
But if a move (like the decrease move) is created after the current day, 
it is in auto-post, and so, in draft.

To correct that, we prevent their deletion and give the correct residual amount 
(it is a computed non-stored field, so it has been given as an argument to the method).Another issue was found, related to already depreciated assets.
Create an asset with 10000 as original value, 4000 as Import amount
and 6000 as salvage value.
Confirm it (no moves should be created)
Sell or dispose it.

=> It creates a move before disposal while there shouldn't be any

The issue was that reevaluation didn't work with already depreciated assets and with no moves before the reevaluation.

opw-3945341

task-3444716

Forward-Port-Of: odoo/enterprise#65031
Forward-Port-Of: odoo/enterprise#62982