### Steps to reproduce:
	- Create an accrual plan with the following rule: 
	— The employee has 20 days off in the first year. Total 20. 
	— The employee has 21 days off in the second year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 21 + 5 = 26 
	— The employee has 22 days off in the third year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 22 + 5 = 27 
	— The employee has 23 days off in the fourth year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 23 + 5 = 28
	- Create an accrual allocation with the created plan
	- Check future allocation data using 'Balance at the'
	- Notice the following behaviour: — until 31/12/2025 it CORRECTLY shows 20 days available.

		— from 01/01/2026 to 30/06/2026 it CORRECTLY shows 26 days (21 days for renewal and 5 days not used in 2025)
		— from 01/07/2026 it INCORRECTLY shows no days available.

		— from 01/01/2027 to 30/06/2027 it CORRECTLY shows 27 days (22 days for renewal and 5 days not used in 2026)
		— from 01/07/2027 it INCORRECTLY shows 5 days.

		— from 01/01/2028 to 30/06/2028 it CORRECTLY shows 28 days (23 days for renewal and 5 days not used in 2027)
		— from 01/07/2028 it INCORRECTLY shows no days available.

		— from 01/01/2029 it CORRECTLY shows 28 days again.
		— In the following years, after 6 months, one year shows 5 days and the next shows nothing.

### Cause:
The first cause here is that when we have validity for the carryover then we will have two calls in each year one at the start of the year and another at the expiration date of the carryover. So, when we add the days to the allocation we don't consider the second call in the condition and we only check if the allocation.actual_lastcall is equal to one of the start dates for each year

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L588

The second cause where each two years one of them shows the number of carryover days from the previous year, this is happening because when we remove the expiring days for the first year we set the number of days to 0

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L516-L517

And it will be 0 until we loop again and add the days to allocation

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L521-L522

and since this is happening after we already set the expiring days which in this year will be 0 we won't remove those expiring days from the year's allocation data

### Fix:
We add a condition to check if the actual_lastcall is either a date in the start of the allocation or one of the expiration dates for the carryover.

Also, before we set the value of the expiring_carryover_days we call _add_days_to_allocation to calculate on the correct number of days for the plan level we are checking.

opw-4606886

Forward-Port-Of: odoo/odoo#221248
Forward-Port-Of: odoo/odoo#209669

Currently, a user error occurs when confirming a Sales Order (SO).

**Steps to reproduce:**

1) Install sale_project
2) Create a service product that generates a project and a task. 
3) Add a project template by creating one from the product form view. 
4) Create an SO by creating a customer with a company 
5) Add the above-created service product and confirm the SO.

**Error:**
A user exception will be triggered
```
The project and the associated partner must be linked to the same company.
```

**Cause:**

- When a project template is created from the product view, 
both the customer and the company_id default to empty.

- Later, when confirming a SO with a customer that belongs to a company, 
the new project's company_id is taken from the project template, which is empty.

https://github.com/odoo/odoo/blob/876e9d5e9ba87fa69188b2da098eec78f77040f5/addons/sale_project/models/sale_order.py#L140-L141

- However, the project’s partner_id (the customer) does have a company_id,
(since the customer value for the project will be set through SO's customer).

- This leads to a mismatch between the project’s company_id(which is empty) 
and its partner’s company_id. So a user exception will be triggered from the below lines

https://github.com/odoo/odoo/blob/876e9d5e9ba87fa69188b2da098eec78f77040f5/addons/project/models/project_project.py#L257-L258

**Solution:**

- If the project template has no company_id, and the customer of the project has one, 
set the project’s company_id to match that of the customer.

opw-4900741,4880495

Forward-Port-Of: odoo/odoo#216582

Steps to Reproduce:
- Ensure the `sale_timesheet` module is installed.
- Log in as a user with Timesheet Administrator permissions but without access to the Project module.
- Attempt to open the Timesheets list view results in an `AccessError` due to missing read rights on `project.task`.
- Create a task in a private project linked to a timesheet and open its form view results in an `AccessError` due to missing read rights on `project.project`.

Cause:
- When a user has Timesheet Administrator access but lacks project access, they can view all timesheets, including those linked to tasks with private privacy visibility. However, these users do not have read access to the private tasks themselves.
- The `_compute_commercial_partner` method reads `task_id.partner_id.commercial_partner_id` and `project_id.partner_id.commercial_partner_id`. When a user without read access to `project.task` or `project.project` tries to compute this field, an `AccessError` occurs because the code tries to access these related records without bypassing access rights.

Solution:
- Use `sudo()` on `task_id` and `project_id` when accessing their `partner_id` fields inside the compute method to bypass access rights checks, preventing ` AccessError` for users lacking read permissions.

task-4798066

Forward-Port-Of: odoo/odoo#221247
Forward-Port-Of: odoo/odoo#210826

**Steps to reproduce:**
- Install `point_of_sale`.
- Go to POS -> configuration -> settings
- Search 'Operation type' -> open picking type -> Disable `Create new`
- Create a storable product 'test' with serial tracking.
- Add on-hand quantity with serial numbers.
- In POS, select the product and choose one SN,
- Select it again and choose another SN.

**Observation:**
- The order line should have 2 quantities with a list of Serial numbers chosen by the user. For one quantity, it's working fine, but for multiple quantities, an issue occurs.

**Issue:**
- While confirming edit serial numbers popup for multiple quantities, it checks whether each selected SN is valid or not.
- The condition is that the entered SN is in the existing available SNs option. But the already chosen SN is not in the existing SN option,
- Also, creating a new SN is disabled, so it's considered an invalid input.
https://github.com/odoo/odoo/blob/876b7337eb689e0682ab48e9e833f9f0dc6bb8d2/addons/point_of_sale/static/src/app/store/select_lot_popup/select_lot_popup.js#L190-L193

**Solution:**
- Added a condition to allow SNs that are already selected (matched by name and ID) to be considered valid inputs.

opw-4865902

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

Forward-Port-Of: odoo/odoo#220932
Forward-Port-Of: odoo/odoo#219205

After this commit: odoo/enterprise@9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048 [diff](https://github.com/odoo/enterprise/commit/9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048#diff-de4a628e7837c273b67d71f93efab85b6a9ee957ea702f502066ebcc632a76cbL64)

The condition that handles hiding the basic wage on the payslip was not added —possibly it was missed. That’s why the "Hide basic on PDF" feature doesn’t work, regardless of whether it’s enabled, as the necessary condition is missing in the template.

Steps to reproduce (on runbot):
- In a v18 runbot, open any payslip and go to the salary structure. Enable the "Hide basic on PDF" option.
- Return to the payslip and print it.
- You’ll see that the basic wage is still printed on the payslip.


**Before Fix:**

<img width="669" height="238" alt="payslipbefore" src="https://github.com/user-attachments/assets/2fce67a2-19d8-45d8-88fa-4fc6a1767e68" />

**After Fix:**

<img width="683" height="289" alt="payslipafter" src="https://github.com/user-attachments/assets/adcb0104-9c4e-4a35-ba78-b3f278f6bfda" />

opw-4953831

Forward-Port-Of: odoo/enterprise#90798