**Steps to reproduce in runbot:**
1. Install hr_holidays_attendance.
2. Create an employee with a contract start date (e.g., April 1st).
3. Set the timezone(for both user and emp working schedule) to Europe/Brussels.
4. Create an attendance record (e.g., April 15th).
5. Go to Reporting > Time Off Ledger and remove all filters.
 -> Attendance is correctly shown for all dates from April 1st
6. Create a public holiday on April 16th starting at 00:00.
7. Check the Time Off Ledger again.

**Issue:**
The attendance entry for April 15th disappears after adding the public holiday.

**Cause:**
Calendar leave datetime fields (date_from/date_to) are stored in UTC but compared against attendance dates without converting to the employee's resource calendar timezone, causing date boundaries to shift and records to be incorrectly excluded.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L133-L144

**Solution:**
Convert calendar leave datetimes to the employee timezone before casting to date, ensuring comparisons reflect the correct local boundaries.

**NOTE:**
This issue is mainly reproducible on runbot since its server timezone is
GMT. On local machines configured with UTC, the stored datetime values
already align with the expected conversions, so the date shift does not occur.


opw-6118043




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

Forward-Port-Of: odoo/odoo#265129
Forward-Port-Of: odoo/odoo#262179

Issue:
------
`l10n_br.address_form_fields` inherits from `portal.address_form_fields` but targets a `<select>` element that was moved to `portal_address_extended.address_extended_form_fields` in [saas~19.2].

Traceback:
----------
```py
Error while parsing or validating view:

Element '<xpath expr="//select[@name=&#39;city_id&#39;]/option[not(@value=&#39;&#39;)]">' cannot be located in parent view
```

Steps to reproduce:
-------------------
1. Install `l10n_br` in v19
2. Upgrade to v19.2
3. Upgrade the `l10n_br` module →  Traceback

Root cause:
-----------
The view is adapting an element owned by a sibling view, making the inheritance hierarchy conceptually wrong and fragile.

Solution:
---------
Update the `inherit_id` of `l10n_br.address_form_fields` to `portal_address_extended.address_extended_form_fields` so it correctly inherits from the view that owns the targeted element.

opw: [6125901]

[saas~19.2]: https://github.com/odoo/odoo/commit/026c6f9f2a388ee509a135c53e38f5bb3d08ff73
[6125901]: https://www.odoo.com/odoo/70/tasks/6125901?debug=1

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

### Issue before this commit:
In the previous implementation, several Italian taxes, specifically the 4% INPS and the 4% Pension Fund (F.Pens), were not correctly initialized. Although the relevant EDI data was present in the source CSV templates, it was missing from the actual tax records in the database.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi
2. Go to Accounting -> Taxes
3. Open 4% INPS tax and 4% F.Pens and go to Advanced Options tab and see that no Pension Fund Type is associated by default

### Cause of the issue:
While moving the witholding data from l10n_it_edi to l10n_it in this commit https://github.com/odoo/odoo/commit/40e09ca01242 the templates were not correcly rendered and set up.

### Reason to introduce the fix:
For a tax to be correctly recognized from the XML, it is essential that we have the corresponding tax already configured in Odoo, including the specific type. We should have at least these two taxes fully configured so the system can elaborate them correctly when imported from vendor bills.

opw-6093221

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

Forward-Port-Of: odoo/odoo#258947

When updating a mo, if the new component has a multilvl bom, it will only create a mo for the direct child and not the next

Steps to reproduce:
-------------------
* Create a products "Main", "Final", "Semi", "Raw"
* Create a Bom for "Final" with "Semi" as component
* Create a Bom for "Semi" with "Raw as component
* Add MTO on Final and Semi
* Create a MO for Main with no components and confirm it
* Add "Final" to the mo as component as save. -> The MO for "Final" is correctly created with "Semi" as component but there is no MO for "Semi" with "Raw" as component.

Observation:
-------------

