When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5 account.bank.statement.lines and use them to define the reconciliation model config. A matching is done on the payment_ref of the account.bank.statement.lines by finding the longest common substring in the reference.

### Current Implementation
The current algorithm does so by first generating all the possible substrings for all the payment_ref before doing the intersection between these sets and returning the max if `len(substring) >=10`. This is reasonable when the payment_ref follows either a SEPA communication national standard like the Belgian one or the Creditor Reference standard (ISO 11649). For transactions with large, unstructured communication with more than 100 chars, the method `_get_common_substrings` quickly overfill the memory, sometimes raising a MemoryErorr, and takes a significant amount of time. That's because the nested function `_generate_all_substrings` generates n*(n+1)/2 substrings, with n being the lenght of a payment_ref, called `label` in `generate_all_substrings`.

### Proposed Fix
This commit introduces another algorithm to find the largest common substring. It starts by taking the two smallest labels to find their substrings intersection. We know that for an arbitrary collection of labels, the intersection of their substrings sets A ∩ B ∩...∩ Z is included in the intersection of any two substrings sets. The underlying assumption of the first step is that for an arbitrary collection of labels the intersection of the substrings sets of the two smallest labels will be the smallest intersection of any given pair of substrings sets. This won't hold true everytime and using a metric such as label similarity instead of shortest string might be better. But on average this should be good enough and it's easier to implement + it removes the need of preprocessing the labels to compute the similarity.

The point of the new nested function `common_substrings` is to discard common substrings as we build them. Using the current `generate_all_substsrings` on either the smallest label or both smallest
labels would still generate and store a lot of substrings, especially for large labels. By yielding the common substrings as we find them, the memory footprint is vastly reduced.

Lastly, the next substring in the common_substrings iterable is only checked against the remaining labels if it's longer than the current match. This speeds up the whole process

### speedup

In a customer database with some account.bank.statement.line with payment_ref > 500 chars, setting a specific account (code 4970) on transactions goes from MemoryError to < 1Mb memory consumption.

Because of the memory consumption it was not possible to gather timing value on the current version. 
Testing the new algorithm in a shell and using as labels the 5 longest payment_ref in the customer database
(831, 831, 1117, 1178, 1300 chars), averaging to 2000 chars once normalised, the average time to execute `_get_common_substrings` is 900 ms ± 10.3 ms.

Forward-Port-Of: odoo/enterprise#118824

Currently, an error occurs when a user removes the Tax Treatment Category of an Australian employee.

Steps to Reproduce:
 - Install the `l10n_au_hr_payroll` module with demo data.
 - Switch to an `Australian company`.
 - Open any `Employee` > `Payroll` > remove the `Tax Treatment Category` value.

`UnboundLocalError: cannot access local variable 'code' where it is not associated with a value`

After the [change] in selection field behavior, users can clear the value of the field. When the 
user removes the Tax Treatment Category value, the system computes the tax treatment 
code [1]. During this process, if no condition matches, the code variable is not initialized. 
Converting this uninitialized variable to a string [2] raises an error.

This commit ensures that when the tax treatment category is not set, the tax treatment code is 
set to False with an early return. Since the tax treatment category is required field and compute 
the correct tax treatment code, once the category is set.

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

[1]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L450-L451

[2]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L515

No task ID

Forward-Port-Of: odoo/enterprise#124067

### 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#125475
Forward-Port-Of: odoo/enterprise#124882

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

Steps to reproduce:
-------------------
1. Install Timesheets.
2. Create a new employee with a fully fixed working schedule (40h/week).
3. Open Timesheets > All Timesheets and create a new timesheet in the past week for this employee (e.g. 8 hours).
4. Observe the overtime indicator for the employee (it shows 32 hrs)
   (Click the left arrow to display it).
5. Change the timesheet encoding unit to "Days / Half-Days".
6. Return to Timesheets and observe the overtime indicator (it now correctly shows 4 days).
7. Install a language other than English (e.g. French).
8. Return to Timesheets and observe the overtime indicator again.

Issue:
--------
The remaining time value changes unexpectedly and displays 32 hours instead of 4 days.

