- batched _compute_company_ids on returns
- batched return to unlink in _generate_or_refresh_all_returns
- removed redondant call to _generate_or_refresh_all_returns in
  action_save_onboarding_fiscal_year since we want to call it only
  when a value is changed and that's already handled in the write on
  the company.
- batched _is_available_for on reports
- make only one write on the company (and one call to
  _generate_or_refresh_all_returns) when writing or create the fiscal
  year wizard.
- dont delete return created manually with a date before the date of
  the account_opening_date and not yet posted.

Detected from runbot error:
https://runbot.odoo.com/odoo/runbot.build.error/231463

A small workaround is needed on the company when writing the changes
from the fiscal year wizard. This is because related fields are writen
one by one, which then trigger multiple times
_generate_or_refresh_all_returns. To prevent this, we are batching
all the write on the company from the fiscal year wizard in one write.
The opening_date need to be handled separatly since it's not a related
field but still need to be writen on the company, if removed from the
vals during the create it's then not possible to save the wizard anymore.

Also fixed a bug where the returns manually created before the
account_opening_date would be deleted if they were not posted before
the next call to _try_create_returns_for_fiscal_year.

**Detailed Explanation**

We can see the tour being broken when trying to save on the wizard:

<img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/9443251c-aee1-4fbe-be2f-27c11bcbb77d" />

So we can do a flamegraph to take a look at what's happening on that database during that time and we can see 2 majors time uses, a call to `_generate_or_refresh_all_returns` triggered by a write on the wizard and a call to `action_save_onboarding_fiscal_year`

<img width="1396" height="855" alt="image" src="https://github.com/user-attachments/assets/a9d310da-2787-4806-951d-e50b8c1da2a8" />

The first call to `_generate_or_refresh_all_returns` took about 7.8s, the second one took about 1.1s

First, we can see a lot of `_compute_company_ids` calls, this is because we have `precompute=True` on this field due to it being needed in the different access rules.

Since all the returns that are created have similar main company, tax unit and return type, we can easily batch them to only call `_get_company_ids` once for all the returns that will be created. Resulting in the following flamegraph:

<img width="1422" height="866" alt="image" src="https://github.com/user-attachments/assets/c52c88c7-0263-44fb-a16c-52456673dc92" />

The first call to `_generate_or_refresh_all_returns` took about 0.8s, the second one took about 1.2s

Another little change we can do is to remove the call to `_generate_or_refresh_all_returns` during  `action_save_onboarding_fiscal_year` and adding the forced_date from the first one to the second one. 

<img width="1294" height="844" alt="image" src="https://github.com/user-attachments/assets/7ad55d06-ecd4-4957-b514-71fffa6de00c" />

We now end up with one call to `_generate_or_refresh_all_returns` that takes 1.4s

BUT, we can still do better. We can see that all we did previously was only do to one thing less.
The "real" problem was the many search calls done in `_is_available_for` during the `_init_options_variants`.

<img width="1268" height="693" alt="image" src="https://github.com/user-attachments/assets/ebae398d-dfdd-4c1e-99ac-44f25e5875e7" />

After the final change, we are down to 0.9s !

One thing to keep in mind, all those flamegraph were done on a dump of a database from a nightly test, which had many companies created as well as **every** modules installed, which means every return types, reports, ... This means those performance improvements wont be as useful on small databases.

Forward-Port-Of: odoo/enterprise#95760

delivery_* = bpost, dhl, easypost, envia, fedex, sendcloud, shiprocket,
             starshipit, ups, usps, ups_rest, delivery_easypost, delivery_shiprocket,
             l10n_br_edi_website_sale, sale_amazon, sale_shopee

With this PR:
---
1. Renamed 'Shipping Methods' to 'Delivery Methods'
   * Renamed all user-facing labels of "Shipping Method(s)" to "Delivery Method(s)"
for consistent terminology across apps and improved user clarity, without
altering terminology used by specific delivery providers or third-party
integrations.
2. Renamed 'Delivery Carrier'/ 'Carrier' to 'Delivery Methods'
   * A `Carrier` label is used at the stock level, while `Delivery Method` is used at
  the sales level.
   * A Delivery Method represents the complete carrier process along with the
  required parameters defined at the sales level, whereas a Delivery Carrier
  (or Carrier) is used at the transfer/picking level, where the focus is on
  which carrier actually ships the goods rather than the full delivery
  configuration.
   * Therefore, all relevant occurrences of Delivery Carrier have been updated to
  Delivery Method.
   * The remaining occurrences of Carrier/Delivery Carrier refer either to
  stock-level usage, delivery provider's internal labels, or
  localization-specific terminology.

