Error-1 :
```
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system:
account.1_l10n_id_domestic_fiscal_position
```

Error-2 :
```
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: account.1_tax_luxury_sales
```

Reason-1 :
- In [this](https://github.com/odoo/odoo/commit/e342a45aceb60b44052c5d52e9ecc35a9a7340da) commit new account.fiscal.positions were added and linked to acc.tax using fiscal_position_ids .
- In [this](https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_id/migrations/1.3/end-migrate_update_taxes.py) migration script, while creating taxes it didnt find fiscal positions, so need to create them first.

Reason-2 :
- original_tax_ids was also added in same commit, if client deleted those tax(ie tax_luxury_sales) will fail while creating `tax_luxury_sales_pemungut_ppn`, It needs to be created first too.

- upg : [4341887](https://upgrade.odoo.com/odoo/upgrade.request/4341887)
- opw : [6285978](https://www.odoo.com/odoo/project/70/tasks/6285978)

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

Forward-Port-Of: odoo/odoo#269802

Currently, an error occurs when installing the hr_holidays_attendance module.

**Steps to Reproduce:**
 - Install the `hr_attendance` module without demo data.
 - Go to `Attendance` > `Configuration` > `Overtime Rulesets` and open the `Default Ruleset` record.
 - Delete its `linked overtime rules`.
 - Install the `hr_holidays_attendance` module.
 
 **Error:**
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'

odoo.tools.convert.ParseError: while parsing /home/odoo/odoo18/community/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml:7, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
            <field name="compensable_as_leave" eval="True"/>
        </record>
```
This error occurs when the user deletes all overtime rules and then installs the hr_holidays_attendance 
module. During installation, the module attempts to update the deleted overtime rule records, 
which raises an error [1].

This commit uses forcecreate="0" to skip updating records if the corresponding overtime 
rules do not exist.

[1]- https://github.com/odoo/odoo/blob/da0a83761f38ee4a2940015b6c8f7190c310a4a0/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml#L7-L12

sentry-7372074675

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

Forward-Port-Of: odoo/odoo#279088
Forward-Port-Of: odoo/odoo#277656

With pos_hr enabled, the cash in/out popup uses the cashier's `work_contact_id` as partner for the `account.bank.statement.line`. When that partner is archived or not part of the limited partner loading, the relation cannot be resolved in the frontend and the statement line is created with `partner_id = False`.

Deleting such a cash move then crashes in `delete_cash_in_out`:

    File ".../point_of_sale/models/pos_session.py", line 1877, in delete_cash_in_out
        action = cashier_name + ': ' + str(amount)
    TypeError: unsupported operand type(s) for +: 'bool' and 'str'

Steps to reproduce:
- Enable "Multi Employees per Session" (pos_hr) on a PoS config
- Archive the work contact of an employee, or make sure it is not included in the limited partner loading
- Open a session, log in as that employee and register a cash in/out
- As a manager, delete the cash move from the cash move list => Traceback, the cash move cannot be deleted

opw-6389830

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

Forward-Port-Of: odoo/odoo#278462
Forward-Port-Of: odoo/odoo#276598

### Issue:
When importing EDI documents such as Peppol files, Swiss VAT numbers may be formatted or unformatted
When `base_vat` is installed, VAT is stored formatted in Odoo (e.g. `CHE-530.781.296 TVA`)
If the format differs, the matching fails and a new partner is created at each import

### Cause:
`_retrieve_partner` lacked Swiss-specific VAT normalization logic in `_get_country_specific_vat_variants`, causing it to miss formatted variants with language suffixes (`TVA`, `MWST`, `IVA`)

Even when the match succeeded, `_import_ubl_create_missing_customer` still compared VAT strings without stripping `-` and lang suffixes for CH partners, causing a false mismatch and triggering partner creation anyway

### Notes:
The partner match improvement is backported from 18.3: https://github.com/odoo/odoo/commit/f1a5a3d72a26ee471d2ef1d8034136208b2bcebc
The original fix was incomplete — it added `_get_country_specific_vat_variants` but missed the VAT comparison fix in `_import_ubl_create_missing_customer`, allowing the issue to persist after a successful match
`base_vat` is required to get the fix fully working

### Steps to reproduce:
- Install `account` and `base_vat`
- Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA)
- Import a [Peppol Bill](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) with VAT `CHE530781296TVA`

Before the fix, a new partner is created instead of matching the existing one

opw-6353387

Forward-Port-Of: odoo/odoo#279184
Forward-Port-Of: odoo/odoo#274398

Error-1 :
```
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system:
account.1_l10n_id_domestic_fiscal_position
```

Error-2 :
```
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: account.1_tax_luxury_sales
```

Reason-1 :
- In [this](https://github.com/odoo/odoo/commit/e342a45aceb60b44052c5d52e9ecc35a9a7340da) commit new account.fiscal.positions were added and linked to acc.tax using fiscal_position_ids .
- In [this](https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_id/migrations/1.3/end-migrate_update_taxes.py) migration script, while creating taxes it didnt find fiscal positions, so need to create them first.

Reason-2 :
- original_tax_ids was also added in same commit, if client deleted those tax(ie tax_luxury_sales) will fail while creating `tax_luxury_sales_pemungut_ppn`, It needs to be created first too.

- upg : [4341887](https://upgrade.odoo.com/odoo/upgrade.request/4341887)
- opw : [6285978](https://www.odoo.com/odoo/project/70/tasks/6285978)

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

Forward-Port-Of: odoo/odoo#269802

Currently, an error occurs when installing the hr_holidays_attendance module.

**Steps to Reproduce:**
 - Install the `hr_attendance` module without demo data.
 - Go to `Attendance` > `Configuration` > `Overtime Rulesets` and open the `Default Ruleset` record.
 - Delete its `linked overtime rules`.
 - Install the `hr_holidays_attendance` module.
 
 **Error:**
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'

odoo.tools.convert.ParseError: while parsing /home/odoo/odoo18/community/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml:7, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
            <field name="compensable_as_leave" eval="True"/>
        </record>
```
This error occurs when the user deletes all overtime rules and then installs the hr_holidays_attendance 
module. During installation, the module attempts to update the deleted overtime rule records, 
which raises an error [1].

This commit uses forcecreate="0" to skip updating records if the corresponding overtime 
rules do not exist.

[1]- https://github.com/odoo/odoo/blob/da0a83761f38ee4a2940015b6c8f7190c310a4a0/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml#L7-L12

sentry-7372074675

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

Forward-Port-Of: odoo/odoo#279088
Forward-Port-Of: odoo/odoo#277656

### Issue:
When importing EDI documents such as Peppol files, Swiss VAT numbers may be formatted or unformatted
When `base_vat` is installed, VAT is stored formatted in Odoo (e.g. `CHE-530.781.296 TVA`)
If the format differs, the matching fails and a new partner is created at each import

### Cause:
`_retrieve_partner` lacked Swiss-specific VAT normalization logic in `_get_country_specific_vat_variants`, causing it to miss formatted variants with language suffixes (`TVA`, `MWST`, `IVA`)

Even when the match succeeded, `_import_ubl_create_missing_customer` still compared VAT strings without stripping `-` and lang suffixes for CH partners, causing a false mismatch and triggering partner creation anyway

### Notes:
The partner match improvement is backported from 18.3: https://github.com/odoo/odoo/commit/f1a5a3d72a26ee471d2ef1d8034136208b2bcebc
The original fix was incomplete — it added `_get_country_specific_vat_variants` but missed the VAT comparison fix in `_import_ubl_create_missing_customer`, allowing the issue to persist after a successful match
`base_vat` is required to get the fix fully working

### Steps to reproduce:
- Install `account` and `base_vat`
- Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA)
- Import a [Peppol Bill](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) with VAT `CHE530781296TVA`

Before the fix, a new partner is created instead of matching the existing one

opw-6353387

Forward-Port-Of: odoo/odoo#279184
Forward-Port-Of: odoo/odoo#274398

With pos_hr enabled, the cash in/out popup uses the cashier's `work_contact_id` as partner for the `account.bank.statement.line`. When that partner is archived or not part of the limited partner loading, the relation cannot be resolved in the frontend and the statement line is created with `partner_id = False`.

Deleting such a cash move then crashes in `delete_cash_in_out`:

    File ".../point_of_sale/models/pos_session.py", line 1877, in delete_cash_in_out
        action = cashier_name + ': ' + str(amount)
    TypeError: unsupported operand type(s) for +: 'bool' and 'str'

Steps to reproduce:
- Enable "Multi Employees per Session" (pos_hr) on a PoS config
- Archive the work contact of an employee, or make sure it is not included in the limited partner loading
- Open a session, log in as that employee and register a cash in/out
- As a manager, delete the cash move from the cash move list => Traceback, the cash move cannot be deleted

opw-6389830

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

Forward-Port-Of: odoo/odoo#278462
Forward-Port-Of: odoo/odoo#276598

The AutoComplete component wraps a text input that already renders its
own suggestion dropdown, so the browser's native suggestions must stay
out of the way. In 12/2024 in this commit [1] the input's autocomplete
was switched from `off` to `new-password` on the premise that `off` is
not respected by browsers. In 02/2025, in this commit [2] then made it
the component default so many2x pickers stay clean.

Chrome runs two independent suggestion mechanisms, and each attribute
silences only one of them:
- `off` is ignored when the input has a name and Chrome holds autofill
  (address) data for it.
- `new-password` is ignored when Chrome offers "frequently used values",
  i.e. the form-history dropdown. [3]

So `new-password` does not always work. It only stays hidden while the
field is ineligible for those suggestions. A field becomes eligible as
soon as it gains an `id` and an associated `<label>`. On `saas-19.3`
this is provable on commit [4] where adding a prefix icon gave the link
popover URL input an `id` + `<label for>`, and the native dropdown
resurfaced over the custom URL/page suggestions.

This branch targets `saas-18.4`, where the regression is NOT
reproducible because that URL input has no `id`/`label` yet. The fix is
applied here anyway to avoid the gap that any later `label`/`id`
addition re-exposes (as commit [4] proved), and the fix can be forward
ported to `saas-19.3`.

The website editor's URL field implements autocomplete without the
`AutoComplete` component, so the default does not reach it. so
`autocomplete="off"` is set directly on that input.

[1]: https://github.com/odoo/odoo/commit/9c0f5612
[2]: https://github.com/odoo/odoo/commit/2980694b (opw-4551051)
[3]: https://issues.chromium.org/issues/41163264#comment30
[4]: https://github.com/odoo/odoo/commit/2b4d04d1 (task-6034288)

task-6370552

Forward-Port-Of: odoo/odoo#279203
Forward-Port-Of: odoo/odoo#277501

Steps to reproduce
---
1. Confirm a purchase order and receive it a few days later.
2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure.

Observed: the value is counted from the line's scheduled date instead of the order date, and can even be negative when the scheduled date precedes the confirmation date.

Issue
---
The metric is meant to be the effective lead time, the number of days between the order confirmation and the actual receipt, falling back to the planned "days to receive" when nothing has
been received yet according to [task](https://www.odoo.com/odoo/project/809/tasks/3691573).
The query instead computes age(date_planned, COALESCE(date_done, date_order)), so once a receipt exists it returns date_planned - date_done (the gap between the
scheduled date and the receipt) rather than date_done - date_order.
https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/purchase_stock/report/purchase_report.py#L20-L28

opw-6226523

Forward-Port-Of: odoo/odoo#279267
Forward-Port-Of: odoo/odoo#268843

While preloading chart template data, if an account already exists in the db but has `active=False`, it is not found because archived records are excluded from the [`_search`].

As a result, the load attempts to create a new account. During creation, the Python constraint [`_ensure_code_is_unique`] searches with `active_test=False`, finds the archived account with the same code, and raises a ValidationError:
```py
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/chart_template.py", line 735, in _load_data
    'noupdate': True,
                     ^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 4519, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 4426, in _load_records_create
    records = self.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/account/models/account_account.py", line 1057, in create
    records._ensure_code_is_unique()
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_account.py", line 1135, in _ensure_code_is_unique
    raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 1.1.1.02.003, 1.1.1.02.004
```

Steps to reproduce:
- In a `v19.0` database, install `l10n_ar` with demo data.
- The accounts with codes `1.1.1.02.003` and `1.1.1.02.004` are created by [`_create_outstanding_accounts`].
- Archive those accounts and upgrade to `v19.2`.
- During the upgrade, [`_get_latam_check_outstanding_account_account`] attempts to create new accounts with the same codes, triggering the duplicate code validation.

tbg-2840

[`_search`]: https://github.com/odoo/odoo/blob/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd/addons/account/models/chart_template.py#L438
[`_ensure_code_is_unique`]: https://github.com/odoo/odoo/blob/19.0/addons/account/models/account_account.py#L1133
[`_create_outstanding_accounts`]: https://github.com/odoo/odoo/blob/06a46b083fde5688d71c5602553316c9e7160b6a/addons/account/models/chart_template.py#L925C9-L949
[`_get_latam_check_outstanding_account_account`]: https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_latam_check/models/account_chart_template.py#L60-L76



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

Forward-Port-Of: odoo/odoo#279313
Forward-Port-Of: odoo/odoo#279092

**Problem:**
When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.

**Steps to reproduce:**
1. Create a new task and select a project that has a customer.
2. The Customer is set to that project's customer.
3. Select another project configured with a different customer.
4. Observe the Customer keeps the first project's customer.

**Current behavior:**
The Customer keeps the first selected project's customer.

**Expected behavior:**
The Customer follows the selected project and shows its customer.

**Cause of the issue:**
partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer.

**Fix:**
Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes.

opw-6315902

Forward-Port-Of: odoo/odoo#278526
Forward-Port-Of: odoo/odoo#276211

**Steps to reproduce:**
- Install website_forum
- Create a new post on the forum with the admin
- Subscribe to the post notifications using the bell button
- Create a new portal user and give him 5 karma
    (to give him enough rights to answer and comment)
- Connect with the portal user and go to the post
- Create an answer
- Try to comment on your own answer
- AccessError is raised

**Issue:**
Since [1] we check comodel access (in this case `res.partner`) when adding records. Here during the `message_post` the `question_followers` are added manually as `partner_ids` before sending (the logic only relies on the original post subscribers, not on the added comment/reply).

```py
question_followers = self.env['mail.followers'].sudo().search([
    ('res_model', '=', self._name),
    ('res_id', '=', self.parent_id.id),
    ('partner_id', '!=', False),
]).filtered(lambda fol: comment_subtype in fol.subtype_ids).mapped('partner_id')
partner_ids += question_followers.ids
```

As the portal user has no `read` access to the subscribers the message creation fails with a traceback.

**Fix:**
Add `sudo` to the `message_post` call of `post_comment`.

[1] https://github.com/odoo/odoo/commit/aae732957c3c3b3590f5686cfccc0ab264d0b5c9

opw-5318757

Forward-Port-Of: odoo/odoo#278840
Forward-Port-Of: odoo/odoo#274751

### Issue:
When importing EDI documents such as Peppol files, Swiss VAT numbers may be formatted or unformatted
When `base_vat` is installed, VAT is stored formatted in Odoo (e.g. `CHE-530.781.296 TVA`)
If the format differs, the matching fails and a new partner is created at each import

### Cause:
`_retrieve_partner` lacked Swiss-specific VAT normalization logic in `_get_country_specific_vat_variants`, causing it to miss formatted variants with language suffixes (`TVA`, `MWST`, `IVA`)

Even when the match succeeded, `_import_ubl_create_missing_customer` still compared VAT strings without stripping `-` and lang suffixes for CH partners, causing a false mismatch and triggering partner creation anyway

### Notes:
The partner match improvement is backported from 18.3: https://github.com/odoo/odoo/commit/f1a5a3d72a26ee471d2ef1d8034136208b2bcebc
The original fix was incomplete — it added `_get_country_specific_vat_variants` but missed the VAT comparison fix in `_import_ubl_create_missing_customer`, allowing the issue to persist after a successful match
`base_vat` is required to get the fix fully working

### Steps to reproduce:
- Install `account` and `base_vat`
- Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA)
- Import a [Peppol Bill](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) with VAT `CHE530781296TVA`

Before the fix, a new partner is created instead of matching the existing one

opw-6353387

Forward-Port-Of: odoo/odoo#279184
Forward-Port-Of: odoo/odoo#274398

With pos_hr enabled, the cash in/out popup uses the cashier's `work_contact_id` as partner for the `account.bank.statement.line`. When that partner is archived or not part of the limited partner loading, the relation cannot be resolved in the frontend and the statement line is created with `partner_id = False`.

Deleting such a cash move then crashes in `delete_cash_in_out`:

    File ".../point_of_sale/models/pos_session.py", line 1877, in delete_cash_in_out
        action = cashier_name + ': ' + str(amount)
    TypeError: unsupported operand type(s) for +: 'bool' and 'str'

Steps to reproduce:
- Enable "Multi Employees per Session" (pos_hr) on a PoS config
- Archive the work contact of an employee, or make sure it is not included in the limited partner loading
- Open a session, log in as that employee and register a cash in/out
- As a manager, delete the cash move from the cash move list => Traceback, the cash move cannot be deleted

opw-6389830

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

Forward-Port-Of: odoo/odoo#278462
Forward-Port-Of: odoo/odoo#276598

The AutoComplete component wraps a text input that already renders its
own suggestion dropdown, so the browser's native suggestions must stay
out of the way. In 12/2024 in this commit [1] the input's autocomplete
was switched from `off` to `new-password` on the premise that `off` is
not respected by browsers. In 02/2025, in this commit [2] then made it
the component default so many2x pickers stay clean.

Chrome runs two independent suggestion mechanisms, and each attribute
silences only one of them:
- `off` is ignored when the input has a name and Chrome holds autofill
  (address) data for it.
- `new-password` is ignored when Chrome offers "frequently used values",
  i.e. the form-history dropdown. [3]

So `new-password` does not always work. It only stays hidden while the
field is ineligible for those suggestions. A field becomes eligible as
soon as it gains an `id` and an associated `<label>`. On `saas-19.3`
this is provable on commit [4] where adding a prefix icon gave the link
popover URL input an `id` + `<label for>`, and the native dropdown
resurfaced over the custom URL/page suggestions.

This branch targets `saas-18.4`, where the regression is NOT
reproducible because that URL input has no `id`/`label` yet. The fix is
applied here anyway to avoid the gap that any later `label`/`id`
addition re-exposes (as commit [4] proved), and the fix can be forward
ported to `saas-19.3`.

The website editor's URL field implements autocomplete without the
`AutoComplete` component, so the default does not reach it. so
`autocomplete="off"` is set directly on that input.

[1]: https://github.com/odoo/odoo/commit/9c0f5612
[2]: https://github.com/odoo/odoo/commit/2980694b (opw-4551051)
[3]: https://issues.chromium.org/issues/41163264#comment30
[4]: https://github.com/odoo/odoo/commit/2b4d04d1 (task-6034288)

task-6370552

Forward-Port-Of: odoo/odoo#279203
Forward-Port-Of: odoo/odoo#277501

Steps to reproduce
---
1. Confirm a purchase order and receive it a few days later.
2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure.

Observed: the value is counted from the line's scheduled date instead of the order date, and can even be negative when the scheduled date precedes the confirmation date.

Issue
---
The metric is meant to be the effective lead time, the number of days between the order confirmation and the actual receipt, falling back to the planned "days to receive" when nothing has
been received yet according to [task](https://www.odoo.com/odoo/project/809/tasks/3691573).
The query instead computes age(date_planned, COALESCE(date_done, date_order)), so once a receipt exists it returns date_planned - date_done (the gap between the
scheduled date and the receipt) rather than date_done - date_order.
https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/purchase_stock/report/purchase_report.py#L20-L28

opw-6226523

Forward-Port-Of: odoo/odoo#279267
Forward-Port-Of: odoo/odoo#268843

The AutoComplete component wraps a text input that already renders its
own suggestion dropdown, so the browser's native suggestions must stay
out of the way. In 12/2024 in this commit [1] the input's autocomplete
was switched from `off` to `new-password` on the premise that `off` is
not respected by browsers. In 02/2025, in this commit [2] then made it
the component default so many2x pickers stay clean.

Chrome runs two independent suggestion mechanisms, and each attribute
silences only one of them:
- `off` is ignored when the input has a name and Chrome holds autofill
  (address) data for it.
- `new-password` is ignored when Chrome offers "frequently used values",
  i.e. the form-history dropdown. [3]

So `new-password` does not always work. It only stays hidden while the
field is ineligible for those suggestions. A field becomes eligible as
soon as it gains an `id` and an associated `<label>`. On `saas-19.3`
this is provable on commit [4] where adding a prefix icon gave the link
popover URL input an `id` + `<label for>`, and the native dropdown
resurfaced over the custom URL/page suggestions.

This branch targets `saas-18.4`, where the regression is NOT
reproducible because that URL input has no `id`/`label` yet. The fix is
applied here anyway to avoid the gap that any later `label`/`id`
addition re-exposes (as commit [4] proved), and the fix can be forward
ported to `saas-19.3`.

The website editor's URL field implements autocomplete without the
`AutoComplete` component, so the default does not reach it. so
`autocomplete="off"` is set directly on that input.

[1]: https://github.com/odoo/odoo/commit/9c0f5612
[2]: https://github.com/odoo/odoo/commit/2980694b (opw-4551051)
[3]: https://issues.chromium.org/issues/41163264#comment30
[4]: https://github.com/odoo/odoo/commit/2b4d04d1 (task-6034288)

task-6370552

Forward-Port-Of: odoo/odoo#279203
Forward-Port-Of: odoo/odoo#277501

### Issue:
When importing EDI documents such as Peppol files, Swiss VAT numbers may be formatted or unformatted
When `base_vat` is installed, VAT is stored formatted in Odoo (e.g. `CHE-530.781.296 TVA`)
If the format differs, the matching fails and a new partner is created at each import

### Cause:
`_retrieve_partner` lacked Swiss-specific VAT normalization logic in `_get_country_specific_vat_variants`, causing it to miss formatted variants with language suffixes (`TVA`, `MWST`, `IVA`)

Even when the match succeeded, `_import_ubl_create_missing_customer` still compared VAT strings without stripping `-` and lang suffixes for CH partners, causing a false mismatch and triggering partner creation anyway

### Notes:
The partner match improvement is backported from 18.3: https://github.com/odoo/odoo/commit/f1a5a3d72a26ee471d2ef1d8034136208b2bcebc
The original fix was incomplete — it added `_get_country_specific_vat_variants` but missed the VAT comparison fix in `_import_ubl_create_missing_customer`, allowing the issue to persist after a successful match
`base_vat` is required to get the fix fully working

### Steps to reproduce:
- Install `account` and `base_vat`
- Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA)
- Import a [Peppol Bill](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) with VAT `CHE530781296TVA`

Before the fix, a new partner is created instead of matching the existing one

opw-6353387

Forward-Port-Of: odoo/odoo#279184
Forward-Port-Of: odoo/odoo#274398

When a PoS runs in a currency other than the company currency, product prices are loaded already converted to the PoS currency (`list_price`, `lst_price`, `standard_price` all go through `_convert_pos_data_currency`).

The prices carried by combos were not: `product.combo.base_price` is computed in the combo currency (the company currency) and `product.combo.item.extra_price` is stored in the product currency, but neither was converted when loaded in the PoS. As a result, a product priced at 2 USD (= 80 ZIG) was correctly shown as 80 ZIG on its own, yet appeared as 2 ZIG once it was part of a combo, since the raw amount was displayed as-is in the PoS currency.

Convert `base_price` and `extra_price` from each record's own `currency_id` to the PoS currency at load time, mirroring what is already done for product prices.

Steps to reproduce:
- Set a product to 2 USD and a PoS to a ZIG pricelist (rate 40).
- Open the PoS: the standalone product shows 80 ZIG.
- Add the same product as a combo item: it shows 2 ZIG instead of 80 ZIG.

opw-6410243

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

Forward-Port-Of: odoo/odoo#278330

If one of the Payroll Structure Types has the Scheduled Pay field unset,
opening the Payroll dashboard raises a traceback.

Steps to reproduce the error:
- Install ``hr_payroll`` module
- Go to Payroll > Configuration > Settings > Set Payroll Closing Date > Save
- Go to Payroll > Configuration > Structure Types > Create a new Structure Type > Unset Scheduled Pay
- Open Dashboard

Traceback:
```py
AttributeError: 'bool' object has no attribute 'title'
```

https://github.com/odoo/enterprise/blob/9a3ea83a432f42f62076a50fca6bc771a2de96bf/hr_payroll/models/hr_payroll_warning.py#L413-L419
The dashboard collects the scheduled pay values from all structure types and
later calls ``schedule.title()`` to build the labels. When a Structure Type has
no Scheduled Pay configured, so ``schedule`` becomes ``False``, leading to the traceback.

``_get_schedule_pay`` method can return False at [1],
So, It will generate the traceback from below line also. https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L401

Solution:
Added a fallback value when default scheduled pay is False.

[1]: https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L149-L154

sentry-7583037488

Forward-Port-Of: odoo/enterprise#126127
Forward-Port-Of: odoo/enterprise#122492

Currently, an error occurs when processing Ecuadorian EDI invoices that
use taxes from the `Special Consumptions (ICE)` tax group.

**Steps to reproduce:**
- Install `l10n_ec_edi` and switch to an EC Company.
- Create a new tax with the `Tax Group` set to `Special Consumptions (ICE)`.
- Create an invoice using this tax.
- Confirm the invoice and click `Process Now`.

**Error:**
```
  File "/home/odoo/odoo/enterprise/saas-18.4/l10n_ec_edi/models/account_edi_format.py", line 373, in _l10n_ec_get_base_lines
    code_percentage = L10N_EC_VAT_SUBTAXES[tax_data['tax'].tax_group_id.l10n_ec_type]
KeyError: 'ice'
```

**Root Cause:**
At [1], non-VAT tax groups such as `ICE` are explicitly not supported
and are not included in `L10N_EC_VAT_SUBTAXES`.

At [2], the code assumes that every Ecuadorian tax group exists in
`L10N_EC_VAT_SUBTAXES` and directly indexes the mapping using
`tax_group_id.l10n_ec_type`. When an invoice uses an `ICE`
tax, causing an error.

**Fix:**
This commit prevents errors by using the tax's `Code ATS` as the
`codigoPorcentaje` value and the tax's `amount` as the `tarifa` in
the XML when the tax group is not present in `L10N_EC_VAT_SUBTAXES`.
(Confirm with the PO [here], just to fix it from 18.4, that the problem is 
that it is not working on the versions where we already introduced the feature.)

[1]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_move.py#L17-L38

[2]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_edi_format.py#L372-L377

[here]:
https://www.odoo.com/mail/message/1121493378

opw-6373984
opw-6430589
opw-6423812

Forward-Port-Of: odoo/enterprise#123918

Currently, an error occurs when a user creates a Google Reserve Merchant record.

**Steps to Reproduce:**
 - Install the `appointment_google_reserve` module.
 - Go to `Appointments` > `Configuration` > `Google Booking`.
 - Click `New` to create a record.

`AttributeError: 'website' object has no attribute 'homepage_url'`

After this [recent commit], as part of the context-based website resolution refactoring, the 
`default_website` record is now available even without the `website` module because it is 
created in `base` [1]. When a user creates a Google Reserve Merchant record, it attempts 
to set the default URL using the default website from `base`. However, it then tries to access 
the `homepage_url` field, which is defined in the `website` module [2]. Since the `website` 
module is not installed, this raises the error [3].

This commit ensures that before accessing `homepage_url`, it first checks whether the 
`homepage_url` field exists when creating the merchant record, since this field depends 
on the `website` module.

[recent commit]: https://github.com/odoo/odoo/commit/ae81b6f6074632d1a609387e53f97a61ee6c95f4

[1]: https://github.com/odoo/odoo/blob/ea0e2750a43e337bc6d9a00489a30df3fc0616c7/odoo/addons/base/data/website.xml#L5-L9

[2]: https://github.com/odoo/odoo/blob/ea0e2750a43e337bc6d9a00489a30df3fc0616c7/addons/website/models/website.py#L168

[3]- https://github.com/odoo/enterprise/blob/01b0cf4e2f2e2c63c02c3429d029c90639de1322/appointment_google_reserve/models/google_reserve_merchant.py#L21-L22

Task-6395376
sentry-7630852653

Forward-Port-Of: odoo/enterprise#125680

**Steps to reproduce:**
- Install the `l10n_pl_reports` module and switch to a `PL Company`.
- Create and confirm a vendor bill with a `Bill Reference` and `Taxes`.
- Navigate to Accounting > Reporting > Tax Report and select `This Month`.
- From the dropdown, click `JPK` > `Export XML`.
- Open the generated XML file and observe the `DowodZakupu` field.

**Observation:**
`DowodZakupu` contains the vendor `Bill Number` even 
when a `Bill Reference` is set.

**Root Cause:**
At [1], `DowodZakupu` is populated only with the vendor `Bill number`(`move_name`) 
instead of using the `Bill reference`(`ref`) when available.

**Fix:**
This commit ensures `DowodZakupu` contains the `Bill Reference`
when it is available in JPK exports.

**Reference:**
https://www.podatki.gov.pl/media/eqrn3dey/broszura-jpk_vat-z-deklaracj%C4%85-od-1-lutego-2026-r-en.pdf (page 41)

[1]:
https://github.com/odoo/enterprise/blob/4b0404058b280136f6865090562f95e18d4d7e0b/l10n_pl_reports/data/jpk_export_templates.xml#L208

opw-6299827

Forward-Port-Of: odoo/enterprise#126113
Forward-Port-Of: odoo/enterprise#121117

### Issue:

Attributes of DoctoRelacionado node in the XML display an incorrect value because the exchange rate difference entry distorts the calculation, even though the invoice was fully settled.

https://drive.google.com/file/d/1ntQny0o8bkkfYtY5ZNBK0Yq7Rq0I-yfz/view

### Fix:
Sorting partials by "not exchange_move_id" first broke the chronological order whenever the invoice/payment partial itself carried an exchange difference (e.g. a foreign currency payment settled at another rate). This made the residual-chain algorithm consume the credit note's "other_residual" on the wrong payment, so ImpSaldoAnt/ImpPagado/ ImpSaldoInsoluto in the payment CFDI's DoctoRelacionado stayed wrong even though the invoice was fully paid.

Populate the exchange move mapping in a separate first pass and sort the partials purely by date/id, so credit notes are always deducted from the correct payment.

task-id:[6363092](https://www.odoo.com/odoo/project/49/tasks/6363092)

Forward-Port-Of: odoo/enterprise#126061
Forward-Port-Of: odoo/enterprise#124882

**_Steps to reproduce :_**

-  Install l10n_it_riba.
-  Configure a company with a San Marino (SM) IBAN as the bank account for the
   journal used for Ri.Ba.
-  Create a customer payment and add it to a Batch Payment using the Ri.Ba.
   payment method.
-  Validate the Batch Payment.

**_Observed behavior :_**

 The validation fails with the error:
   `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments`

**_Cause :_** 

 The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs.

**_Fix :_**

-  Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files.

-  While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format.

**_opw_** - 6303820

Forward-Port-Of: odoo/enterprise#126208
Forward-Port-Of: odoo/enterprise#121439

## Problem

`pttExtensionHookService` registers a global `window.addEventListener("message", ...)`
handler that reads `data.from` without checking that `data` is defined first:

```js
browser.addEventListener("message", ({ data, origin, source }) => {
    const rtc = env.services["discuss.rtc"];
    if (
        source !== window ||
        origin !== location.origin ||
        data.from !== "discuss-push-to-talk" ||   // <- crashes if data is undefined
        (!rtc && data.type !== "answer-is-enabled")
    ) {
        return;
    }
    ...
```

Any same-window, same-origin `postMessage` sent by an unrelated browser
extension (a common content-script <-> injected-script pattern) can carry
`data === undefined`. The `source !== window` and `origin !== location.origin`
checks only filter out cross-window/cross-origin messages, so a same-origin
message from any other extension reaches this handler and crashes with:

```
TypeError: Cannot read properties of undefined (reading 'from')
```

This surfaces as an uncaught client error on any page with Discuss loaded,
after some time, unrelated to what the user is doing. The Discuss
push-to-talk extension itself does not need to be installed to trigger it,
since the crash happens before checking whether the message actually
originated from that extension.

## Solution

Use optional chaining (`data?.from`) so unrelated same-origin messages with
no `data` are safely ignored instead of crashing.

## Verification

- Reproduced against the live production `web.assets_web.min.js` bundle
  (traceback matches exactly).
- Confirmed the bug is still present in the latest `18.0` of both `OCA/OCB`
  and `odoo/odoo` (no newer commit touches this file since
  `dc58ef1ad904`, which fixes an unrelated issue).

Issue:
The MyInvois payload computed `cbc:PrepaidAmount` as `amount_total - amount_residual`, treating every reconciled payment as a prepayment. A payment made on or after the invoice date is an ordinary settlement, not a deposit, but the code recognized it as one anyway. The values reported for `PrepaidAmount` were wrong regardless of the invoice date, and for a fully paid invoice this also collapsed `PayableAmount` to 0.00, which LHDN rejects.

Root Cause:
LHDN only considers a reconciled payment a genuine deposit if it was received before the invoice date. The code applied no date condition at all, so any payment reconciled against the invoice was added to `PrepaidAmount` and reduced `PayableAmount` accordingly.

Fix:
Only sum reconciled payment partials whose date is strictly earlier than the invoice date as prepaid, so regular payments are no longer misclassified as deposits. As a safety net, if the valid prepaid sum still covers the full invoice amount (e.g. a full advance payment), reset it to 0 so `PayableAmount` always reflects the full amount_total instead of being reported as 0. Also omit the `PrepaidPayment` node entirely when there is no genuine prepayment, rather than emitting it with a 0.00 amount.

[Task-6404296](https://www.odoo.com/odoo/my-tasks/6404296)

Forward-Port-Of: odoo/odoo#278010

The JsonFormatter has two bugs

- the ignore list is not working as expected
- in 18.0-18.4 the 'test' key is broken

This commit add tests to ensure those behavior works as expected

While on it, also adds a `additional_record_keys` parameter to allow to specifically add keys to the default list, without having to override the whole list, and add additional default keys (exc_info and test)

The previous `ignored_record_keys` default value was possible to remove by calling `JSONFormatter(ignore_record_keys=[])`

The purpose was to be able to easily include all keys and ignore the default ingnore list, but this makes the additional blacklisting of a few keys more tedious, and the general usage and implementation more complex

`JSONFormatter(ignore_record_keys=[*JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS, 'other key'])`

To simplify the logic, **this is not the case anymore**, so to include all keys something like this would be needed

`JSONFormatter(additional_record_keys=JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS)`

Or an hardcoded list.

Forward-Port-Of: odoo/odoo#279049

Issue:
---
Fiscal position is wrongly set to `self.env.user.partner_id.country_id`
instead of `partner_shipping` country, if `partner_shipping_id` is not
changed in the checkout process.

Steps:
1- Create two auto detect fiscal positions: France, Germany
2- Set portal user's partner address country to France.
3- Using portal user, shop from website, and create a delivery address.
4- Pay and confirm the order.
5- Using the admin user, you check the SO's FP which is correctly set
   to Germany.
6- Using portal user, again shop from website, and don't change
   address. Keep previous shipping address which is Germany.
7- Confirm and pay the order.
8- Using admin user, check the new SO's FP. It's set to France.

Cause:
---
`_compute_fiscal_position_id` in SO depends on `partner_shipping_id`.
When the `partner_shipping_id` is not changed, the fiscal position
value set in create will remain.
This value is set in `Website._prepare_sale_order_values()`.
The `fiscal_position_id` is set to self.fiscal_position_id, which is
`_get_fiscal_position(self.env.user.partner_id)`.

Fix:
---
If the user has already a SO, we can use last SO's shipping address
and invoice address to calculate FP in `_prepare_sale_order_values`.

opw-6357638

Forward-Port-Of: odoo/odoo#276485

**Steps to reproduce:**
- Install Survey app
- Create a survey
- Share as e-mail
- Add some text in the body/subject
- Modify recipients
- The added text is automatically reset

**Issue:**
Behavior was previously introduced to match the content
of the composer body/subject to the recipient language.

If there was only one language among the recipients
it automatically adapted the template and changed the
rendered language (which also refreshed the content).

This logic was triggered by a depends on `partner_ids`
and triggered the compute on every recipient changes
which led to the subject/body reset.

**Fix:**
Revert commit: https://github.com/odoo/odoo/commit/b7bbb7b21f4848323666230b518cad9459726f67 in 18.0+
Also adapt commit: https://github.com/odoo/odoo/commit/c6f19e89cb6019e7dbaadbc7427fbb6ddd5661ed to avoid mixed language in resulting mail when the composer was modified
We could also try to prevent the compute when the subject or body is already modified instead of removing its logic.

opw-6020245

When a manufacturing order consumes components into negative stock and a later receipt revalues those component moves, only the component valuation was corrected. The finished product kept its initial cost and the production account stayed unbalanced.

Steps to reproduce:
-------------------
* Configure a finished product and a component in AVCO with automated or manual inventory valuation
* Add a BoM with 10 components per finished product
* Purchase and receive 5 components at $5/unit
* Manufacture 1 finished product, forcing consumption of 10 components
* Purchase and receive at least 5 more components at $10/unit

> Observation:
A revaluation entry is created on the component move of the MO (e.g. 0 qty, -$25), but no matching revaluation is created on the finished product. The FG stays valued at $50 instead of $75 and the WIP/production account is not balanced.

Why the fix:
------------
FIFO vacuum corrections were only propagated through `_post_fifo_vacuum` for real-time valuation layers. Manual periodic vacuum SVLs were ignored, so the MRP hook never ran for the common test and production setups. Pass manual and real-time vacuum SVLs to the hook, and mirror the component correction onto the finished product move of the related done MO.

opw-6232734