Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.

As a result, a partner named "test & test GMBH" was exported as:
  <Nm>test + test GMBH</Nm>
instead of the expected:
  <Nm>test & test GMBH</Nm>

This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.

Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:

- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.

- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.

Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.

ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:

Forward-Port-Of: odoo/enterprise#118604
Forward-Port-Of: odoo/enterprise#115409

Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report.

## Steps to produce:
* Install mrp_account without demo data.
* Create a product with inventory tracking enabled.
* Create a BoM of type kit for that product.
* Add component products with a defined cost and on-hand quantity greater than 0 to the BoM.
* Recompute the kit product’s cost from its BoM on the product page.
* Go to Inventory > Reporting > Stock > Inventory at date > Confirm

## Observed Behavior:
Even though kits do not appear on stock valuation they still do appear the inventory history report.

**Why kits should not appear on inventory history**
For example, consider a kit product called 'Computer' that is composed of the following components:

| Product | Quantity | Cost |
|--------|--------|--------|
| CPU | 1 | $300 |
| Motherboard | 1 | $300 | 

The total cost of the Computer kit is therefore $600. Since the Computer is made up of the CPU and Motherboard, the total inventory value should be $600. However, the system is currently calculating the total inventory value  at that particular date as $1,200, which is incorrect because it is counting both the kit and its components

## Root cause:
This issue occurs when a user opens the inventory history for a specific date using the `Inventory at Date` option and clicks confirm.

At that point, the `open_at_date` function is triggered, which filters products based on the `domain` defined in [1]. Since this domain only checks for tracking-enabled products and does not exclude kit products, kit products still appear.

**Why doesn’t this issue occur in the normal stock view?** 
Because the domain is overridden at [2] to explicitly exclude kit products from the stock view.

However, the quantity history report does not apply this same domain override, so kit products continue to appear there.
[1]:
https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/stock/wizard/stock_quantity_history.py#L16-L38 [2]:
https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/mrp/views/product_views.xml#L164-L166

## Solution:
To ensure accurate total inventory valuation, kit products should be excluded from the valuation, and only their individual components should be considered.

This can be achieved by modifying and overriding the domain to explicitly exclude kit products.

This PR can be considered an extension of [3](https://github.com/odoo/odoo/commit/6d9c7165ec60ed0b871ac46d8d85ebbf082e8835).


opw-6164547

Forward-Port-Of: odoo/odoo#262185

Steps to produce:
---
- Install the `Sales` module, enable `Variants` in settings.
- Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as `Custom`, enable `Free Text`, set extra price to `25`, set variant creation to `Never`, and save.
- Create a sales order, add the product > configurator opens.
- Without saving, open and close the configurator repeatedly (using the pencil icon).

Issue:
---
-  Product price keeps increasing on every open.

Root cause:
---
- After this [commit], `_getVariantPtavIds()` returns a direct reference to the live `currentIds` array. In edit mode, pushing `_getNoVariantPtavIds()` into it mutates the actual field value, so no-variant PTAV ids accumulate on every reopen, causing duplicate IDs and inflated price computation.

Fix:
---
- Clone the array to avoid mutating the live `currentIds`.

[commit]: https://github.com/odoo/odoo/commit/bd4b6d02fed5fdc5ce628cb7d76df4cfdd2d1b3b

opw-6267273
---

**Note:** Not adding a test because only tour test is possible here in this scenario with makes the execution process slow.



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

Forward-Port-Of: odoo/odoo#267991

## Description of the issue/feature this PR addresses

The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section.  

This affects not only external modules but also internal ones that add menu items under *Contacts*.

## Current behavior before PR

When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy.

<img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" />

## Desired behavior after PR is merged

The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules.

<img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" />



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

Forward-Port-Of: odoo/odoo#234909

**Steps to reproduce:**
* Install the **l10n_es_edi_sii** module.
* Create a **Portuguese customer**.
* Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping.
* Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**).
* Go to **Accounting → Reporting → Tax Report → OSS Sales**.
* Export the **VAT Record Books (XLSX)** file and open it.