When updating de MO, it will write the new SM (Final) to the production, and we will call ```_autoconfirm_production``` with ```no_procurement```: https://github.com/odoo/odoo/blob/6fb69b5640743d3bc7bb52c73cb27da428f2451c/addons/mrp/models/mrp_production.py#L1051 Where we will directly confirm the sm (```_action_confirm```).

From the SM ```_action_confirm``` we will create and run a procurement (manufacture in our case).
From the manufacture we will create the new move line for Semi and go through ```action_confirm``` on the manufacturing order:
https://github.com/odoo/odoo/blob/9ef76a4d6010191ab7ab1a0d1085972901280dda/addons/mrp/models/stock_rule.py#L116-L118
In the MO ```action_confirm```, we will confirm the move and should create new procurement for the moves that need them, but, since in our case we have ```no_procurement``` in the context, we will set ```create_proc``` to false:
https://github.com/odoo/odoo/blob/9ef76a4d6010191ab7ab1a0d1085972901280dda/addons/mrp/models/mrp_production.py#L1635
Since ```create_proc``` is false we will not create a procurement for those move lines:
https://github.com/odoo/odoo/blob/6fb69b5640743d3bc7bb52c73cb27da428f2451c/addons/stock/models/stock_move.py#L1557-L1558
https://github.com/odoo/odoo/blob/6fb69b5640743d3bc7bb52c73cb27da428f2451c/addons/stock/models/stock_move.py#L1571-L1580

opw-6005675

Forward-Port-Of: odoo/odoo#258153

Issue
-----
`REF` field of Fedex labels is missing.

Steps to reproduce
-----
- Setup Fedex
- Create a product (set weight)
- Create a delivery for the product
	- Set carrier as Fedex
- Validate delivery
- Opend the label

> REF field is empty

Cause
-----
When filling the `CustomerReferences`, we only specify the SO

https://github.com/odoo/enterprise/blob/aae680f5b86fa87193ba6616e8431eed985b2ee7/delivery_fedex_rest/models/fedex_request.py#L309-L313

The `REF` field is populated using `CUSTOMER_REFERENCE` references, which is not present in this case.

Excerpt of the API DOC
-----
```
"CustomerReference": {
	"type": "object",
	"properties": {
		"customerReferenceType": {
			"type": "string",
			"description": [...],
			"example": "DEPARTMENT_NUMBER",
			"enum": [
				"CUSTOMER_REFERENCE",
				"DEPARTMENT_NUMBER",
				"INVOICE_NUMBER",
				"P_O_NUMBER",
				"INTRACOUNTRY_REGULATORY_REFERENCE",
				"RMA_ASSOCIATION"
			]
		},
		"value": {
			"type": "string",
			"description": [...],
			"example": "3686"
		}
	}
},
```

[...] replaces long description strings, refer to API for full documentation.

Result after fix
-----
<img width="477" height="738" alt="image" src="https://github.com/user-attachments/assets/0d3a0786-5b7d-41cc-8548-2dc7b0f379ab" />

-----
Ticket:
opw-6101620

Forward-Port-Of: odoo/enterprise#116870

Before this commit, finding a bom for a recordset of `products` involved looping over all the boms and it will loop over all the `product_variant_ids` of `bom.product_tmpl_id` if the bom's `product_id` is NULL. This approach might loop over variants which we are not trying to find a bom for. In additon to that, due to the fact that multiple boms might have the same `product_tmpl_id`, this approach might consider the same variants in the inner loop redundantly even though we matched the variant with a bom in a previous itration.

Worst case, this might result in a time complexity of $O(N * M)$ where N is the number of boms and M is the number of variants.

To improve the performance, I only considered the variants given in the paramater `products` and in addition to that, I created a new dictionary mapping a `product_tmpl_id` to its bom if the bom doesn't have a variant set. By doing this, I can loop over the `products` given and if it doesn't have a bom set then it will be set to the one its template had taken from the previos loop.

In a method call with the following constraints
    - **2** products the method was finding a bom for
    - The 2 products had the same template and the template contained **550** active variants
    - The boms were only related to the template rather than the variants themselves.

