### Steps to Reproduce:
1. Have a product where Track Inventory is enabled and the product category is FIFO and Perpetual
2. Create a PO for the product
3. Validate the receipt
4. Update the quantity on the PO to 0
5. Create Accrued Expense Entry > Traceback

### Description of the issue/feature this PR addresses: 
**Issue:** Currently when generating an Accrued Expense Entry for a PO where quantity on the line is updated to 0, the system crashes with an RPC error. This happens because reducing the line quantity to 0 sets the overall order amount to 0.0. Then. when the accrued orders wizard tries to calculate line-item ratios, it triggers a `ZeroDivisionError`.

**Solution:** We can add a zero-check fallback condition when computing the line ratio inside `_compute_move_vals` in the
`AccountAccruedOrdersWizard` class. The ratio calculation now defaults to 0.0 if the order total is zero, preventing division by zero.

### Current behavior before PR: 
Triggering the Accrued Expense Entry wizard on a PO with a changed quantity of 0.0 causes a `ZeroDivisionError` server error. The user receives an RPC error dialog and cannot proceed with creating the journal entry.

### Desired behavior after PR: 
The wizard should be able to process Purchase Orders with a line quantity of 0 without throwing an RPC error. The system should now cleanly generate the accrual entry based on received quantities.

opw-6459403

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

Forward-Port-Of: odoo/odoo#281808

### Issue:
`test_19_website_page_options` and `test_32_website_background_colorpicker` fail intermittently on RunBot on the "Click Edit" tour step:
FAILED: [27/43] Tour website_background_colorpicker → Step <b>Click Edit</b> to start designing your homepage. (trigger: body .o_menu_systray .o_menu_systray_item.o_edit_website_container button)
Element (body .o_menu_systray .o_menu_systray_item.o_edit_website_container button) has not been found.
TIMEOUT step failed to complete within 10000 ms.
The whole website systray (Edit, Publish, mobile preview, ...) disappears permanently after a save, with no way to bring it back

### Cause:
https://github.com/odoo/odoo/blob/68066eaf3505bbf9ccaf60069072b9a62a49d4e4/addons/website/static/src/client_actions/website_preview/website_builder_action.js#L178-L207
1. Entering edit mode schedules a 200ms delayed removal of `website.WebsiteSystrayItem` from the systray registry to avoid a visual pop during the navbar hide animation
2. Leaving edit mode re-adds the entry only if not already present
3. If a full edit -> save cycle completes in under 200ms, the timer from step 1 is still pending when step 2 runs
The re-add is skipped since the entry still looks present
4. The stale timer fires and removes the entry permanently
Nothing re-adds it until the next edit-mode transition, which requires clicking the button that just disappeared

runbot-240723

Forward-Port-Of: odoo/odoo#280064

Currently, an error occurs when a user opens the calendar.

Steps to Reproduce:
 - Install the `hr_calendar` module.
 - Go to `Employees` and create an `employee`.
 - Under the `Settings tab`, set the employee's `user` to `Administrator`.
 - Create a `new company` and switch to it.
 - Open the `Calendar` and set the `scale` to `Month`.

`TypeError: reduce() of empty iterable with no initial value`

When the user opens the calendar, it fetches the unusual days for the selected attendees. 
By default, the current user's partner is set as an attendee [1]. It then computes the 
schedule for the attendee [2], which returns an empty dictionary [3] because the linked 
employee belongs to a different company than the current company, as restricted by the 
domain [4]. This empty dictionary is then passed to reduce() to intersect the schedules, 
which raises an error because the iterable is empty.

This commit ensures that when no schedule is found for the attendees, an empty set is returned.

[1]: https://github.com/odoo/odoo/blob/658018684d781fef8bf77a77f1e050d1eb16937c/addons/hr_calendar/models/calendar_event.py#L38-L40

[2]: https://github.com/odoo/odoo/blob/658018684d781fef8bf77a77f1e050d1eb16937c/addons/hr_calendar/models/res_partner.py#L123-L130

[3]- https://github.com/odoo/odoo/blob/658018684d781fef8bf77a77f1e050d1eb16937c/addons/hr_calendar/models/res_partner.py#L40-L42

[4]- https://github.com/odoo/odoo/blob/658018684d781fef8bf77a77f1e050d1eb16937c/addons/hr_calendar/models/res_partner.py#L19-L25

sentry-7672490836

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

Forward-Port-Of: odoo/odoo#282866

Current behaviour:
In the Calendar view (day/week/month scale), when the user's timezone observes a DST transition that starts exactly at local midnight (e.g. Africa/Cairo, since 2023), the day column right after the transition gets the wrong weekday name, duplicating the previous day's name. For ex. it renders "... THU THU FRI ..." instead of "... THU FRI SAT ...", for the week surrounding April 30th 2027.

To fix this we add 1 hour to the Date before reading its weekday/day from it, mirroring the workaround FullCalendar itself adopted for this same bug. It has no effect on any ordinary day (adding 1h to a correct local midnight stays within the same calendar day), and it cannot overshoot into the next day since no real-world DST gap exceeds that margin.

