Steps to reproduce:
------------------------------
1. Install Subscription module
2. Create a new subscription and confirm it
3. Create an invoice from the subscription.
  * Register a payment and ensure the invoice is in the Paid state.
4. Go back to the subscription and close it with any reason
5. Open the related invoice.
  * Create and Confirm Credit Note.
  * Register a payment for the credit note.
6. Go back to subscription

Observation:
------------------------------
The subscription is automatically set back to `In Progress` even  though it was previously churned.

Issue:
------------------------------
The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid.

Solution:
------------------------------
Add a condition to exclude refund invoices from the reopening logic

opw-5947999

Forward-Port-Of: odoo/enterprise#108487

Prerequisites:
------------------------------
1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket
2. From Settings, create one Alias Domain

Steps to reproduce:
------------------------------
1. Install Helpdesk module
2. Open Helpdesk Team > Settings
3. Inside Channels, Set the mail used for the incoming server and the alias created
4. Set Accept Emails From to Everyone
5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`)
6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail.
7. Open Incoming mail sever  > Click on Fetch Now
8. Open Created Contact

Observation:
------------------------------
The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost

Issue:
------------------------------
After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update.

https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369

Solution:
------------------------------
Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails

Note for reviewer
-----------------------------
After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address.

That said, we should also avoid automatically clearing or altering the existing value in the field.

Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint.


opw-5478067

Forward-Port-Of: odoo/enterprise#107808

An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation

Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```

Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown

Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.

Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.

target: saas-18.4
task-6034836

Forward-Port-Of: odoo/enterprise#110568

Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app

Observation:
----------------------------------
Tracaback Occurs:
```
 File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
    existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```

Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320

Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.

Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.

opw-5391742

Forward-Port-Of: odoo/enterprise#111084
Forward-Port-Of: odoo/enterprise#102335

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service.

**Current behavior before PR:**
When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice.

**Desired behavior after PR is merged:**
For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error.

Forward-Port-Of: odoo/enterprise#106881

Backport of https://github.com/odoo/odoo/pull/249869

Description
This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a default account linked to an existing journal has been archived.

Current Behavior
Currently, when a user creates a new journal (e.g., a "Bank" type journal), the system automatically generates or assigns a default account. If the user subsequently archives that default account, any future attempt to create a new journal of the same type results in a Validation Error:

"Account codes must be unique. You can't create accounts with these duplicate codes: [XXXXXX]"

This happens because the system's uniqueness check for account codes includes archived accounts, but the automated journal setup logic fails to account for this state, effectively locking the user out from creating new journals until the archived account is manually renamed or unarchived.

Desired Behavior
After this PR is merged, users should be able to create new journals seamlessly, even if previous journals have archived default accounts.

video
https://drive.google.com/file/d/1VzAskdTwF7lNc1y8PIpvN0T2zzKTMtdJ/view

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#251025

When vendor bills digitization is deactivated, subscribers to the "Purchases" journal are not notified when a vendor bill is sent to the email alias set on the "Purchases" journal