| Input Size | Before | After |
| :--- | :--- | :--- |
| 100 | 0.78s | 0.03s |
| 1000 | 8.53s | 0.11s |
| 10000 | 80.99s | 0.73s |

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

Forward-Port-Of: odoo/odoo#247465

When generating a quotation for a recurring plan, if the quotation uses the DIN5008 template, the recurring plan is not shown in the report.

Steps to reproduce:
-------------------
* Make sure l10n_din5008 is installed
* Create a Swiss company
* Go to the subscription app and create an order with a recurring plan
* Print the quotation
> Observation: The recurring plan is not shown in the report.

Why the fix:
------------
We add a new scss rule to make sure the recurring plan is always shown in the report.
https://github.com/odoo/enterprise/blob/fb2eb6cfdc4527e102dd22321975ab3f0d24b88b/sale_subscription/views/subscription_templates.xml#L7-L23

Before:
<img width="790" height="677" alt="image" src="https://github.com/user-attachments/assets/342753fa-9655-41ac-a958-f94f6ae2b6c7" />

After:
<img width="808" height="756" alt="image" src="https://github.com/user-attachments/assets/4ed726c5-0702-48ee-8578-8b0d2c0f4e55" />


opw-5960219

Forward-Port-Of: odoo/odoo#261727

Steps to reproduce:
===================
1. Go to the shop page and use the rental date picker to select a start and end date with hours.
2. Find a rental product configured with "Days" pricing.
3. Add to card directly from the product card
4. Add a rental product from product image that has date type value date
5. Go to that product details page.
6. Click add to cart

-> Invalid operation, You cannot mix different rental periods...

Cause:
======
When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added.

However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing).

This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page).

Solution:
=========
The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist.

opw-5450576

Forward-Port-Of: odoo/enterprise#117058
Forward-Port-Of: odoo/enterprise#103373

Currently, an error occurs when users click on View GROSS/PPH21/JHT/JP History to see historical payslip line values.

Steps to Reproduce:
 - Install the `l10n_id_hr_payroll` module with demo data.
 - Switch to the `Indonesian` company.
 - Go to `Employees` and open an `existing record or create a new one`.
 - Click on `GROSS/PPH21/JHT/JP History` button.

`ValueError: External ID not found in the system: hr_payroll.act_contribution_reg_payslip_lines`

The issue occurs because, in [this commit], the act_contribution_reg_payslip_lines window action 
was removed. However, when viewing historical lines, and it still tries to retrieve this action using 
its XML ID [1] and then updates its domain, context, and views. As a result, it raises an error due 
to the missing XML ID.

This commit ensures that the method returns a standalone window action dictionary instead of 
relying on the removed window action record.

[this commit]: http://github.com/odoo/enterprise/pull/112571/changes/7094cdc033591258cae7c7df46888c29eaae6248

[1]- https://github.com/odoo/enterprise/blob/103500a805d1ffc1185ed639d613c2d1ede492cb/l10n_id_hr_payroll/models/hr_employee.py#L17-L24

sentry-7489148694

__
## Short functional explanation of the error
While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and
hr_work_entry_attendance are both installed.
When setting an attendance for an employee that has a check-in date but no check-out date, and running the scheduled action `Automatically check-out employees`, an `expected singleton` error occurs.

## Reproduction Steps
1. Install hr_work_entry_attendance.
2. Create an Employee. In the Payroll tab, set a start date for the contract. In the Settings tab, make sure their timezone is set to Brussels, and set the Overtime Ruleset field to Default Ruleset.
3. In Settings, check the Automatic Check-out box.
4. Go to Attendances. Create an attendance for the employee you just created. Set a Check-in date to 8 am on April 17th, for example, and leave the check-out field empty.
5. Open Scheduled Actions. Search the action Automatically check-out employees and click Run Manually.

### Expected behavior
The attendance check-out should be set at the end of April 17th.

### Unexpected behavior
An error occurs:
`Expected singleton: hr.attendance.overtime.line(39, 40)`

