### 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

**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. 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
==================

- 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