This commit implements a way for user to manually set a default value
for the `invoice_cash_rounding_id` field in moves, and apply by default
a standard `account.cash.rounding` record based on the found `ir.default`
record or the ISO-4217 standard for every available currency.

It adds 5 new `account.cash.rounding` record included on the data of the
`account` module. They're set with the 'biggest_tax' strategy so that
the user doesn't need to add required account data on the fields.

We use the `ir.default` object to store the "preferred" default value of
the move rounding field. The rounding field will also be computed to
make sure it gets filled with the default value. An override on
`default_get` is needed so that the default `ir.default` behavior does
not interferre with the compute and making sure the rounding field gets
computed correctly.

To set a preferred `ir.default` on the cash rounding field, the user
must create a new record on "User-Defined Defaults" menu, select the
cash rounding, fill the JSON value with the rounding record ID, and fill
either the company field and/or the condition string with
"currency=<currency_name>" (e.g. "currency=USD"). When searching through
the `ir.default` records to apply, the code will by priority search
through the record sorted by:

- company and currency condition filled
- currency condition filled
- company filled

By default, 3 `ir.default` record are created when installing `account`
module as an exception to the ISO-4217 standard in Odoo for the currency
of IDR, INR, and CHF.

An options for digits is added on the rounding field in the
`account.cash.rounding` list and form view, to make sure the additional
decimal points are shown (it's set to hide anything smaller than 2
digits behind the decimal separator)

In master (18.1), an additional preferred default value for the rounding
field will be saved on the partner of the move, and will be made a
priority over all current `ir.default` for this rounding field.

task-id: 4338116

When sending an email to an invoice mail alias without valid
attachment, a custom bounce mail is sent to inform the customer
that it was bounced because of a missing attachment.

Currently, the bounce email from will default to the bounce alias
of the main company of the DB.

In a multi company setup, where each company might have their own
mail alias domain, this can be confusing for the receiving party
that didn't send the original email to the main company's alias domain.

## Proposed solution:
We call `_routing_create_bounce_email` with the right
company in the context, since the journal company
is already detected.
Additionally, in the context of the accounting code
calling the bounce private method, we pass an explicit value  for `reply_to`

## How to reproduce it:
1) Set up DB with two companies (companyA and companyB). Install account.
2) Set up two mail alias domains (companya.com and companyb.com)
3) Send an email to the invoice alias of companyB (e.g. invoices@companyb.com).
-> bounce email will have FROM as "notifications@companya.com" (the notifications alias
of companyA)

Example headers before:
```
Reply-To: "YourCompany" <catchall@companya.com>
To: customer@example.com
Date: Thu, 02 Jul 2026 11:18:49 -0000
Return-Path: bounce@companya.com
From: "MAILER-DAEMON" <bounce@companya.com>
```
After fix:
```
Reply-To: info@companyb.com
To: customer@example.com
Date: Thu, 02 Jul 2026 11:16:19 -0000
Return-Path: bounce@companyb.com
From: "MAILER-DAEMON" <notifications@companyb.com>
```

opw-6342778

Issue:
- After confirming a sale order with a reward applied (e.g. an ewallet reward), unlocking it, and editing it so the reward line's cost changes (e.g. adding a product and re-claiming the reward), the coupon's point balance updates correctly.
- However, the corresponding loyalty.history record's used value is never refreshed, so it keeps showing the old cost instead of the new one.

Steps to reproduce:
- Enable Loyalty and Lock Confirmed Sales in Sales settings.
- Create an ewallet type loyalty.program and generate an ewallet for a partner with e.g. 1000 points.
- Create a sale order for that partner, add a product worth 100, and claim the ewallet reward (reward line created with points_cost = 100).
- Confirm the order. loyalty.history shows used = 100 (correct), card balance shows 900 (correct).
- Unlock the order, add a second product worth 100, and claim the reward again (same reward line updates to points_cost = 200).
- Lock the order again.
- Check the loyalty.card: balance is correctly 800.
- Check loyalty.history for that order: used still shows 100 instead of 200.

Fix:
- Updated _update_loyalty_history() in sale_order.py to create a new history line if none exists 
  for the given card and order combination.
- Updated write() in sale_order_line.py to correctly sync history lines when a reward line is 
  modified on a confirmed order, handling both same-coupon updates via delta and coupon 
  changes by subtracting the old coupon cost and adding the new one separately.
- Added test_loyalty_history_created_on_post_confirm_reward to verify that a history line is created 
  when a reward is claimed on a confirmed order where no history line existed before.
- Added test_loyalty_history_updated_on_points_cost_write to verify that history.used is updated by the 
  correct delta when points_cost changes on a reward line of a confirmed order.

Impact:
- Ensures a coupon's usage history stays accurate after a confirmed order is unlocked and edited.
- Prevents the loyalty.history used field from silently going stale while the actual point balance is correct.
- Not scoped to ewallet specifically — since points_cost semantics are the same across program types, this also corrects the same class of staleness for other reward types (discount, gift_card, etc.) when a reward line's cost changes post-confirmation.

When matching Purchase Order lines with Vendor Bill lines from the Bill Matching view,
if a PO and its vendor bill each contain several lines for the same product,
all bill lines of that product get matched to the first PO line only.
The remaining PO line(s) stay unmatched and are then added back
to the bill as new (duplicate) lines.

Steps:

- Create a purchase order with two lines for the same product and confirm
- Create a draft bill with the same configuration and same partner
- From the PO, click on "Bill matching" button
- Select the 4 lines and click on the "Match" button
-> On the purchase order, first line has qty_invoiced == 2 and the
   second one 0
-> On the bill, there is an additional line with 0 quantity