Note: This is a known bug (https://github.com/fullcalendar/fullcalendar/issues/7633), fixed in FullCalendar v6.1.17, a major version ahead of the v4.4.0, so the fix can't be applied directly without a full library upgrade.

opw-6370140

Forward-Port-Of: odoo/odoo#280253
Forward-Port-Of: odoo/odoo#279343

**Steps to reproduce:**
  * Set up a French company and configure Peppol E-invoicing.
  * Install `account_edi_ubl_cii` module.
  * Create a company partner (customer) and set a **Reference** value on the company contact under 
     **Customer** -> **Settings** -> **Sales and Purchase**.
  * Create a child contact under that company and set a different Reference value.
  * Create an invoice using the child contact as the invoice partner and confirm the invoice.
  * Send it via Peppol.

**Observed Behaviour:**
  * The BuyerReference in the generated XML contains the reference of the parent
  (commercial partner) Instead of the child contact used on the invoice.

**Cause:**
  * The buyer reference was taken from the commercial partner instead of the
  invoice partner.

**Fix:**
  * Update the condition to use the invoice partner's reference when available;
  Otherwise, fall back on the commercial partner's reference.

opw - 6330649

Forward-Port-Of: odoo/odoo#283324
Forward-Port-Of: odoo/odoo#273700

**Steps to reproduce:**
 - Install l10n_din5008 and accountant.
 - Enable Snailmail from Accounting → Settings.
 - Create a German customer (Fiscal Country: Germany).
 - Create and post a customer invoice using the DIN5008 report layout.
 - Select Send by Post.
 - Enable Developer Mode and navigate to `Settings → Technical → Email → Snailmail Letters`.
- Open the generated letter and send it.

**Current behavior:**
The letter fails to be sent to Pingen with the following error: An error occurred when sending the document by post.
Error: ` The attachment of the letter could not be sent. Please check its content and contact the support if the problem persists.`

**Cause:**
For Snailmail documents, Pingen validates that the recipient address is located within the DIN5008 address window. The current l10n_din5008 report renders additional document information instead of the address in the address area, preventing the compliance validation to fail.

**Fix:**
When rendering the report for Snailmail, ensure that only the recipient address is displayed in the DIN5008 address window while suppressing the additional information that would otherwise occupy this area. This preserves the standard DIN5008 layout for regular reports while generating a Snailmail-compliant PDF that passes Pingen’s validation.

**Reference:** [Pignen Recipient Address Validation Rule](https://help.pingen.com/en/fix-and-enhance-letters/issue-with-recipient-address#040201)

Ticket [link](https://www.odoo.com/odoo/project.task/6387869)
opw-6387869

Forward-Port-Of: odoo/odoo#280320

Steps to reproduce
----------------------------------------
1. Install the SMS Marketing module (mass_mailing_sms).
2. Open any SMS Marketing record in the "Sent" or "Sending" stage.
3. Click on the "Insert Field" button.

Observation
----------------------------------------
Traceback Occurs:
```
TypeError: Cannot read properties of null (reading 'getRootNode')
```

Issue
----------------------------------------
The SMS widget displays the "Insert Field" button even when the SMS message
field is readonly. The button relies on the textarea reference to open the
dynamic fields popover, but the textarea is only rendered in editable mode.

The readonly behavior of the text field can be seen here:
https://github.com/odoo/odoo/blob/ccce9fcc79edcfb1f310b49a16de8235d987b74b/addons/web/static/src/views/fields/text/text_field.xml#L5-L7

However, the SMS widget still renders the "Insert Field" button without
checking whether the message field is readonly:
https://github.com/odoo/odoo/blob/ccce9fcc79edcfb1f310b49a16de8235d987b/addons/sms/static/src/components/sms_widget/fields_sms_widget.xml#L6

As a result, clicking the button in readonly mode tries to access an
unavailable textarea reference to open the dynamic fields popover, causing
a traceback.

Solution
----------------------------------------
Hide the "Insert Field" button when the SMS message field is readonly,
preventing the dynamic fields popover from being opened when the textarea
reference is unavailable.

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

Forward-Port-Of: odoo/odoo#283446
Forward-Port-Of: odoo/odoo#282845

Problem: 
When a `table` with a `color`/`backgroundColor` contains a nested `table`, `distributeTableColorsToAllCells` propagates the outer table's color to every `td` in the subtree, including cells belonging to the inner table. The inner table's own color is then discarded since its `td`s already have a value.

Cause: 
`table.querySelectorAll("td")` returns every `td` in the entire subtree, not just the table's own direct cells.

Solution:
Scope the selected `td`s to `td.closest("table") === table`, so a table's color is only distributed to its own cells.

Steps to reproduce:
1. Add a `background-color` to an outer `table`.
2. Nest a `table` with a different `background-color` inside one of its cells.
3. Load/normalize the content in the editor.
4. Observe both tables' cells carry the outer table's color.

opw-6438972

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

Forward-Port-Of: odoo/odoo#283373
Forward-Port-Of: odoo/odoo#281413

Steps to Reproduce:

1. Confirm a Sales Order with one line -> creates delivery P1. Validate P1 with date_done = Day_A.
2. Create an invoice from the SO and post it -> invoice.delivery_date = Day_A.
3. Add a new line to the same SO -> creates delivery P2.
4. Validate P2 with date_done = Day_B, where Day_B is earlier than Day_A.

Issue:
The already-posted invoice's `delivery_date` silently changes from Day_A to Day_B after step 4, even though nobody edited the invoice. This only happens when a delivery validated after posting has an earlier `date_done` than what was already used.

Root Cause:
`account.move.delivery_date (sale_stock)` is computed in `_compute_delivery_date()`, which depends on `sale.order.effective_date.effective_date` is itself computed as the earliest `date_done` among all done, facing deliveries on the order. Neither compute method checks whether the invoice is posted, so validating P2 triggers a chain reaction: the delivery is saved -> the sale order recalculates -> the invoice recalculates -> delivery_date gets overwritten on an already-posted invoice.

`sale_stock` also marks `delivery_date` as protected, but this protection only works when the invoice itself is saved (write/create). Here, the change starts from saving the delivery (stock.picking), which never goes through the invoice's save method, so the protection never kicks in. `delivery_date` is also not on the list of fields Odoo normally blocks from editing after posting.

Fix:
`_compute_delivery_date()` now splits invoices into posted and non-posted before running. Non-posted invoices work exactly as before. Posted invoices are skipped from the sync and simply keep their current value instead of taking the newly calculated one. `sale.order.effective_date` itself is untouched only its effect on an already-posted invoice is blocked.

Result:
Once an invoice is posted, its `delivery_date` now stays fixed no matter what happens with later deliveries on the same sale order. `effective_date` keeps updating normally either way, confirming the fix only affects the invoice. Verified with both a script and a manual UI test.

opw-6409171

Forward-Port-Of: odoo/odoo#283069
Forward-Port-Of: odoo/odoo#280978

**Steps to reproduce:**

-  Install the Serbian EDI module `l10n_rs_edi`.
-  Configure eFaktura credentials on the company.
-  Create and confirm a Serbian customer invoice.
-  Send the invoice to eFaktura.

**Observed Behavior:**

When the eFaktura API returns an HTTP error, Odoo only displays the generic exception generated by `requests`, for example an HTTP 400/500 error.

The actual error information returned by eFaktura in the response body is not shown to the user, making it difficult to understand why the invoice was rejected.

**Cause:**

`_l10n_rs_edi_send` catches `HTTPError`, `Timeout`, and `ConnectionError`, but the error message is built only from the Python exception.

For HTTP errors, the eFaktura API may return a response containing more precise information such as:

```json
{
    ErrorCode: ...,
    Message: ...
}
```

This response was not being used when displaying the error in Odoo.

**Fix:**

When an HTTP response is available and contains an eFaktura error payload, use the returned `ErrorCode` and `Message` as the error displayed on the invoice. Fallback to the existing connection/HTTP exception message when no usable API response is available.

opw - 6453653

Forward-Port-Of: odoo/odoo#281490

Steps to reproduce:
---
- Install `website_sale` module.
- Enable `Product Variants` and `Prevent Sale of Zero Priced Product` in settings.
- Create new attribute > set `Variant Creation` as `Never` and also add value with extra price.
- Create a product with sales price = 0, assign the attribute, and publish it.
- As a public user (incognito), try to add the product to the cart.

Issue:
---
- In terminal error `The given product does not exist therefore it cannot be added to cart` is raised.

Root cause:
---
- In `_is_add_to_cart_allowed()`[1], the method calls `_get_contextual_price()` [2] to check if the product's price is zero when `prevent_zero_price_sale` is enabled.
- However, `_get_contextual_price()` is called without the no-variant attribute values in the context, so it does not account for their `price_extra`. For a product with list price as 0 and attribute with extra price, the price is incorrectly computed as 0, causing `_is_add_to_cart_allowed()` to return `False`.

Solution:
---
- Before calling `_is_add_to_cart_allowed()`, set the product's context with the no-variant attribute values via `_get_product_price_context()`, so that `_get_contextual_price()` correctly includes the price extra in its computation.

[1]https://github.com/odoo/odoo/blob/bbafbbd8950ec7123ab652851ede5479484eee26/addons/website_sale/controllers/cart.py#L117-L120

[2]https://github.com/odoo/odoo/blob/bbafbbd8950ec7123ab652851ede5479484eee26/addons/website_sale/models/product_product.py#L149-L150

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

Forward-Port-Of: odoo/odoo#283217
Forward-Port-Of: odoo/odoo#278620

## Current behavior:
On a Monday–Friday working schedule, a Daily accrual plan that is based on worked time grants accrued time on Saturday as well, even though Saturday is not a working day. The employee accrues on 6 days per week instead of 5 (Sunday is correctly skipped. Only Saturday is wrong).

## Expected behavior:
The employee accrues only on the 5 working days (Mon–Fri) → 5 grants per week. Saturday and Sunday should add nothing.

## Setup:
- Working schedule: Standard 40h/week, Monday–Friday, 08:00–17:00.
- All timezones set to Australia/Brisbane (UTC+10) and matching: employee, working schedule, and user are all the same timezone.
- Accrual plan milestone: accrue 5 Hours, Daily, "At the end of the accrual period", "Based on worked time = Yes".

## Steps to reproduce:
- Create the working schedule and accrual plan above, with the calendar timezone set to Australia/Brisbane.
- Assign the accrual allocation to an employee, Starting on a Monday.
- On the Time Off dashboard, use "Balance at the (date)" to project the balance day by day across a weekend (Friday → Saturday → Sunday → Monday).

## Cause of the issue:
Accrual period boundaries were built as naive UTC midnights instead of local calendar midnights.

## Fix:
Localize accrual period boundaries in the employee/resource timezone before calling resource calendar APIs.

This bug is reproducible in multiple versions. PRs for:
- v19.0: https://github.com/odoo/odoo/pull/279029
- v18.0: https://github.com/odoo/odoo/pull/279036

opw-6316062

Forward-Port-Of: odoo/odoo#283215
Forward-Port-Of: odoo/odoo#279029

Steps to produce:
---
- Install the `Sales` module.
- In Settings, enable `Automatic Invoice`.
- Also enable the Demo payment provider.
- Create a sale order with a total of `800` and confirm it.
- Generate a payment link for `200` from the gear icon and pay it.
- Generate a second payment link for `300` and pay it.
- Generate a final payment link for the remaining `300` and pay it.

Issue:
---
- After the first payment (200), an `invoice of 200` is created. Correct.
- After the second payment (300), an` invoice of 500` is created instead of 300.
- After the third payment (300), an `invoice of 100` is created instead of 300.

Root cause:
---
- The down payment invoice uses `order.amount_paid`, the cumulative sum of all transactions on the order, instead of the amount of the latest payment. This causes invoices to be sized off the running total instead of the individual payment delta.

Fix:
---
- Compute the invoice amount as `order.amount_paid - order.amount_invoiced` (the unpaid) instead of passing the cumulative `amount_paid` directly.

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

Forward-Port-Of: odoo/odoo#283393
Forward-Port-Of: odoo/odoo#273099

Steps to reproduce:
1. Create a button
2. Choose "custom" in type
3. Put a gradient for Fill option
4. Remove border (put 0)

Problem:
Since [this commit][1] support has been added to preview custom buttons with gradient backgrounds in the website builder. However, if a user sets the border to 0px it a false border is shown. This is inconsistent the changes that will be applied to the button on the website. The cause is how the preview border is set. In the same [commit][1], borders are previewed at 2px regardless of their actual size. This works for solid background buttons but causes a gradient pseudo-border to appear with custom gradient buttons.

Solution:
The solution is to set the preview button's border-width styling to 0px in the case when the border is being changed and its width is set to 0. This styling does not affect the classes applied to the actual button being edited and is removed if the border thickness is changed again.

[1]: https://github.com/odoo/odoo/commit/291a77c50f19622f8083a5e3798c17b49f3b1c7e

task-6296905

When updating mail notifications during `mail.mail._send()`,

a `SerializationFailure` raised while flushing the notification recordset leaves the current transaction in an aborted state.

As `_send()` continues handling the exception, accessing fields:
 - https://github.com/odoo/odoo/blob/127f1316540ec6cc6880ea3515e6923ba3903bc7/addons/mail/models/mail_mail.py#L816

So, any subsequent SQL query fails with

`InFailedSqlTransaction`, masking the original concurrency error.

Avoid accesing to `mail.message_id` with aborted cursor, preserving the original `SerializationFailure`.

A regression test is added to simulate a concurrency failure during

`flush_recordset()` and verify that the cursor is no longer used dirty

The logger for the unittest without the fix is the following:

```log
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "odoo/addons/mail/models/mail_mail.py", line 719, in _send
    notifs.flush_recordset(['notification_status', 'failure_type', 'failure_reason'])
  File "<string>", line 3, in flush_recordset
  File "unittest/mock.py", line 1139, in __call__
    return self._mock_call(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "unittest/mock.py", line 1143, in _mock_call
    return self._execute_mock_call(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "unittest/mock.py", line 1204, in _execute_mock_call
    result = effect(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 93, in mocked_mail_notification_flush_recordset
    return original_flush_recordset(self, *vals, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 6788, in flush_recordset
    self._flush(fnames)
  File "odoo/odoo/models.py", line 6852, in _flush
    model.browse(some_ids)._write_multi(vals_list)
  File "odoo/odoo/models.py", line 4938, in _write_multi
    self.env.execute_query(SQL(
  File "odoo/odoo/api.py", line 993, in execute_query
    self.cr.execute(query)
  File "odoo/odoo/sql_db.py", line 371, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 107, in test_mail_send_dirty_cursor
    mails.send()
  File "odoo/addons/mail/models/mail_mail.py", line 652, in send
    self.browse(batch_ids)._send(
  File "odoo/addons/mail/models/mail_mail.py", line 818, in _send
    mail.id, mail.message_id)
             ^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 1309, in __get__
    self.compute_value(recs)
  File "odoo/odoo/fields.py", line 1491, in compute_value
    records._compute_field_value(self)
  File "odoo/odoo/models.py", line 5302, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/odoo/fields.py", line 113, in determine
    return needle(records, *args)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 710, in _compute_related
    record[self.name] = self._process_related(value[self.related_field.name], record.env)
                                              ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 7083, in __getitem__
    return self._fields[key].__get__(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 1272, in __get__
    recs._fetch_field(self)
  File "odoo/odoo/models.py", line 4120, in _fetch_field
    self.fetch(fnames)
  File "odoo/addons/mail/models/mail_message.py", line 756, in fetch
    return super().fetch(field_names)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 4158, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 4245, in _fetch_query
    rows = self.env.execute_query(query.select(*sql_terms))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/api.py", line 993, in execute_query
    self.cr.execute(query)
  File "odoo/odoo/sql_db.py", line 371, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block
```

Real error in production:

```log
2023-04-15 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_notification" SET "failure_reason" = "__tmp"."failure_reason"::text, "failure_type" = "__tmp"."failure_type"::VARCHAR, "notification_status" = "__tmp"."notification_status"::VARCHAR FROM (VALUES (4426629, 'Error without exception. Probably due to concurrent access update of notification records. Please see with an administrator.', 'unknown', 'exception')) AS "__tmp"("id", "failure_reason", "failure_type", "notification_status") WHERE "mail_notification"."id" = "__tmp"."id" ERROR: could not serialize access due to concurrent update
```

```log
2023-04-14 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_mail" SET "failure_reason"='Error without exception. Probably due do sending an email without computed recipients.',"headers"='{''X-SMTPAPI'': ''{"ip_pool": "Transactional"}'', ''X-Odoo-Objects'': ''sale.order-1436960''}',"state"='exception',"write_uid"=1,"write_date"=(now() at time zone 'UTC') WHERE id IN (2548540)
ERROR: current transaction is aborted, commands ignored until end of transaction block
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:


# UPDATE 2026-07-22

The reviewer requested to remove the large docstring

For record, the docstring was

```python
    """Reproduces a concurrency scenario where `mail_mail._send()` fails with a PSQL SerializationFailure after
        flushing `mail.notification` records. After such a failure, the cursor is left in an aborted
        (`InFailedSqlTransaction`) state, so any further SQL access (e.g. reading `mail.message_id` like
        https://github.com/odoo/odoo/blob/127f1316540ec6cc68/addons/mail/models/mail_mail.py#L816)
        would raise a new error masking the original SerializationFailure.

        Setup:
        - Uses a separate `cursor()` to create and commit a message with its `mail.mail` and `mail.notification`
        records, so they are visible to a second, concurrent transaction.

        Concurrency simulation:
        - `MailNotification.flush_recordset` is patched so that, right before the real flush runs, a second cursor
        updates the same `mail.notification` records (`failure_reason`). This forces PSQL to raise a
        SerializationFailure when the original transaction tries to flush those rows.

        Assertions:
        - `SerializationFailure` is raised confirming the concurrency conflict.
        - `mail_mail._send()` logs the expected error message containing the mail `id` and `message-id`

        Cleanup: created records are unlinked in `finally`
        """
```

# UPDATE 2026-07-23

The reviewer requested to remove the unittest

For record, the unittest was

```diff
diff --git a/addons/test_mail/tests/test_message_post.py b/addons/test_mail/tests/test_message_post.py
index 53dd5b9eec52..46a3958a5bff 100644
--- a/addons/test_mail/tests/test_message_post.py
+++ b/addons/test_mail/tests/test_message_post.py
@@ -7,17 +7,21 @@ from datetime import datetime, timedelta
 from freezegun import freeze_time
 from itertools import product
 from markupsafe import escape, Markup
+from psycopg2.errorcodes import SERIALIZATION_FAILURE as SERIALIZATION_FAILURE_CODE
+from psycopg2.errors import SerializationFailure
 from unittest.mock import patch
 
-from odoo import tools
+from odoo import SUPERUSER_ID, api, tools
 from odoo.addons.base.tests.test_ir_cron import CronMixinCase
-from odoo.addons.mail.tests.common import mail_new_test_user, MailCommon
+from odoo.addons.mail.models.mail_notification import MailNotification
+from odoo.addons.mail.tests.common import mail_new_test_user, MailCommon, MockEmail
 from odoo.addons.test_mail.data.test_mail_data import MAIL_TEMPLATE_PLAINTEXT
 from odoo.addons.test_mail.models.test_mail_models import MailTestSimple
 from odoo.addons.test_mail.tests.common import TestRecipients
 from odoo.api import call_kw
 from odoo.exceptions import AccessError
-from odoo.tests import tagged
+from odoo.modules.registry import Registry
+from odoo.tests import TransactionCase, get_db_name, tagged
 from odoo.tools import mute_logger, formataddr
 from odoo.tests.common import users
 
@@ -2244,3 +2248,49 @@ class TestMessagePostLang(MailCommon, TestRecipients):
                                     self.assertIn('html lang="es_ES"', email['body'])
                                 else:
                                     self.assertIn('html lang="en_US"', email['body'])
+
+
+@tagged('database_breaking')
+class TestMessagePostConcurrent(MockEmail, TransactionCase):
+    """Mail concurrency edge cases that require real, separately committed transactions
+    instead of the usual rollback-based TransactionCase isolation.
+    """
+
+    def test_mail_send_dirty_cursor(self):
+        """Reproduces SerializationFailure `mail_mail._send()` fails,
+        the cursor is left in an aborted state, so any further SQL access would raise a new error
+        (e.g. reading `mail.message_id` like
+        https://github.com/odoo/odoo/blob/127f1316540ec6cc68/addons/mail/models/mail_mail.py#L816)
+        """
+        original_flush_recordset = MailNotification.flush_recordset
+
+        def mocked_mail_notification_flush_recordset(self, *args, **kwargs):
+            with Registry(get_db_name()).cursor() as cr:
+                cr.execute('UPDATE mail_notification SET failure_reason = %s WHERE id IN %s', ('Forced Concurrent Update', tuple(self.ids)))
+            return original_flush_recordset(self, *args, **kwargs)
+
+        recs2unlink = []
+        with Registry(get_db_name()).cursor() as cr:
+            env = api.Environment(cr, SUPERUSER_ID, {})
+            partner = env.ref('base.user_admin').partner_id
+            try:
+                message = partner.message_post(body='Hello', message_type='comment', partner_ids=[partner.id], mail_auto_delete=False, force_send=False)
+                notifs = env['mail.notification'].search([('notification_type', '=', 'email'), ('mail_mail_id', 'in', message.mail_ids.ids)])
+                self.assertTrue(notifs)
+                mails = message.mail_ids
+                recs2unlink.extend([notifs, mails, message])
+                cr.commit()
+
+                mails = self.env[mails._name].browse(mails.ids)
+                with (
+                    mute_logger('odoo.sql_db'), self.assertRaises(SerializationFailure) as exc, self.mock_mail_gateway(),
+                    patch(f'{MailNotification.__module__}.{MailNotification.__name__}.flush_recordset', autospec=True, side_effect=mocked_mail_notification_flush_recordset),
+                    self.assertLogs('odoo.addons.mail.models.mail_mail', level='ERROR') as log_capture,
+                ):
+                    mails.send()
+            finally:
+                for rec2unlink in recs2unlink:
+                    env[rec2unlink._name].browse(rec2unlink.ids).unlink()
+
+            self.assertEqual(exc.exception.pgcode, SERIALIZATION_FAILURE_CODE)
+            self.assertIn(f'Exception while processing mail with ID {mails.id} and Msg-Id \'{mails.message_id}\'.', [record.message for record in log_capture.records])

```

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

Forward-Port-Of: odoo/odoo#279897
Forward-Port-Of: odoo/odoo#274089

Steps to reproduce
==================

- Use a mobile viewport
- Go to planning
- Click on an empty cell
- Click on the date
- On the bottomsheet, click on the time at the bottom
- Try to type 12:34

=> Only 1 is entered and then the start_datetime field is focused behind the bottom sheet

Cause of the issue
==================

The <input type="time"/> listen to the onchange event. We listen to rawPickerProps changes using a reactive call. shouldFocus is then set to true, and the focus is done after the next render.

The onchange event is called at a different time depending on the platform.

On IOS and Firefox desktop: after changing hours or minutes
On Android: once the apply button is clicked
On Chrome desktop: After entering a single char

Solution
========

The bottomsheet is only displayed when env.isSmall && hasTouch(). It doesn't make sense to focus the input, since we don't handle the keyboard in that case.

opw-6386252

Forward-Port-Of: odoo/odoo#276617

Steps to reproduce:
- Enable presets and set a preset carrying a tax-replacing fiscal position (e.g. "Takeout") as the default preset of the POS config
- Take an order with another preset that has no fiscal position (e.g. "Dine In")
- Refund that order from the ticket screen

Issue:
The refund is taxed with the fiscal position of the default preset instead of the one of the refunded order. The ticket screen displays the refund lines with the taxes of the original order, but the refund that is actually created maps them through the wrong fiscal position. With tax-included prices the totals still match on screen, so the operator only sees the discrepancy after going back.

Cause:
The destination order of a refund is an empty order, created with the default preset and therefore with that preset's fiscal position. In TicketScreen.onDoRefund, the fiscal position of the refunded order was only copied onto it when the refunded order had one, so an order taken without a fiscal position kept the default preset's one. When an already existing empty order is reused as destination, whatever fiscal position was last set on it survives for the same reason.

Fix:
Always assign the fiscal position of the refunded order to the destination order, an empty one included, so a refund is taxed exactly like the order it refunds instead of silently switching. The preset itself is left untouched: it drives the ordering workflow (timing slot, customer identification) which must not be imposed on a refund.

opw-6442664

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

Forward-Port-Of: odoo/odoo#281508
Forward-Port-Of: odoo/odoo#280672

### Issue:
When multiple partners share the same email address, `_mail_find_partner_from_emails` may resolve to the wrong partner when the input is a formatted email like "`Name <email>`"

This affects use cases like email templates using `{{object.company_id.email_formatted}}` as sender, where the wrong company partner could be selected

### Cause:
The lookup in `done_partners` only matched on `email_normalized`, which cannot distinguish partners sharing the same email but with different names

The `email_formatted` field carries both name and email, allowing an exact match when the input is a formatted email

### Steps to reproduce:
- Install `account`
- Create an Email Template (Applies to: account.move, From: {{object.company_id.email_formatted}})
- Create a second company B with the same email as the default (e.g. info@yourcompany.com)
- In Settings (logged in as company B), set a Fiscal Position (e.g. US Taxable)
- Create an Invoice on company B
- In the chatter, click Send message, click the expand arrows button, use the three dots menu to select the template
- Send and check the Sender in the chatter

Before the fix, the sender resolves to the default company even though the invoice belongs to company B

opw-6260992

Forward-Port-Of: odoo/odoo#282966
Forward-Port-Of: odoo/odoo#269509

### [FIX] account_reports: snapshotable_engine wrapper with custom engine

The `snapshotable_engine` wrapper assumes that `self` is the report,
but with a custom engine, `self` is the report's custom handler.

Retrieve the report from the options to handle both cases correctly.

### [FIX] account_reports: snapshot always_unfolded groupby lines

The first groupby level of `always_unfolded` line is evaluated on every
rendering of the reports, so it needs to be snapshotted as well.

### [FIX] account_reports: preserve group order and handle None values

Custom engines can return `None` to represent the absence of a value.
Treat these values as `0.0` when rounding grouped results.

Also preserve the order of group keys returned by each term's engine,
as some engines rely on that order for cumulative columns.

### [FIX] account_reports: fix merging snapshot partitions

Merging keys can have mixed types(None, tuple, etc). Comparing None with a string causes a traceback.

This can happen when consolidation is enabled: the account_id groupby is
replaced with account_code. If an account is not mapped to a code,
it returns None, while the accounts having a mapping will return a string.

Comparing these values during the merge causes a traceback.
It will also be useful for a snapshot of the custom engine, which returns the key
as None(e.g. Unknown Partner)

### [FIX] account_reports: invalidate partner-grouped snapshot when merging partners

Merging partners rewrites partner_id on move lines at SQL level, without
any lock date protection.
Snapshots grouped by partner may contain stale results afterwards, and
need to be regenerated.

Forward-Port-Of: odoo/enterprise#128608

**Steps to reproduce:**
* Install the **Accounting** module.
* Create two companies with different currencies (e.g. **USD** and **CAD**) sharing the same **Chart of Accounts**.
* Open a shared account and:
  * Add both companies in the **Company** field.
  * Under the **Mappings** tab, configure a mapping for each company.
* In each company, create and post a journal entry on the same shared account (for example, a receivable account) using the company's own currency.
* Set the journal entry dates to the **current month**.
* Open **Accounting → Reporting → General Ledger**.
* Change the reporting period to the **following month** so the posted entries are shown as the **Initial Balance**.
* Open the report separately for each company.

**Observed behavior:**
* From the **CAD company**, the Initial Balance displays **USD 2,000** instead of the expected **USD 1,000**.
* From the **USD company**, the **Currency** column on the Initial Balance is **blank**.

**Cause:**
* The SQL query for the `id_with_accumulated_balance` groupby used `SUM(amount_currency)` and `MIN(currency_id)` to aggregate all pre-period lines into a single Initial Balance row.
* In a multi-company shared Chart of Accounts, lines from different companies (each with their own currency) were collapsed into the same group, causing `SUM(amount_currency)` to add amounts across currencies and `MIN(currency_id)` to return an arbitrary currency ID.
* Additionally, the Python accumulation loop incorrectly performed **integer addition** on `currency_id` (a foreign key), further corrupting the displayed currency.

**Fix:**
* Replace `SUM(amount_currency)` and `MIN(currency_id)` with `CASE` expressions `MIN = MAX` is a uniformity check that works for **any number of currencies**: if every row in the group shares the same currency the condition is true and the correct sum is returned; if even one row differs the condition is false and both fields return `NULL`. The original three-column `GROUP BY (id, date, account_id)` is preserved.
* The Initial Balance row now correctly shows a **blank** currency column, consistent with the Odoo 18 behavior, instead of an incorrect aggregated foreign currency amount.

opw-6375310

Forward-Port-Of: odoo/enterprise#124823

Currently, an error occurs when orders are being fetched from shops with pending authorization.

Steps to replicate:
- Install `sale_tiktok`.
- Open Sales > Configuration > Shops (Under the title tiktok shops).
- Click `Connect New Shop` > Give values for `App key, App secret, Service ID`.
- Click `Connect Shop & Authorize` and then Return back to Odoo.
- Run the Scheduled Action `TikTok Shop: sync orders`.

Error:
```
File '/home/odoo/src/enterprise/saas-19.4/sale_tiktok/utils.py', line 171, in make_tiktok_api_request
    if now > shop.access_token_expire_datetime - timedelta(minutes=5):
TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'

ValueError: TypeError('unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'') while evaluating
'model._sync_orders()'
```

Cause:
- Since the shop has not yet been authorized with TikTok, the `access_token_expire_datetime` field is not set. This field is only populated after the shop is successfully authorized (see [this]).

- Later, when the `TikTok Shop: sync orders` cron runs, the flow reaches [here], where we checks whether the access token is expired and needs to be refreshed. At this point, `access_token_expire_datetime` is still False because the shop has not been authorized yet.

Solution:
- The orders should only be fetched from those shops that are authorized with TikTok.
- Used the `access_token` field to determine whether a shop is authorized, as it is only populated after the authorization flow is successfully completed.

[this]: https://github.com/odoo/enterprise/blob/593409ca160863d3e985f3cf5e2aadda1d450b41/sale_tiktok/controllers/onboarding.py#L52-L54

[here]: https://github.com/odoo/enterprise/blob/593409ca160863d3e985f3cf5e2aadda1d450b41/sale_tiktok/utils.py#L171

sentry-7631179329

Forward-Port-Of: odoo/enterprise#127148

Creating a batch of payslips mixing employees with and without leave allocations raises a KeyError:
```
  File "l10n_au_hr_payroll/models/hr_payslip.py", line 869, in _add_unused_leaves_to_payslip
    annual_gross = leaves_totals[payslip.id]['annual'] * daily_wage
                   ~~~~~~~~~~~~~^^^^^^^^^^^^
  KeyError: 22
```

Current Issue:
`_l10n_au_get_unused_leave_by_type` only materialises leaves_by_date[payslip.id] inside the allocation loop, so a payslip whose employee has no matching allocation never gets a key. `_l10n_au_get_unused_leave_totals` then rebuilt a plain dict out of those entries and only fell back to a defaultdict when leaves_by_date was completely empty. A mixed batch is not empty, so the plain dict was returned and `_add_unused_leaves_to_payslip` raised on the payslips that were missing from it.

This never showed up in the UI, **where payslips are created one at a time**: a single slip either has an allocation, or produces an empty mapping that hits the fallback.

Approach:
Build the totals on a defaultdict and update it instead of returning a plain dict, so any payslip without allocation resolves to 0 rather than being absent. This also drops the need for the empty special case, and keeps the mapping consistent with the defaultdict returned by `_l10n_au_get_unused_leave_by_type`, which `_l10n_au_get_leaves_for_withhold` indexes the same way.

task-6465229

Forward-Port-Of: odoo/enterprise#127623

### Issue:
When an invoice has an image as its main attachment added via a log note, any non-admin user who did not create the attachment gets an `AccessError` when exporting the Datev ATCH zip

### Cause:
Since commit `e7c93e5a6f`, attachments uploaded via certain flows can be "orphaned" — their `res_model` is set to `False` and `res_id` to `0` via `_fix_attachments_on_record_from_files_data`
This allows the attachment to appear in the chatter without being linked to the move's attachment list

However, `_message_set_main_attachment_id` can still set such an orphaned attachment as `message_main_attachment_id`
When a user without system rights tries to read it, the ORM access check uses `res_model=False` and `res_id=0`, which does not match the move the user has access to, raising an `AccessError`

### Steps to reproduce:
- Install `l10n_de_reports` and switch to the DE company
- Create and confirm an Invoice (any lines, any customer)
- Add a Log Note with an image
- Set Demo user's Accounting rights to `Invoicing & Banks`
- Log in as Demo
- Open the General Ledger
- In the cog menu, choose `Datev ATCH (zip)`

Before the fix, an `AccessError` is raised

opw-6397804

Forward-Port-Of: odoo/enterprise#128484
Forward-Port-Of: odoo/enterprise#127787

When reconciling an internal transfer between a branch and its parent
company, an User Error is raised if the branch transaction has been
processed via reconciliation model.

Steps to reproduce:
- Have a company with branch both selected
- On the branch, create a reconciliation model "Internal transfer" that
  assigns the whole balance to the liquidity transfer account
- Have a Bank journal on the company and a Bank journal on the branch
- On the branch bank journal, create a -100 transaction 'testb' and
  reconcile it using the branch internal transfer model
- On the company bank journal, creata a 100 transaction, open the
  reconciliation widget and select the branch transaction to match it

Issue:
The reconciliation is refused with a company inconsistency error
``` Uh-oh! You’ve got some company inconsistencies here:
- “BNK1/2026/00011 test” belongs to company “YourCompany” while
  “Reconciliation Model” (reconcile_model_id: 'Internal Transfer
  branch') belongs to another company.  To avoid a mess, no company
  crossover is allowed!
```
However, if user manually assign the transfer account to the branch transaction,
the reconciliation proceed as expected

Analysis:

When reconciling, we build the counterpart journal item by cloning the
values of the matched move line, copying also the reconcile model.
That field is company dependent and flagged copy=False, so it should not
be propagated.

opw-6365856

Forward-Port-Of: odoo/enterprise#127517

**Problem:**
The running timesheet timer in the systray stops when the Odoo server clock passes UTC midnight, even though it is still the same day in the user's own timezone.

**Steps to reproduce:**
1. Set the user's timezone to one behind UTC (e.g. America/Guadeloupe, UTC-4).
2. Start a timesheet timer while it is before local midnight but after the server has passed UTC midnight (e.g. 20:00 local = 00:00 UTC).
3. Look at the running timer in the systray.

**Current behavior:**
At server (UTC) midnight the running timer disappears and its ongoing count is lost.

**Expected behavior:**
The timer keeps running until the user's own local midnight, regardless of the server timezone.

**Cause of the issue:**
The systray controller derives its reference day from `date.today()`, which returns the server's (UTC) local date. The running timer's timesheet is created dated the user's local day (`hr_timesheet` uses `fields.Date.context_today`). Once the server crosses UTC midnight, `date.today()` advances to the next day while the user's local day has not, so `timesheet_systray_user_data` (searching `date == today`) and `get_timer_start_time` (searching `date` within today's bounds) no longer match the running timesheet, and the systray reports no running timer.

**Fix:**
Deriving the reference day from `fields.Date.context_today` aligns the systray's notion of "today" with the timezone the timesheet was recorded in, so the timer is tied to the user's local day rather than the server's. This keeps recording and retrieval consistent, since the timesheet is already dated with the user-local day on creation.

opw-6343442

Forward-Port-Of: odoo/enterprise#125635

Peppol documents can be received in a journal or in the Documents app (peppol_reception_mode). Some companies cannot use Documents: _peppol_allows_document_reception() returns False and the journal stays required. This is the case of French companies (via l10n_fr_pdp).

The onchange of the settings and the import did not check this method. So on a French company with the mode set to 'documents':
  - the Settings cleared the journal on each opening, while it was still required
  - the incoming documents were saved in Documents instead of vendor bills

Steps to reproduce:
- Create a Belgian company, with a purchase journal, and register it on Peppol as receiver
- Set the reception mode to "Receive in Documents"
- Change the fiscal position to France, and install l10n_fr_pdp, the Peppol part is replaced by "French Electronic Invoicing", so the radio button is not visible anymore, but the company still has peppol_reception_mode == 'documents'.
- Open the Settings again: the field "Incoming Invoices Journal" is empty.

opw-6429691

Forward-Port-Of: odoo/enterprise#126462

### Issue before this commit:
When generating a SEPA Credit Transfer batch using the German XML format (pain.001.001.03), the <LEI> tag is erroneously included in the exported file if an LEI is configured on the company. This invalidates the XML, causing banks to reject the file.

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Settins > Vendor Payments > SEPA Credit Transfer / ISO20022 and set Name Identification as 529900T8BM49AURSDO55 and Issuer as LEIMAN
3. Go to companies and set 529900T8BM49AURSDO55 as LEI in the DE company
4. Go to Accounting dashboard and click the 3 dots of the bank group, go to Configuration and set the Account Number and be sure in the Outgoing Payments tab XML Format is German
5. Create a new German company from Contacts with:
	1. Country as Germany
	2. VAT
	3. Account Number in the Bank Accounts by adding one line:
		1. example Account Number: DE65100500007201811026
		2. example Bank: BNP Paribas
		3. activate the Send Money button
7. Then go to Vendor > Payments and create a new one with Payment Method as SEPA Credit Transfer for the German company created
8. Go back and select the new payment from the list and click create batch and print it
9. In the XML of pain.001.001.03.(DE) file, the LEI tag should not be included.

### Cause of the issue:
The XML generation logic does not filter out the <LEI> element for older schema versions like pain.001.001.03, which do not support this tag.

### Reason to introduce the fix:
To ensure strict schema compliance and prevent bank rejections. The <LEI> element is now properly omitted from pain.001.001.03 files and restricted only to newer formats (e.g., pain.001.001.09) where it is valid.

opw-6428150

Forward-Port-Of: odoo/enterprise#127758

### Problem
- Fixed salary payslips were not being prorated correctly. The 50% rule threshold was compared against
  `hours_per_week` (single week) instead of 50% of the theoretical hours for the payslip period.
  This led to incorrect salary deductions in all cases and the wrong computation path being taken when less than 
  50% of the month was worked.

### Solution
- Fix `_l10n_be_has_enough_paid_hours` to compare paid hours against 
  50% of theoretical hours instead of `hours_per_week` (which are calculated for the employee's `working schedule`)

### How it works
- For fixed salary (`wage_type = 'monthly'`), the quarterly hourly rule 
  is applied as follows:

- **Hourly rate** = `fixed_salary × 3 / 13 / theoretical_hours`
- **50% rule**:
  - If more than 50% of theoretical hours were worked → deduct absences 
    from fixed wage
  - If less than 50% of theoretical hours were worked → pay only the 
    hours worked

For variable salary (`wage_type = 'hourly'`), the employee is simply 
paid for the number of hours worked during the period.

Task-6260378

Forward-Port-Of: odoo/enterprise#126600

[FIX] l10n_ch: fix default contract type

This task is runbot error fix that occured from 19.0 to 19.2

Bug reproduction:

1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute test_version_timeline_auto_save_tour tour test 3 - It fails in .o_arrow_button_wrapper[data-tooltip^='Contract:'] step

Bug cause:

1 - When l10n_ch_hr_payroll_account is installed:

    1.1 - contract type becomes "Permanent contract with monthly salary"
    1.2 - the employee is not swiss but it has this CH contract type

2 - data-tooltip starts with Permanent contract instead of contract

    2.1 - Tour fails

3 - contract_type_id is overwritten in swiss modules

    3.1 - Default is assigned without looking to the country of self.env

Bug solution:

1 - If the country is not swiss, the default is assigned as False

    1.1 -> fixed in l10n_ch_hr_payroll/hr_version

    1.2 instead of assigning swiss contract type to the non-swiss emp.

Note: This is fix from saas-18.4 to master.

task-6392040

runbot error: https://runbot.odoo.com/odoo/runbot.build.error/941358

Forward-Port-Of: odoo/enterprise#127687
Forward-Port-Of: odoo/enterprise#126520

Following the fix made in community branch, this adds a test veryfing the expected behavior in case of a fluctuating rate for the domestic currency.

Scenario 2: fluctuating domestic (USD) rate
 USD rate=1 from Jan 1 to Jun 30, USD rate=3 from Jul 1 to Dec 31
 EUR rates unchanged: 2 from Jan 1, 4 from Jul 1

 Correct conversion factors (= USD_rate / EUR_rate):
  Jan 1 – Jun 30 (182 days): 1/2 = 0.50
  Jul 1 – Dec 31 (184 days): 3/4 = 0.75

 Current rate at 2020-12-31:      3/4 = 0.75
 Correct average rate:            (0.50 * 182 + 0.75 * 184) / 366 = 229/366 ≈ 0.62568
 Previsouly bugged average rate (USD fixed at current=3): (1.50 * 182 + 0.75 * 184) / 366 = 411/366 ≈ 1.12295

 Historical equity rates (correct vs previously bugged):
  Mar 1 (USD=1, EUR=2): correct = 1/2 = 0.50; buggy = 3/2 = 1.50  → 40 * 0.50 = 20 vs 40 * 1.50 = 60
  Oct 1 (USD=3, EUR=4): correct = 3/4 = 0.75; buggy = 3/4 = 0.75  → 60 * 0.75 = 45 (same by coincidence)

task-5953104

X-original-commit: 6357edc49f8bbc0d553dc6073c66865bf5af9db1

Following the fix made in community branch, this adds a test veryfing the expected behavior in case of a fluctuating rate for the domestic currency.

Scenario 2: fluctuating domestic (USD) rate
 USD rate=1 from Jan 1 to Jun 30, USD rate=3 from Jul 1 to Dec 31
 EUR rates unchanged: 2 from Jan 1, 4 from Jul 1

 Correct conversion factors (= USD_rate / EUR_rate):
  Jan 1 – Jun 30 (182 days): 1/2 = 0.50
  Jul 1 – Dec 31 (184 days): 3/4 = 0.75

 Current rate at 2020-12-31:      3/4 = 0.75
 Correct average rate:            (0.50 * 182 + 0.75 * 184) / 366 = 229/366 ≈ 0.62568
 Previsouly bugged average rate (USD fixed at current=3): (1.50 * 182 + 0.75 * 184) / 366 = 411/366 ≈ 1.12295

 Historical equity rates (correct vs previously bugged):
  Mar 1 (USD=1, EUR=2): correct = 1/2 = 0.50; buggy = 3/2 = 1.50  → 40 * 0.50 = 20 vs 40 * 1.50 = 60
  Oct 1 (USD=3, EUR=4): correct = 3/4 = 0.75; buggy = 3/4 = 0.75  → 60 * 0.75 = 45 (same by coincidence)

task-5953104

Forward-Port-Of: odoo/enterprise#123055