Cause:
---------
In `get_timesheet_and_working_hours_for_employees`, the code determines whether the timesheet UoM is expressed in days by comparing the UoM name with the string `"days"`.

Since UoM names are translatable, this comparison becomes invalid when the user language changes (e.g. `"jours"` in French), causing the logic to skip the day conversion and return values in hours instead.
https://github.com/odoo/enterprise/blob/c48290e90fdeadf4f9ca8c44b035e601e7ed380a/timesheet_grid/models/hr_employee.py#L165-L169

Solution:
-----------
Compare the timesheet UoM record with the day UoM record directly instead of relying on translated string values.


see commit: https://github.com/odoo/enterprise/commit/5fbf194c5056566453a124812fd2614edfe19a82

opw-6279133

Forward-Port-Of: odoo/enterprise#126114
Forward-Port-Of: odoo/enterprise#120595

Steps to reproduce:
-------------------
1. Install `documents_hr` and `web_studio` with demo data.
2. Add `document_count` to the Employees list view via Studio.
3. Create a second company with an employee, enable multi-company.
4. Open Employees list, click **All** in the search panel.

Issues:
------
Issue 1:
```python
File "/home/odoo/odoo/enterprise/documents_hr/models/hr_employee.py", line 25, in _compute_document_count
    if not self.company_id.documents_hr_settings:
File "/home/odoo/odoo/community/odoo/orm/fields.py", line 1429, in __get__
    record.ensure_one()
File "/home/odoo/odoo/community/odoo/orm/models.py", line 5640, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: res.company(1, 2)
```

Issue 2:
```python
  File "/home/odoo/odoo/enterprise/documents_hr/models/hr_employee.py", line 31, in _compute_document_count
    ('partner_id', '=', self.work_contact_id.id)
  File "/home/odoo/odoo/community/odoo/orm/fields_misc.py", line 117, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.partner(9, 8, 7)
```
Cause:
---------
https://github.com/odoo/enterprise/blob/38674448e387159d28f98c1678856fcaf5f7f52e/documents_hr/models/hr_employee.py#L23-L48
1. The document count computation assumes all employees belong to the same company by directly accessing `self.company_id.documents_hr_settings`. In a multi-company environment, `self` may contain employees from different companies, making self.company_id a multi-recordset and triggering a singleton error.

2. Similarly, when `documents_hr_settings` is disabled, the fallback computation accesses `self.work_contact_id` on a multi-recordset, causing another singleton error.

Solution:
-----------
Split the employees based on whether `documents_hr_settings` is enabled and compute each group separately.
Additionally, use the current employee's `work_contact_id` in the fallback computation to avoid singleton error.

**NOTE:**
This has been resolved from saas-19.4 onward with this improvement [commit](https://github.com/odoo/enterprise/commit/d018d8205300b434728129e199ae048cefbaa296).

opw-6351141

Forward-Port-Of: odoo/enterprise#126099
Forward-Port-Of: odoo/enterprise#124826

Steps to reproduce:
- Configure a preparation display on a POS config with a product category
- Place an order and leave it in a non-final stage
- Keep the session open past midnight

Issue:
The kanban order-count badge drops the order once its create_date falls behind "today", while the preparation screen still lists it. The same divergence makes the badge keep counting an order that a "Reset" already removed from the screen.

_compute_order_count() scoped its search on pos_config_id and create_date >= today, whereas the screen is built by get_preparation_display_order() from _get_open_orders_in_display() and _get_stageless_orders_in_display(), which have no date filter and instead bound the set by the order stage `done` flag and the session state. An order open across midnight is therefore in the screen set but not in the badge set. Conversely reset() marks the current stage done, which drops the order from the screen set, but the badge only skipped orders whose latest stage is the final stage, so an order reset while still in the first stage stayed counted.

opw-6414302

Forward-Port-Of: odoo/enterprise#126139
Forward-Port-Of: odoo/enterprise#125984

Issue:
In accrual list reports (Billed Not Received / Invoiced Not Delivered), selecting an "As of" date, opening a line, and returning with the breadcrumb resets the date filter to the default value (today's date)

Steps to reproduce:
1) Open an accrual list report ( Accounting > Audit > Purchases > Bill to receive / Billed Not Received OR Invoices to be issues / invoiced Not delivered)
2) Pick any "As of" date
3) Open any row
4) Click breadcrumb to return to the accrual list
5) Observe the "As of" date has been reset to today's date
To generate some data you could:
create a PO, then upload the bill, validate the receipt, then you'll find it in bills received