Impact:
-------
- This avoids confusion between "Shipping Method" and "Delivery Method", as
"Delivery Method" better reflects how an order is handed over to the customer,
making the terminology clearer and more contextual.
- Clarifies when "Delivery Method" vs. "Carrier" should be used by keeping "Carrier"
terminology where it correctly reflects stock-level operations, while ensuring sales-level 
terminology remains consistent.

task-4720174

Currently, an error occurs when a user connects a bank that has payments not enabled.

**Steps to replicate:**
* Install `account_online_payment`
* Invoicing > Bank > dropdown menu and connect the demo bank.

**Error:**
`Non-blocking error during payment activation: To activate payments, you must first enable them when connecting a bank account.`

**Root cause:**
*  The error happens because payment is disabled on the bank page. As `is_payment_enabled` is `False` in the `data` at [1], which comes from [2],and that `data` comes from a response in the super call at [3].

**Solution:**
* Since this error comes from a `UserError`, it would be better to use logger warning instead of logger error.

[1]:
https://github.com/odoo/enterprise/blob/b5ff6fff193a7197b3983985c8af13512d677146/account_online_payment/models/account_online_link.py#L18 
[2]:
https://github.com/odoo/enterprise/blob/b5ff6fff193a7197b3983985c8af13512d677146/account_online_payment/models/account_online_link.py#L24 
[3]:
https://github.com/odoo/enterprise/blob/b5ff6fff193a7197b3983985c8af13512d677146/account_online_synchronization/models/account_online.py#L963-L970

sentry-6936347663

Forward-Port-Of: odoo/enterprise#99227

Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor.

The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article.

Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)).

This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile.

runbot error~182073

Forward-Port-Of: odoo/enterprise#99174

Improve the display of the tax details in the journal audit report.

A few issues were spotted:
* The header of the "Taxes Applied" table was not covering the full width when there are taxes related to multiple countries, fixed by using the right variable in the `colspan`
* When taxes have long names, which happens easily with OSS etc, they were displayed on multiple lines in the table, making the table very long. This is fixed with the new `.name` css class, wrapping the line with an ellipsis.
* When there are taxes related to multiple countries, the full name of the country was used. Since the vertical space is scarce, we display the country code instead.
* A lot of space was wasted with poor usage of table elements.
  - The sub-tables were defined inside of `td` elements with fixed `colspan`. This doesn't make sense as they have nothing to do with the headers. By using a single `td` using the full width of the table, and splitting the tables inside of a flex element, we are now more free to have tables of different width depending  on the content of the sub tables
  - The sub tables were using `table-layout: fixed` for no apparent reason. This is forcing thin columns (i.e. the country code) to take a lot of space, and making larger (larger amounts) columns overflow.

[REV] account_iso20022: Wrong XML generated for Switzerland

This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da.

This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt.

The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix.

ticket-4535542

=======================

[FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file

https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard.

Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file.

ticket-4535542

Forward-Port-Of: odoo/enterprise#99150
Forward-Port-Of: odoo/enterprise#98918

Currently an error occurs when user tries to activate a stripe card.

Steps to replicate:
- Install `hr_expense_stripe_demo`, `l10n_be`, and `hr_payroll` with demo data.
- Use ngrok to portforward localhost to the public internet and open the link.
- Switch to My Belgian Company.
- `Settings > Expenses > Expense Card > Agree to T&C > Save > Click Connect`.
- Select `Use Test Phone Number > Use Test Code > Save For Later`.
- Create a new Employee named `Test` and click `Create User` (provide an email).
- Under the `Personal` tab, set the value for the `Payslip Language` field.
- Go to `Expenses > Cards > New`, assign Cardholder as `Test`, and save.
- Click `Activate`, fill in the required fields, and save.
- The error will appear.

Error:
`KeyError: False`

Cause:
- The error occurs because line [1] attempts to remove the `False` item from the `preferred_langs` OrderedSet.
- Line [1] was added as a guard to remove any `False` value from `preferred_langs`, this occurs when an employee has no language set and hence it will be assigned as False.
- However, if the employee has a language selected, there is no `False` value in the `preferred_langs` set, causing line [1] to raise a `KeyError: False`.

Solution:
- Using the python method `discard()`, we can safely remove any False value and function wont raise any error if False is not found in the `preferred_langs` OrderedSet.

[1]: https://github.com/odoo/enterprise/blob/e1d8b1316ce822055a1b42c7f5893cfd1a3dd8a5/hr_expense_stripe/wizard/hr_expense_stripe_cardholder_wizard.py#L176

sentry-6975780020

Forward-Port-Of: odoo/enterprise#98216