**Issue 1:**

Steps to reproduce:
- Install the `l10n_ar` module.
- Go to Customers and create a new customer with the country set to Argentina.
- Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`.

**Error:**
`ValueError: invalid literal for int() with base 10: '1234567890a'`

**Issue 2:**
- Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`.
- Set `Identification Number` to `1234567890a`.

**Observation:**
All non-digit characters are stripped, and the identification number is 
silently changed to `1234567890`.

**Expected behaviour:**
Any Identification Type other than CUIT (80), CUIL (86), and DNI (96)
should be kept unchanged without stripping alphabetic characters.

**Root Cause:**
At [1], `_get_id_number_sanitize` sanitizes identification numbers
based on the selected Identification Type.

- For `CUIT` and `CUIL`, `stdnum.ar.cuit.compact()` only removes 
  separators (e.g., spaces and dashes). If the identification number
  contains alphabetic characters, they are preserved and called `int()` 
  on the resulting value, raising a `ValueError`.
- For all other identification types, valid alphanumeric values are
  unintentionally modified by stripping non-digit characters.

**Fix:**
This commit validates identification numbers before sanitization for
`CUIT` (80), `CUIL` (86), and `DNI` (96), ensuring only valid numeric
identification numbers are converted. For all other identification
types, it preserves alphanumeric characters by removing only
non-alphanumeric separators.

[1]:
https://github.com/odoo/odoo/blob/08b75d753c638e9d2d7418b55e9107bda471cb31/addons/l10n_ar/models/res_partner.py#L124-L136

Related enterrpise PR: https://github.com/odoo/enterprise/pull/123729

opw-6333998

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

Forward-Port-Of: odoo/odoo#269100

For a logged-in user, some form fields are automatically prefilled from
their profile, such as a "Phone" field with their phone number.

**Issue:**
The prefill configuration is always preserved when we change options of
a field. While this is correct when updating few options, but it also
happens after the field is repurposed, causing it to inherit a prefill
value intended for a different field.

**Steps to reproduce:**
- Edit the /contactus page's form.
- Change the "Name" field's type to a "URL" or "CC" field.
- Save the changes.
- The "URL/CC" field is prefilled with the user's name.

A field is considered repurposed when:
- its type is changed (e.g. from "Phone" to "URL");
- a custom field is converted into an existing field.

**Fix:**
This commit preserves the prefill only when the field keeps the same
name and type. Otherwise, it clears the stale prefill so repurposed
fields no longer inherit incorrect values.

task-[5976747](https://www.odoo.com/odoo/project/974/tasks/5976747)

Forward-Port-Of: odoo/odoo#275812

### [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

Forward-Port-Of: odoo/odoo#275391

Before this commit:
- When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`.
- In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. 
- In such situations, Odoo incorrectly imports the document as a credit note.

Technical reason:
- The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund.

After this commit:
- **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note.
- Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes.

Task-6321262

Forward-Port-Of: odoo/odoo#275994
Forward-Port-Of: odoo/odoo#271829

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.

Forward-Port-Of: odoo/odoo#273688

**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

Forward-Port-Of: odoo/odoo#275684

Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked.

Steps to reproduce:
- in a multi-company database, create a product tracked by lots
- create a lot with the same name for that product in each company
- create one receipt per company with that lot name typed in the detailed operations, select both receipts in the Transfers list view and validate them together

The lines of one company are linked to the lot of the other company and the validation is blocked by "Incompatible companies on records". When the lot only exists in one of the companies, the search misses it and the validation fails on the lot uniqueness constraint while recreating a lot that 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#276688