Cause:
`AccrualListController.setup()` always initialized state.date with a fresh default date and did not re-put the previously saved `accrual_entry_date` from restored context
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L10-L16

Although `setDate()` stored the selected date in context, `setup()` overwrote the UI state on controller recreation
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L61-L65

Solution:
- Persist `accrual_entry_date` in `AccrualListSearchModel` via `exportState()` / `_importState()`, so the date is restored in search context before the list model loads on breadcrumb navigation.
- Initialize the date picker through `setDate()` in `onWillStart()` instead of hardcoding `DateTime.now()` in `setup()`, so restoration and user changes share the same code path.
- In `setDate()`, reset grouped list caches (`currentGroups` and `groups`) before `root.load()`, because those caches are not keyed on `accrual_entry_date` and would otherwise show stale vendor groups after a date change or breadcrumb restore.

opw-6232263


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

Forward-Port-Of: odoo/enterprise#118669

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

Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard on opening with:

```
psycopg2.errors.UndefinedTable: relation "account_currency_table" does not exist
```

### Current behavior before PR

To compute the recipients, `AccountPartnerLedgerReportHandler._get_report_send_recipients` runs `_get_query_sums`, whose SQL joins the currency table. In a multi-currency setup that table is a **temporary** table that must be created beforehand by `AccountReport._init_currency_table`.

Every regular rendering entry point calls `_init_currency_table` before running currency-table queries, but the report-sending path does not, so the query fails on a missing `account_currency_table` relation.

### Desired behavior after PR is merged

`_init_currency_table(options)` is called before running the query, so the temporary table exists. It is a no-op in mono-currency setups (early return in `_init_currency_table`), so mono-currency behavior is unchanged.

### Steps to reproduce

1. Have several companies using different currencies.
2. Select more than one of them in the company switcher.
3. Open **Accounting > Reporting > Partner Ledger**.
4. Click **Send by email** → the wizard crashes on opening.

Video: https://drive.google.com/file/d/1skpg7YDtxcY1PCtURyzk5PdFPi7ZPreG/view

A regression test covering the multi-currency send-recipients path is included in `test_partner_ledger_report.py`.
I've created the task #6362131 for this issue

Forward-Port-Of: odoo/enterprise#124900
Forward-Port-Of: odoo/enterprise#122897

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

With the Shared Customer Account setting enabled, a user created in c1 cannot access the shop in the website of c2

Steps to reproduce:
1. Install eCommerce and Contacts
2. Go to Settings > Users & Companies > Companies and create two companies c1 and c2
3. Go to Website > Configuration > Websites and create two websites w1 with company c1 and w2 with company c2
4. Change the order of the websites so that w1 is at the top
5. Go to Website > eCommerce > Pricelists and create a pricelist pl1 in c1 assigned to w1 and pl2 in c2 assigned to w2
6. In an incognito tab, go to w1 and create a new account
7. As admin, go to Website > Configuration > Websites and change the order of the websites so that w2 is at the top
8. In an incognito tab, connect with the previously created account and go to the shop
9. An error is thrown
(This error only happens when geoip works, i.e. when `_get_geoip_country_code` returns something)

Issue:
When geoip returns a country code, we search through all the pricelists available for that country code but some of them can be restricted to a company which raises an access error. We need to be able to access them in order to filter the ones that are not available on the current website

Solution:
Access all pricelists with sudo, they will be filtered out with `_is_available_on_website`

opw-3574089

Forward-Port-Of: odoo/odoo#268863

Routes inherited from product category are not available when on replenish.

Steps to reproduce:
-------------------
* Create a new route and allow it on product category
* Create a product category and add the route
* Add the category to a product
* use the repenish button 
-> the category route is not available on the replenishment