Steps to reproduce:
1. Install Accounting
2. Go to Settings > Accounting > Digitization and set Vendor Bills to "Do not digitize"
3. Go to Settings > Technical > Email > Alias Domains and create a new alias domain (e.g. "odoo.com")
4. Go to Settings > Technical > Email > Incoming Mail Servers and create a new incoming mail server (e.g. "megu@odoo.com", you may need to setup POP access on your email address and create an app password, see https://support.google.com/mail/answer/7104828)
5. Go to Accounting > Configuration > Journals and open journal "Purchases"
6. Go to Advanced Settings tab and set the Email Alias and the Send Copy To fields (e.g. "megu@odoo.com" for both)
7. Send a mail with an attachment to the email alias set on the "Purchases" journal
8. Go to the previously created incoming mail server and click on Fetch Now
9. Go to Settings > Email > Technical > Emails
10. No email has been sent to the subscriber of the "Purchases" journal

Issue:
`_extend_with_attachments` returns None if the OCR import failed https://github.com/odoo/odoo/blob/b44295bb6ce621ff87cbc96860492650d90d0ad7/addons/account/models/account_document_import_mixin.py#L340-L349 which prevents the call to method `_notify_invoice_subscribers`

Solution:
Send an email regardless of the result of the OCR import

opw-5914096

Forward-Port-Of: odoo/odoo#252442

Trying to investigate this common issue:

https://runbot.odoo.com/runbot/build/104596176 script timeout exceeded -> internal error during screenshot + timeout error when trying to shut down service workers (but oddly `Page.stopLoading` worked so the browser might not be entirely hosed?)

https://runbot.odoo.com/runbot/build/104598123 and https://runbot.odoo.com/runbot/build/104599315 only parsed a timeout during service workers shutdown, but looking at the logs they actually have the same error, it's just that the in-band error is suppressed by the retry, but then the traceback finder goes and triggers on the TB it finds in the logs (but only the last link of the TB so the thing is cut off):
```

2026-03-19 03:48:11,239 26 INFO 104599315-saas-19-1-all odoo.addons.website.tests.test_snippets.TestSnippets.test_03_snippets_all_drag_and_drop: Asking for screenshot 
2026-03-19 03:48:11,241 26 INFO 104599315-saas-19-1-all odoo.addons.website.tests.test_snippets.TestSnippets.test_03_snippets_all_drag_and_drop: Couldn't capture screenshot: Internal error 
2026-03-19 03:48:21,249 26 _WARNING 104599315-saas-19-1-all odoo.tests.common: Error during browser shutdown 
Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 2566, in browser_js
    self.fail(str(error))
  File "/usr/lib/python3.12/unittest/case.py", line 715, in fail
    raise self.failureException(msg)
AssertionError: Script timeout exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 1664, in _websocket_request
    return f.result(timeout=timeout * self.throttling_factor)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/concurrent/futures/_base.py", line 458, in result
    raise TimeoutError()
TimeoutError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 1375, in _ws_winddown
    self._websocket_request('Runtime.evaluate', params={'expression': """
  File "/data/build/odoo/odoo/tests/common.py", line 1666, in _websocket_request
    raise TimeoutError(f'{method}({params or ""})')
TimeoutError: Runtime.evaluate({'expression': "\n            ('serviceWorker' in navigator) &&\n                navigator.serviceWorker.getRegistrations().then(\n                    registrations => Promise.all(registrations.map(r => r.unregister()))\n                )\n            ", 'awaitPromise': True})
```

Issue before this commit:
=========================
Clicking Produce All on a Manufacturing Order as a user with Manufacturing and Timesheet rights raised an AccessError.

During Manufacturing Order completion, Odoo creates analytic lines for work center cost distribution and links them to the work order through the wc_analytic_account_line_ids Many2many field. With the stricter ORM security checks, linking records in a Many2many field requires read access to those records. Since analytic lines are created using sudo() but the relation update runs under the current user's permissions, the operation fails due to timesheet-related record rules.

Steps to Reproduce:
=========================
1. Install mrp_account and hr_timesheet modules.
2. Create a Work Center with an analytic distribution.
3. Create a Product with a Bill of Materials (BoM) that includes a work order using the created Work Center.
4. Log in as a non-admin user with Manufacturing and Timesheet permissions.
5. Create and confirm a Manufacturing Order for that product.
6. Click Produce All.

Cause of the Issue:
=========================
Analytic lines are created with sudo(), but when linking them to the work order through the Many2many field wc_analytic_account_line_ids, the ORM checks whether the current user has read access to those records. Due to timesheet record rules restricting access to analytic lines, the linking operation raises an AccessError.

With This Commit:
=========================
This commit allows users to complete Manufacturing Orders without encountering access errors when analytic lines are linked to work orders, while preserving the existing analytic distribution and security logic.

For Reference: [Security checks on Many2many](https://github.com/odoo/odoo/pull/217277/changes#diff-720a85988e5f3afc3b2596b9521964ef4a99e03e5b1ea8bea2e8ee476187526aR1467)

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/1HsZjpFSsnsYxZ4xwM8CBDeLhlcIHIP5t/view)

opw-5971807

Forward-Port-Of: odoo/odoo#253496

When opening invoice HTML preview in the portal, the layout was displayed in LTR
even if the invoice partner language was RTL (e.g. Arabic). This happened when
the portal user language was LTR. PDF structure was correct, but HTML preview had
wrong text flow and alignment.

Root cause was that RTL asset processing depends on `env.lang`, not on `t-lang`
in templates. Since the ORM context language remained the portal user’s language,
CSS was compiled in LTR and hardcoded `direction: ltr;` rules from `report.scss`
were overriding the `<html dir="rtl">`.

To fix this, the portal controller now checks the partner language and, if it is
RTL, updates the request context before rendering. This ensures `_render_qweb_html`
runs with the correct `env.lang`, triggering proper RTL CSS conversion via rtlcss.

Additionally, the subtotal section in the Saudi invoice report could have its
values visually cut due to insufficient width allocated to the tax totals
column. The column width has been slightly increased to ensure totals are
properly displayed.

task-5878719

Forward-Port-Of: odoo/odoo#248822

If an order in overpaid using bank, no move line is created for the change.

Steps to reproduce:
-------------------
* Make an order, add a customer
* During payment, select invoice, pay more than the order amount with bank pm
* Validate
* Close register
* Check customer
> Observation: It says we owe the customer money, although change was given.

Why the fix:
------------
Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it.

Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted.

opw-5149700

Forward-Port-Of: odoo/odoo#254125
Forward-Port-Of: odoo/odoo#247621

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

opw-4934391
opw-5226806

Forward-Port-Of: odoo/odoo#239836

Forward-Port-Of: odoo/odoo#250998
Forward-Port-Of: odoo/odoo#243812

Under some conditions, it is currently not possible to render the preview of
some layouts

To reproduce the issue:
(Need `l10n_din5008`)
1. Open Settings more times than the number of companies in the database
   - (We actually need to increase the psql sequence of its table...)
2. Configure your document layout
   - Layout: DIN 5008
3. Click "Preview Document"

Error: an error is displayed: "Missing record: Record does not exist or has
been deleted. (Record: res.company(4,), User: 2)"

When clicking on _Preview Document_, we are actually requesting
`/report/pdf/web.preview_externalreport/4`
Where we have both the report name and the `docids` (equal to `4` in the above
example). Since we are calling it from the `res.config.settings`, we provide
the doc IDs with the ID of the `res.config.settings`. However, the report is
based on the `res.company` model:
https://github.com/odoo/odoo/blob/2f64f909d2f20cc8c0a8e95ba7d17348b9b015e6/addons/base_setup/views/res_config_settings_views.xml#L90
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L1006-L1010
As a consequence, the mechanism will try to render the report using the
company with ID equal to the ID of the config settings, which does not make
sense. This is the reason why, at some point, it can lead to a `Missing
Record` error.

That said, the case is working well on previous versions because we were
defining a global `o` variable before rendering the template, cf for
instance on Odoo 19, L896:
https://github.com/odoo/odoo/blob/1c2e17718e6f2a11d93585f0ea3ba3abee5a4a41/addons/web/views/report_templates.xml#L893-L897
Thanks to that variable, DIN 5008 side, we ignore the `docs`, cf here for
instance:
https://github.com/odoo/odoo/blob/dae4fd0000080ba6395b370e25d3f13f1becd74e/addons/l10n_din5008/report/din5008_report.xml#L96

On Odoo 19.1+, this global variable has been removed by [1]. This commit is
actually the result of a script (cf its description). Since the script
hasn't detected the use of `o`, it moved its declaration inside the previous
`t-call`, L829:
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L827-L830
This was a mistake since the global variable is sometimes used. Long story
short, the script didn't see the dynamic `t-call` inside the template of
`web.external_layout`:
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L758-L761

We have therefore decided to revert this part of the commit and apply the
same logic to its siblings `preview_internalreport` and `preview_layout_report`

[1] https://github.com/odoo/odoo/commit/b7ec60d68c6ee23f7684960e33e5bd6290c9d829

OPW-5951003