## Origin of the issue
When the attendance goes over several days, we set the check-out date to:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L618 This is a Naive date. However, it will later be considered as a UTC date. Because the employee's timezone is Brussels, this time will be transformed to 2 am next day when we retrieve attendance intervals. This will result in the creation of overtime entries for both days, causing the Expected Singleton error.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L687 https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L667-L672 In our case, `self.check_in` = April 17th at 06:00:00 and `self.check_out` = April 17th at 23:59:59. Converted, we will obtain April 17th at 08:00:00 and April 18th at 1:59:59.
Because of that, at the return:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L706-L709 We will return a dict containing 2 intervals: one for 17th April and one for 18th April.
We will then create overtime entries with such attendances: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L333 leading to the creation of 2 different overtimes for the same attendance.
So, when we retrieve the overtime for that attendance: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L185, We get the 2. Thus when trying to access their status with: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L191 An Expected Singleton Occurs.
__
opw-6036064

Forward-Port-Of: odoo/odoo#262257

__
## Short functional explanation of the error
While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and
hr_work_entry_attendance are both installed.
When setting an attendance for an employee that has a check-in date but no check-out date, and running the scheduled action `Automatically check-out employees`, an `expected singleton` error occurs.

## Reproduction Steps
1. Install hr_work_entry_attendance.
2. Create an Employee. In the Payroll tab, set a start date for the contract. In the Settings tab, make sure their timezone is set to Brussels, and set the Overtime Ruleset field to Default Ruleset.
3. In Settings, check the Automatic Check-out box.
4. Go to Attendances. Create an attendance for the employee you just created. Set a Check-in date to 8 am on April 17th, for example, and leave the check-out field empty.
5. Open Scheduled Actions. Search the action Automatically check-out employees and click Run Manually.

### Expected behavior
The attendance check-out should be set at the end of April 17th.

### Unexpected behavior
An error occurs:
`Expected singleton: hr.attendance.overtime.line(39, 40)`

## Origin of the issue
When the attendance goes over several days, we set the check-out date to:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L618 This is a Naive date. However, it will later be considered as a UTC date. Because the employee's timezone is Brussels, this time will be transformed to 2 am next day when we retrieve attendance intervals. This will result in the creation of overtime entries for both days, causing the Expected Singleton error.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L687 https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L667-L672 In our case, `self.check_in` = April 17th at 06:02:00 and `self.check_out` = April 17th at 23:59:59. Converted, we will obtain April 17th at 08:02:00 and April 18th at 1:59:59.
Because of that, at the return:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L706 We will return a dict containing 2 intervals: one for 17th April and one for 18th April.
We will then create overtime entries with such attendances: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L333 leading to the creation of 2 different overtimes for the same attendance.
So, when we retrieve the overtime for that attendance: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L185, We get the 2. Thus when trying to access their status with: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L191 An Expected Singleton Occurs.
__
opw-6036064

Forward-Port-Of: odoo/enterprise#115828

### Issue:
When importing EDI documents such as Peppol files, Swiss VAT numbers are often provided in a flat format (e.g., CHE530781296TVA), while existing Odoo partners usually store them in the official formatted version (e.g., CHE-530.781.296 TVA)

This mismatch prevents proper partner matching and may create duplicate partners during import

### Cause:
`_retrieve_partner` lacks Swiss-specific VAT normalization logic in `_import_retrieve_customer_from_vat()`
As a result, the matching process fails to:
- match formatted and unformatted Swiss VAT numbers
- properly handle language suffixes such as `TVA`, `MWST`, or `IVA`

If `base_vat` is installed, and the imported XML VAT is `CHE530781296TVA`, a new partner will be created with the structure format  `CHE-530.781.296 TVA`
As the match won't be made new partner will be created at each import

### Steps to reproduce:
- Install `account`
- Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA)
- Import the bill [CH_bill_to_import.xml](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) from the ticket 

Before the fix, the existing partner is not matched and a duplicate partner is created

opw-6072239

Forward-Port-Of: odoo/odoo#262011