### Issue
When receiving vendor bills that include bank details, if the partner has archived bank accounts, Odoo may attempt to update them. This leads to a duplicate key violation on `res_partner_bank` when the same account number already exists for the partner.

#### Affected versions
16.0 and later

#### Error example
```bash
2025-07-08 13:36:52,942 204 INFO server-dummy odoo.addons.mail.models.mail_thread: Routing mail from "Client Name" <erp@odoo.com> to "M7- Odoo V17" <purchases@test.odoo.com>,purchases@test.odoo.com with Message-Id <*****.****.*****-****-*****-****.****@******>: direct alias match: ('account.move', 0, {'company_id': 1, 'move_type': 'in_invoice', 'journal_id': 10}, 1, mail.alias(6,))
2025-07-08 13:36:52,946 204 INFO server-dummy odoo.addons.mail.models.mail_thread: Primary email missing on account.move
2025-07-08 13:36:53,576 204 ERROR server-dummy odoo.sql_db: bad query: UPDATE "res_partner_bank" SET "acc_holder_name" = 'M7 GROUP INC.', "company_id" = NULL, "has_iban_warning" = false, "has_money_transfer_warning" = false, "sanitized_acc_number" = '1234567', "write_date" = '2025-07-08T13:36:52.897826'::timestamp, "write_uid" = 1 WHERE id IN (63)
ERROR: duplicate key value violates unique constraint "res_partner_bank_unique_number"
DETAIL:  Key (sanitized_acc_number, partner_id)=(1234567, 3524) already exists.

2025-07-08 13:36:53,576 204 ERROR server-dummy odoo.addons.account.models.account_move: Error importing attachment 'factur-x.xml' as invoice (decoder=_import_invoice_ubl_cii)
Traceback (most recent call last):
  File "/home/odoo/src/odoo/addons/account/models/account_move.py", line 3219, in _extend_with_attachments
    with self.env.cr.savepoint():
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 85, in __exit__
    self.close(rollback=exc_type is not None)
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 89, in close
    self._close(rollback)
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 113, in _close
    self._cr.flush()
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 137, in flush
    self.transaction.flush()
  File "/home/odoo/src/odoo/odoo/api.py", line 879, in flush
    env_to_flush.flush_all()
  File "/home/odoo/src/odoo/odoo/api.py", line 739, in flush_all
    self[model_name].flush_model()
  File "/home/odoo/src/odoo/odoo/models.py", line 6362, in flush_model
    self._flush(fnames)
  File "/home/odoo/src/odoo/odoo/models.py", line 6464, in _flush
    model.browse(ids)._write(vals)
  File "/home/odoo/src/odoo/odoo/models.py", line 4548, in _write
    cr.execute(SQL(
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 332, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "res_partner_bank_unique_number"
DETAIL:  Key (sanitized_acc_number, partner_id)=(1234567, 3524) already exists.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#224248
Forward-Port-Of: odoo/odoo#223873

When a payment term with early payment discount is used on invoice the discount date is set on the payment term line based on the actual configuration of the payment term. When the invoice is posted, this date must not change anymore as it usually is what is communicated to the partner in order to apply EPD.

However, if the payment term's delay for discount is modified, the discount date from the move line was not taken into account by the payment register wizard or by the reconciliation widget, as it was instead recalculating a discount limit date, based on the configuration of the payment term at the time the payment is registered on Odoo.

Make sure it is the discount date that is stored on payment terms' account move line that is used to define if an early payment discount has to be applied.

OPW-4895365

Description of the issue/feature this PR addresses:

On runbot, create a new payment term with an early payment discount (eg 10% at 15 days, balance at 30 days).
Create a customer invoice with a invoice line (eg 100 USD) for any customer with this payment term and set the date to 10 days before today. Post the invoice, you can see on the payment term line that the discount is valid until 5 days after today.
Modify the payment term to set 10% at 5 days. If you go back to the invoice, you'll notice the discount date is still 5 days after today which is fine since this is what was communicated to the customer

Current behavior before PR:

Register a payment on this invoice and you'll notice the EPD is not applied because it gets the date from the actual configuration of the payment term instead of the date stored on the invoice's payment term line.

Desired behavior after PR is merged:

Register a payment on this invoice must apply the EPD as it is still valid based on the invoice's payment term line.

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

Forward-Port-Of: odoo/odoo#220295
Forward-Port-Of: odoo/odoo#215615

Versions
--------
- saas-18.2+

Steps
-----
1. Have a product with extra eCommerce images;
2. enable zoom-on-click on the product page;
3. add a recently-sold product carousel to the page;
4. click on an image to zoom in;
5. attempt to use arrow keys to navigate or using esc to exit zoom.

Issue
-----
Keys don't appear to do anything.

Cause
-----
Commit b8d0ab4275b24 set `oe_website_sale` as `snippet_classes` on the `s_dynamic_snippet_products` snippet, in order to enable the `websiteSaleTracking` widget, which uses this class as `selector`.

Issue is this class also gets used as the selector by the `WebsiteSale` widget which adds zoom-on-click event listeners. As there are two elements with the `oe_website_sale` class now, this widget gets called twice, and because the query selector selects all image elements on the sale page, images get duplicate event listeners assigned to them.

Consequently, clicking on an image opens two lightboxes, and the keys only impact the one hidden behind the other, making it appear as if key presses aren't doing anything.

Solution
--------
Instead of querying all images on the sale page in each call of the widget, only query for images in `this.el`.

opw-4908881

Forward-Port-Of: odoo/odoo#223231

> [!Note]
> This PR unreverts fc6b9ed22728 with a minor modification to ensure one `res.currency` record to compare amounts.

**Steps to reproduce**:
1. Install the `sale` module.
2. Enable `Pricelists` under `Settings > Sales > Pricing > Pricelists`.
3. Create two pricelists:
   - Pricelist A with two fixed-price rules: - 0.75 for quantity ≥ 0 - 0.50 for quantity ≥ 1000
   - Pricelist B with a -10% discount applied to Pricelist A.
4. Create a Sales Order using Pricelist B.
5. Add a product to the order line.
6. Increase the quantity to 1000.

**Observed behavior**:
- The unit price does not update according to the pricelist rule for quantity ≥ 1000.
- If you switch the pricelist to another and then back again, the `Update prices` button appears and correctly updates the price.

**Root cause**:
- The price is not recomputed when the quantity changes because the `price_unit` is not updated because it does not match the `technical_price_unit`.
- Since e1b22257a714, `price_unit` is rounded (2 decimals), but `technical_price_unit` is not. This causes a mismatch in comparison logic due to rounding differences.

**Solution**:
- Replace direct float comparison with `currency_id.compare_amounts()` to ensure proper comparison with rounding precision.

opw-4944644

Forward-Port-Of: odoo/odoo#223548

If you have a product template with variant, ex: Telephone case, variant name : Iphone 15 SE, Samsung Galaxy, Nokia 1999
When doing a search with more then 2 letters you will only find the Telephone case, searh exemple: Iphone 15 SE, Galaxy, Samsung.

** Step to reproduce **
- Create a product called "Telephone case" and add a variant named samsung galaxy S24 ultra
- Create a product called "Samsung galaxy"
- Enable both products for point of sale
- Go to the point of sale app and open a shop that sells both of those products.
- Do a search for the product Samsung galaxy
- Issue : Only the product "Telephone case" will appear.

** Cause of the issue **
Doing a search will call getProductsBySearchWord:

https://github.com/odoo/odoo/blob/5a1fff2cc61bd8676049879039defa3fb2a3f13d/addons/point_of_sale/static/src/app/services/pos_store.js#L2401-L2407

During the product.exactMatch(words) we will get a hit since we will have a name of the product variant:

https://github.com/odoo/odoo/blob/5a1fff2cc61bd8676049879039defa3fb2a3f13d/addons/point_of_sale/static/src/app/models/product_template.js#L265-L278

And the call for the function will finish there since the searchword lenght > 2 and we have a hit.

** Origin of the issue **

The variant search was implemented in "exactMatch()" which block more search if it find a result.

https://github.com/odoo/odoo/commit/05abd586d7adcceed3dae0943526e6357b28dbb4

opw-4864976

Forward-Port-Of: odoo/odoo#217484

### Description of the issue/feature this PR addresses:
Nilvera rejects E-Archive invoices if extra fields are present under
`PartyTaxScheme` when no tax office is set. In addition, the
`invoice_edi_format` selection name for TR was incorrect.  

### Current behavior before PR:
When generating E-Archive invoices, Odoo includes extra nodes such as
`registration_address_vals`, `registration_name`, and `company_id`
under the `PartyTaxScheme` element. Nilvera’s validation fails if
these nodes are present while no tax office is configured. At the same
time, the TR value for `invoice_edi_format` was using the wrong name,
which caused inconsistencies. These issues result in blocking
validation errors on Nilvera’s side and prevent the invoices from
being accepted.  

### Desired behavior after PR is merged:
After this fix, the `PartyTaxScheme` is cleaned up only to include the
expected XML structure:

```xml
<cac:PartyTaxScheme>
    <cac:TaxScheme>
        <cbc:Name>TAX OFFICE NAME</cbc:Name>
    </cac:TaxScheme>