Observation:
-------------
When opening replenishment, it will open the view_product_replenish, in that view, it will use allowed_route_ids to allow us to choose a route for this replenishment: https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/wizard/product_replenish_views.xml#L37 
allowed_route_ids is compute in the mixin with the following domain: https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/models/stock_replenish_mixin.py#L18-L21 https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/models/stock_replenish_mixin.py#L25-L31 
this only take into account route from the product and not the ones from the product category. https://github.com/odoo/odoo/blob/deeecf7cd02e7383b591835b0c6495e3ddead0ff/addons/stock/models/stock_location.py#L511

opw-6297308

Forward-Port-Of: odoo/odoo#271535

### Issue before this commit:

1. When generating a FatturaPA XML for a self-invoice (reverse charge / autofattura, e.g. TD17-TD19) with the "Reference" (ref) field filled in, the supplier's invoice number was placed under <DatiOrdineAcquisto> instead of <DatiFattureCollegate>.
2. When a credit note was generated from a vendor bill, the <IdDocumento> in <DatiFattureCollegate> contained Odoo's internal document number (e.g. BILL/2026/07/0002) instead of the actual reference of the invoice received from the supplier (ref).

### Steps to reproduce the issue:
ISSUE 1:
1. Download Accounting and l10n_it
2. Go to Vendor -> Bills
3. Create a bill with:
	1. Italian company as vendor
	2. Product with tax 22% S RC
	3. Bill reference filled (ex. FT00001)
4. Send it to SDI, open the XML and see that the tag <IdDocumento> is inside the tag <DatiOrdineAcquisto> while it sohuld be inside <Datifatturecollegate>

ISSUE 2:
1. From a bill created click Credit Note
2. Send to SDI again, open the XML and see that the tag <IdDocumento> contains the bill reference created in Odoo while it should take the reference of the original invoice SENT by the vendor

### Cause of the issue:

1. The template's t-elif chain did not distinguish between self-invoices and regular documents, so any value in record.ref was routed to DatiOrdineAcquisto regardless of context.
2. Separately, the linked_moves loop always used linked_move.name to populate <IdDocumento>, which for vendor bills/refunds is Odoo's own sequential number, not the supplier's original invoice number.

### Reason to introduce the fix:

1. For the official FatturaPA Technical Specifications, DatiOrdineAcquisto must only reference a purchase order, while DatiFattureCollegate must reference a related invoice — which is the correct category for the supplier document being integrated in a self-invoice. This is confirmed by the Agenzia delle Entrate documentation: https://www.agenziaentrate.gov.it/portale/documents/d/guest/allegato-a-specifiche-tecniche-vers-1-9 (p.107, chapter Compilazione del documento XML con codice TD17)
2. For credit/debit notes, <IdDocumento> inside <DatiFattureCollegate> must contain the number of the original invoice being referenced/varied, not an internally generated document number, as clarified here: https://www.pa.sm/ticket/kb/faq.php?id=46

opw-6117968

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

Forward-Port-Of: odoo/odoo#276523

Steps to reproduce:
-------------------------
1.  Install hr_holidays.
2. Create a time off type with "Custom Hours" as the duration type and "Considered as" set to "Working Time".
3. Create a multi-day time off request for an employee with a standard working schedule.
4. Check the computed duration.

Issue:
--------
The duration is 32 hours instead of the expected 16 hours.

Cause:
----------
https://github.com/odoo/odoo/blob/c0d737142f3a0a385163eb8d075ca71d63913b68/addons/hr_holidays/models/hr_leave.py#L621-L623 For hourly time off types considered as working time, the duration was computed from the raw datetime difference between `date_from` and `date_to`. This bypassed the existing working schedule computation and included hours outside the employee's working schedule.

Solution:
------------
Remove this logic and let the duration fall back to the working schedule-based computation.

**NOTE:**
This issue has been resolved in saas-19.4 with this [commit](https://github.com/odoo/odoo/commit/53672fdca597644a2b675ce887042ef640073d4f)

opw-6385683





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