**Observed behavior:**
* The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17".
* The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17".

**Cause:**
* In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01".
* This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table.

**Fix:**
* Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`.
* For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise.
* For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise.

opw-6197141,6216485

Forward-Port-Of: odoo/enterprise#119467
Forward-Port-Of: odoo/enterprise#117236

### Description of the issue/feature this PR addresses:

  This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish localization databases. Because the Access Control List (ACL) rule for  l10n_pl.bank.account.verification  was limited only to the "Show Full Accounting Features" group (account.group_account_user ), standard billing users who do not have full accounting features could not access or read verification records during payment registration. This PR modifies the read access rules to grant permissions to the Invoicing group ( account.group_account_invoice ).

  ### Current behavior before PR:

  • Users belonging only to the "Invoicing" group (without "Show Full Accounting Features" rights) receive an Access Denied error when attempting to register a payment for a confirmed invoice:
  │  You are not allowed to access 'PL Bank Account Verification' (l10n_pl.bank.account.verification) records. 

  • This triggers a failure to write/compute the transient field  account.payment.register.l10n_pl_bank_verification_ids  during the payment wizard load, completely blocking billing  users from processing payments.

  ### Desired behavior after PR is merged:

  • Standard Billing/Invoicing users ( account.group_account_invoice ) can successfully register payments for invoices.
  • The payment register wizard computes the  l10n_pl_bank_verification_ids  and displays warning banners regarding VAT verification without throwing security exceptions.
  • Full Accounting users ( account.group_account_user ) retain read access as they inherit all privileges from the Invoicing group.

Closes #263938

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

Forward-Port-Of: odoo/odoo#267992

**Problem:**
When an attendance has overtimes across multiple days, those overtimes can
overlap when calculating their intervals.

There will always be rounding errors since only the durations are saved to 3
decimals, but this is normally fine since the durations are accumulated when
calculating the next interval.

However, on a day boundary in the employee timezone, the end of the interval is
forced to the end of day, which incidentally removes the rounding error. This
causes the overlap when calculating the next interval since its start will be
based on the rounded duration, not the actual end of day.

**Steps to Reproduce:**
- Configure an overtime rule where >8 hours is considered overtime, and a
second rule applies to non-working days
- Set Overtime Rule on employee "Anita Oliver"
- Set employee work entry source to "Attendances"
- Create an attendance that exceeds 8 hours in a day and crosses into a
non-working day and creates enough of a rounding error (see unit test)

-> Traceback error:
`ValueError: Expected singleton: hr.attendance.overtime.line(1, 2)`

**Solution:**
Add an additional check to ensure the overtime cannot start on the previous
day.

opw-6067969

Forward-Port-Of: odoo/enterprise#118570

### Issue before this commit:
When reversing an invoice in a Peruvian company, the "Cancel Reason" entered in the credit note window is not propagated to the Peruvian EDI tab of the resulting Credit Note. Only the Credit Reason is successfully reported.

### Steps to reproduce the issue:
1. Download Accounting and l10n_pe
2. Switch to PE company
3. Create an invoice and confirm it
4. Create a credit note for the invoice with a cancel reason and a credit reason and click the reverse button
5. See that in the Peruvian EDI tab only the Credit Reason is reported but not the Cancel Reason

### Cause of the issue:
In the l10n_pe_edi module, the override of the _prepare_default_reversal method maps the l10n_pe_edi_refund_reason to the new move's values, but completely omits the mapping of the wizard's textual reason field to the l10n_pe_edi_cancel_reason field of the resulting credit note.

### Reason to introduce the fix:
To ensure the generated credit notes contain all required information for the Peruvian EDI (SUNAT). Mapping the cancel reason guarantees that the electronic document accurately reflects both the refund code and the descriptive cancellation text provided by the user.

opw-6238525

Forward-Port-Of: odoo/enterprise#119532
Forward-Port-Of: odoo/enterprise#118479

With Automatic Invoice enabled, no mail confirmation is sent when a picking is validated and the partner doesn't have a user

Steps to reproduce:
1. Install eCommerce and Sales
2. Go to Settings > Inventory > Shipping and enable "Email Confirmation"
3. Go to Settings > Sales > Invoicing and enable "Automatic Invoice"
4. Go to Website > Configuration > Payment Providers and Install Demo
5. Go to Sales > Products, open product "Office Lamp", click on "Update Quantity" in the status bar and add 5 units
6. Log out
7. Go to the shop, add product "Office Lamp" to the cart and checkout
8. Fill in the address form and continue checkout
9. Confirm the order and pay with Demo
10. As user Mitchell Admin, go to Sales, remove the default filter and open the newly created sale order
11. Open the related delivery with the smart button and validate it
12. No delivery order confirmation was sent to the customer (check emails)

Issue:
When automatic_invoice is enabled, we automatically send an invoice when the payment transaction of an order has been processed. This has the effect of archiving partners that don't have a user https://github.com/odoo/odoo/blob/fa9c16472939f71ff9687718f25addd64bb1a97c/addons/website_sale/models/payment_transaction.py#L9-L14

Solution:
???

opw-6232937

**Step to reproduce :**

1. Create a deliverable product with a sales tax.
2. Create another product with a different sales tax.
3. Publish both products on the eCommerce website.
4. Create a discount program.
5. Add both products to the shopping cart.
6. Apply the discount code.
7. Proceed to checkout.

**Issue :**

Applying a discount on multiple products with different taxes causes an infinite reload cycle during checkout.

**Reason :**

The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.
https://github.com/odoo/odoo/blob/18.0/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24

After the fix introduced in:
https://github.com/odoo/odoo/pull/248215

However, when a discount is applied to products with different taxes, the corresponding reward lines are still categorized as `discounted_lines` instead of `groupable_lines`. As a result, they continue to be processed individually rather than being grouped by reward.
    
This leads to a mismatch between the backend, which generates one discount line per tax combination, and the frontend, which expects a single discount entry per reward. Consequently, the checkout page continuously reloads while attempting to synchronize both states.
    
**Solution:**
    
When a discount applies to products with different tax configurations, the corresponding reward lines should be included in `groupable_lines` rather than `discounted_lines`. This ensures that discount lines are grouped by
`reward_id` consistently on both the frontend and backend, preventing the checkout reload loop.

opw-6210411

Forward-Port-Of: odoo/odoo#265740

**Issue**
Printing a credit note for a returned dropshipped tracked product could display the wrong lot/serial number on the invoice report.

**Steps to reproduce**
- Activate "Display Lots & Serial Numbers on Invoices"
- Create a product tracked by serial/lot and enable the dropship route
- Create two lots: "lot1" and "lot2"
- Create and confirm a SO for quantity 2
- Confirm the PO and validate the dropship for both lots
- Create and post an invoice
- Return "lot2" from the dropship picking
- Create and post a credit note for quantity 1
- Click on print -> The generated PDF displays "lot1" instead of "lot2"

**Cause**
While rendering `account.report_invoice_with_payments`, the report calls `_get_invoiced_lot_values` to determine which lot/serial numbers should be displayed:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L31-L32 `invoiced_qties = 1` since the credit is on a quantity of 1 https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L44 Three stock move lines are retrieved from the SO:
- the two original dropship deliveries,
- the return move for `lot2`. https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L63 However, none of them are considered as `is_stock_return` because the dropship locations use `supplier` instead of `internal`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L72-L76 As a consequence:
- The two original delivery move lines each keep quantity `1`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L69 they never pass through the return handling logic: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L77-L80 which would make it as -1 (since `qties_per_lot[sml.lot_id]` is 0 for the first iteration of `sml.lot_id`). Thus, it does not pass by this code (since quantity is greater than 0): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L87-L90 which would make it as 0.
- for the last one, `is_stock_return = False` as it should be, thus the quantity is 1 as it should be. The quantities are therefore accumulated as:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L92

resulting in:
`qties_per_lot = {lot1: 1, lot2: 2}`
instead of:
`qties_per_lot = {lot1: 0, lot2: 1}`

The report then selects the first matching lot and stops: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L94-L99

opw-6230281

Forward-Port-Of: odoo/odoo#266716

### What & why

`odoo db load` always calls `restore_db(..., copy=True)`, which forces the
generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is
the right default when *duplicating* a database, but it breaks the intended
behaviour when *moving* a database between servers: Enterprise subscription codes
are registered against the database UUID, so regenerating it deregisters the
moved database.

The web database manager already lets the user choose between copying and moving
(the `copy` flag of the `/web/database/restore` route), but the CLI exposed no
equivalent and forced a copy unconditionally. The CLI is the better tool for
server-to-server moves: it isn't subject to reverse-proxy upload/timeout limits
and can run unattended or interactively.

### Steps to reproduce the current limitation

1. On server A: `odoo db dump mydb mydb.zip` (Enterprise DB registered to its UUID)
2. On server B: `odoo db load mydb mydb.zip`
3. `database.uuid` has changed → the subscription is deregistered

### Fix

Add a `--move` flag to `odoo db load` that maps to `restore_db(copy=False)`,
keeping the original UUID. The default remains `copy=True`, so existing behaviour
is unchanged.

```sh
odoo db load mydb mydb.zip          # unchanged: restore as a copy (new UUID)
odoo db load --move mydb mydb.zip   # new: restore as a move (keep the UUID)
```

### Backport request

This would be greatly appreciated as a backport to 18.0, 17.0, and 16.0 as well.
Those are precisely the versions that ship the `odoo db` CLI subcommand, so the
fix is applicable to all of them — which is why the backport range is 16.0 → 19.0
and stops at 16.0.

Forward-Port-Of: odoo/odoo#268501

Steps to Reproduce:

* Create a Hungarian company on 19.0 (or earlier).
* Configure NAV credentials through Settings.
* Upgrade the database to saas~19.2.

Issue:

* The upgrade fails while reloading the Hungarian chart template.

```python3

Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-19.2/odoo/service/server.py", line 1626, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/tools/func.py", line 65, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/registry.py", line 202, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 502, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 215, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, version)
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 253, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu/migrations/3.1/end-migrate_update_taxes.py", line 7, in migrate
    env['account.chart.template'].try_loading('hu', company)
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/chart_template.py", line 181, in try_loading
    return self._load(template_code, company, install_demo, force_create)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/template_hu.py", line 11, in _load
    company._l10n_hu_edi_configure_company()
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 79, in _l10n_hu_edi_configure_company
    res_config_id = self.env['res.config.settings'].create({
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.2/hr_payroll/models/res_config_settings.py", line 39, in create
    return super().create(vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_config_settings.py", line 48, in create
    record.company_id._l10n_hu_edi_test_credentials()
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 107, in _l10n_hu_edi_test_credentials
    raise UserError(
odoo.exceptions.UserError: Helytelen NAV hitelesítő adatok! Ellenőrizze, hogy a cég adószáma helyesen van-e beállítva.
Hiba részletei: HTTPSConnectionPool(host='api.onlineszamla.nav.gov.hu', port=443): Max retries exceeded with url: /invoiceService/v3/tokenExchange (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x798a970f1fd0>: Failed to establish a new connection: [Errno 111] Connection refused'))
```

Cause:

* Since the introduction of the Hungarian tax migration using `account.chart.template.try_loading('hu', company)` in saas~19.1, upgrades reload the Hungarian chart template.
* When `l10n_hu_edi` is installed, chart template loading triggers `_l10n_hu_edi_configure_company()`, which performs NAV credential validation through `_l10n_hu_edi_test_credentials()`.
* The credential validation performs a live request to the NAV service, making the upgrade dependent on an external service. https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/res_company.py#L99-L109 https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/template_hu.py#L11

Fix:

* Bypass NAV credential validation during the migration.
* The migration only updates localization data and does not modify the configured EDI credentials.
* This prevents temporary NAV connectivity issues from aborting the upgrade process.

see https://github.com/odoo/odoo/pull/253556

opw-6253523
upg-4326247

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