</cac:PartyTaxScheme>
```
And the invoice_edi_format selection name for TR will be corrected
to display Türkiye rather than Turkyie.

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

Forward-Port-Of: odoo/odoo#223770

*=website

Target: 17.0 to saas-18.3

Issue: 
This issue applies to any block where multiple backgrounds are present (gradient + image).

Steps to Reproduce:
1. Drop a masonry snippet onto the page.
2. Select a block and change the background color to the gradient.
3. Add background image.
3. Change the image position from "Cover" to "Repeat Pattern."
4. Observe the traceback in the console.

Reason:
The issue occurred due to incorrect parsing of CSS background values when multiple background layers were applied (e.g., a gradient + image). When both are set, the element ends up with multiple background-related properties. Previously, In setValue method, Inside MultiUserValueWidget when value = "100px, 100px", the resulting values array was ['100px,', '100px'], which included an extra comma. This has now been corrected to properly handle such cases.

Other edge cases fixed:
1. Gradient was repeating along with the image.
2. Switching to parallax after repeat-pattern causes gradient to repeat.
3. Removing image kept repeat class, causing gradient to repeat.

Fix Summary:
1. We updated `selectStyle` and _computeWidgetState to correctly handle multi-layer background-size and repeat styles.
In selectStyle, we set the height and width values from options and apply them only to the image layer (not gradient), keeping the gradient layer unchanged.
In `_computeWidgetState`, we fetch the background-size from the target and, if multiple layers are present, return only the first one (image layer), since height and width options apply only to that. Now, setValue receives only single-layer values like
`100px 50px`, ensuring correct behavior.
Set background-size 'cover' to gradient which ensures only the image
repeats while the gradient remains fixed.
2. Remove `o_bg_img_opt_repeat` and reset background-size when
   - Image is removed.
   - Switching to parallax.
   
task-4577864

Forward-Port-Of: odoo/odoo#207757

## Short functional explanation of the error
For Dutch companies, when downloading the NLCIUS file of an invoice, the schemeID of the companyID in the XML isn't correct.

## Reproduction Steps
1. Make sure you use a dutch company: in apps, download the 'l10n_nl' and 'account_edi_ubl_cii' modules. Then, click on your company and select the NL Company.
2. Go to settings and type Peppol. Under Customer Invoices, check the Peppo format. Then, setup a Peppol Endpoint. Hit save.
3. Go to the Accounting app and click on the customers tab, then invoices. Click on new.
4. Select a customer. Make sure that the customer is from the Netherlands, has an email address, and in the accounting tab, an account number. Still in the accounting tab, under Electronic Invoicing, set the format at NLCIUS, set a Peppol e-address and a Peppol Endpoint that is 20 characters long.
5. Add a product, click confirm then Send & Print. Make sure that NLCIUS is well checked and click again Send & Print.
6. In the bottom right corner of the page, just under the Amount Due, there's a paper clip icon. Click on it and you'll see the XML. Download it.

### Expected behavior
As the CompanyID is 20 characters long, the schemeID next to the CompanyID should have the value of 0190.

### Unexpected behavior
If you scroll a bit, you'll see that the SchemeID next to the CompanyID has a number of 0106.

## Origin of the issue
In the code, the SchemeID will have a value of 0190 if the CompanyID is 9 characters long.

__
opw-4943262



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

Forward-Port-Of: odoo/odoo#219771
Forward-Port-Of: odoo/odoo#219424

**Issue**:
* Amounts were exactly doubled in 'Current financial investments' (line 12500) in the Spanish Balance Sheet - SMEs report as account codes 551 and 5525 were incorrectly included in balance_pymes_line_12500_sub_balances formula


**Root Cause**:
* Account codes 551 and 5525 were included in BOTH:
  1. Line 12500 sub_balances (unfiltered account_codes expression)
  2. Line 12500 sub_debits (domain expression with sum_if_pos filter)
* This double-counting within the same line caused financial investment amounts 
  to appear twice in the balance sheet
  
**How to Reproduce**:
1. Create Spanish company with 'es_pymes' chart of accounts
2. Post journal entries to accounts 551 or 5525 (current financial investments)
3. Generate 'Balance Sheet - SMEs (ES)' report
4. Observe amounts in line 'V. Current financial investments' are exactly 
   doubled compared to account balances
5. Click on the doubled amount - shows underlying transactions sum to half the amount

**Fix**:
* Removed account codes 551 and 5525 from balance_pymes_line_12500_sub_balances
* These accounts are properly handled by the  sub_debits expression
* Each account is now counted only once within the line
  
opw-4983300

### Steps to reproduce:
- Install l10n_br_edi, switch to Brazilian company
- Set up Avalara
- Create an invoice with the tax "ICMS Exemption Incl." which is included in price
- Click "Generate taxes" to compute the taxes with Avalara
- In "Journal Items" we can see a line for "ICMS Exemption Incl.", its value appear as excluded

### Cause:
The result from Avalara included a value for this tax:
```
'tax': 1.44,
'taxImpact': {
	'accounting': 'none',
	'impactOnFinalPrice': 'Included',
	'impactOnNetAmount': 'Included',
},
```
But the untaxed amount is computed without this tax. Odoo keeps the untaxed amount from the response and add a line for the tax. As a result the tax is added to the amounts like an excluded tax would.

### Solution:
In the response from Avalara, we don't want to create a line for the tax `icmsDeson` when there is `'accounting': 'none'`.

We also log this tax in the chatter to keep a trace of it.

opw-4964315

Forward-Port-Of: odoo/enterprise#91940