This is because we only match the first order line in case of having more than
one line with the same product. Then we add the remaining order lines to
the bill.
With this commit we match each line that need to be matched and we add
lines to the bill only if all order lines have been invoiced.

opw-6279755

When sending a batch of invoice, we first generate an unique PDF file regrouping every invoice.
When at least one invoice needs more than one page to be rendered entirely, the number of pages will
be greater than the number of invoices.

In this case, we use <hX> tags to split invoices:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/odoo/addons/base/models/ir_actions_report.py#L916-L923

This tag is added for PDF files, using the invoice's title:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/web/views/report_templates.xml#L627

In some localization modules, this title shouldn't be displayed and it is removed. Example for Chile:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/l10n_cl/views/report_invoice.xml#L149

In this case, no `<h3>` tag will be added and an error is raised as we cannot separate invoices.

We propose to add an empty `<h3>` tag if the
document title is not defined.

opw-6281187

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

Translatable rows that are identified by a stable key rather than by
their text (e.g. selection option labels in ir.model.fields.selection,
and other module-reflected metadata written through upsert_en()) can
have their English source text changed by a module upgrade while
keeping the same key. For example product.template's selection value
'consu' went from meaning "Consumable" to meaning "Goods" between 17.0
and 18.0, without the stored value itself changing.

In that situation, upsert_en() always refreshes the 'en_US' entry from
the current code, so English is never wrong. But every other language
keeps whatever value it had, since upsert_en() blindly merges the new
'en_US' entry into the existing jsonb without checking whether the
previous 'en_US' value actually changed. When the module's .po file is
later reloaded, TranslationImporter.save() finds a non-empty value
already there for each language and, by design, does not overwrite it
unless explicitly asked to (`overwrite`) on a record that isn't
`noupdate`. That protection is correct when the English text hasn't
changed (it keeps manual translation customizations across upgrades),
but here it ends up protecting a translation of a source string that
no longer exists.

As a result, a value whose meaning changes across versions keeps
showing its old label in every language except English, forever,
unless someone forces a translation overwrite.

Fix this in upsert_en() itself: when the incoming 'en_US' value
differs from the one currently stored, drop every other language
already stored for that row instead of merging into it. Those
translations were made for a source string that no longer exists, so
there is nothing worth protecting. Once dropped, they are simply
missing from the jsonb, so TranslationImporter.save() naturally lets
the freshly (re)loaded translations in on its next run, without needing
to know anything about source drift, and `overwrite`/`noupdate` keep
their exact original meaning for every other case.

Task-6333080


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

Forward-Port-Of: odoo/odoo#275080

Steps to reproduce:
==================
1. Add a Donation snippet on a page
2. Click "Donate Now"
3. Switch the website language on the payment page

=> Configured amounts/descriptions disappear

Cause:
======
The donation snippet posts its configuration (prefilled amounts, display options, descriptions) in the request body. If the user switches the website language on the payment page, it triggers a page reload via a GET request which drops the original form body (this also applies to a simple page refresh). As a result, the kwargs were empty and the page fell back to the default free-amount input, losing the configured options.

Solution:
=========
Implement Post/Redirect/Get: on POST, redirect to /donation/pay with the options in the query string so any later GET (language switch, refresh, iframe src reload) re-renders a fully configured page without losing data.

Alternative Solution:
=====================
We could also store the options in the session, but the current solution is much simpler and avoids session pollution.

opw-6282391

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

### [FIX] web: fix mocked dates in tests

Dates are mocked in all unit tests by default; either to a default static
value, or to one defined in the test/suite. To do so, the `window.Date`
constructor is overridden to have the arguments auto-filled with the current
mock date paramters.

Before this commit, an additional offset was always added to the given
arguments to reflect:
- the time elapsed from the beginning of the test;
- any virtual offset added by a helper such as 'advanceTime'.

The issue is that the spec of the Date constructor wants that the returned date
object has to match all given arguments, and any omitted argument will be
defaulted to the current date/time. This was not the case in tests, as the
offset was always added, regardless of the given arguments.

With this commit: only the arguments that are NOT given and that have been
defaulted to current (mocked) date/time will be offset by the adequate value.
Furthermore: as these mocked parameters are meant to reflect UTC values, the
offset now also considers the *actual* browser offset to generate a local date
from the mock date parameters.

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

**Steps to reproduce:**
1. Create a Sales Order.
2. Create a 50% down payment invoice.
3. Create a credit note for the down payment invoice.
4. Reset the credit note to Draft and cancel it.
5. Create the final invoice from the Sales Order.

**Issue:**
The final invoice is generated for 100% of the order amount, acting as if the down payment invoice does not exist.

**Expected behavior:**
The final invoice should only include the remaining 50% of the order amount because a valid 50% down payment invoice still exists.

**Why this happens:**
- The `price_unit` on the Sales Order's down payment line is manually updated during `action_post()` based on the sum of posted invoices minus posted credit notes.
- When the credit note is posted, `price_unit` drops to 0. However, when that credit note is subsequently reset to draft and cancelled, it triggers `button_cancel()` which only refreshed the line's display name and failed to recalculate `price_unit`. As a result, `price_unit` remained at 0 even though the credit note was no longer active, causing the final invoice to deduct nothing.

opw-6373578

The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself.

Steps to reproduce:
- Enable Sale Credit Limit in the settings of My Company (San Francisco)
- Set a Credit Limit of 100 on a customer, e.g. Deco Addict
- Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected
- Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies
- Open the same quotation again => The warning banner is gone, although neither the quotation nor the
   customer changed

The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one.

Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company.

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

Forward-Port-Of: odoo/odoo#276308