Steps to reproduce:
-------------------------------------
1. Install `hr_appraisal_skills` module
2. Create a new employee and assign at least one skill to the employee
3. Set the Next Appraisal Date to today
4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually
5. Open the newly created appraisal for the employee

Observation:
-------------------------------------
In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage

Issue:
-------------------------------------
When the cron  `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via  `create()`. The skill-copying logic only lived in the  `write()` override, which triggers on state transitions from 'new' to 'pending'. Since  `create()` bypasses  `write()`, Employee skills were never copied to cron-created appraisals

https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15

Solution:
-------------------------------------
Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied.

opw-5491433

Forward-Port-Of: odoo/enterprise#107760

**Steps to reproduce:**
- Install `l10n_de, website_sale and appointment` modules.
- Create a website for the `DE company` and make it default.
 (simply place it first in the sequence.)
- From settings enable `Automatic Invoice` and `Discounts, Loyalty & Gift Card`.
- Go to the appointment module and create a new appointment for the DE company.
- In the options tab, enable `Up-front payment` and publish it.
- Create a new gift card program and generate a gift card to test (should cover the entire cost of the appointment booking).
- Now go to an Incognito tab, go to the appointment, and book the currently created appointment. When confirming the order, use the gift card and then confirm the order.

**Issue:**
- When you confirm the order, an access error occurs.

**Root cause:**
- Since automatic invoicing is enabled, at [1] the method
  `get_product_accounts` is called for the DE company.
  Inside this method at [2], self.sudo(False) is used, which removes the
  elevated access rights. As a result, the `Public product template` record
  rule is triggered, and because the public user cannot access the product,
  an AccessError is raised.
- In this [commit], we can see that `sudo(False)` was added when coming from
  the stock flow because the stock valuation layer was being created as sudo.

**Solution:**
- Instead of adding `sudo(False)` in **l10n_de**, we can apply `sudo(False)`
  at the point where the **stock valuation layer** is created using `sudo()`.

[1]https://github.com/odoo/odoo/blob/9d5d5c08f950d32bf61c2186181e8eddad9036da/addons/account/models/account_move_line.py#L603-L604
[2]https://github.com/odoo/odoo/blob/9d5d5c08f950d32bf61c2186181e8eddad9036da/addons/l10n_de/models/datev.py#L20

[commit]: https://github.com/odoo/odoo/pull/236931/changes/0919774791bb998954b870798c88843f999f2de4

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

steps to reproduce:
-------------------
1. Install Time Off
2. Go to Configuration > Accrual Plans
3. Create an accrual plan:
   * Set the accrued gain time to "At the start of the accrual period"
   * Set the carry-over time to "At the start of the year"
4. Create a milestone:
   * Set the number of accrued days to 1
   * Set the accrual frequency to "monthly" and the carry over to "None.Accrued time reset to 0"
5. Go to Management > Allocations
6. Create an allocation:
   * Set the start date to 2025-01-01
   * Set the accrual plan to the one created above
7. Use future allocations to check accruals

current behavior:
-----------------
- On 2026-01-01 --> accrued days = 1  (correct)
- On 2026-02-01 --> accrued days = 1  (should be 2)
- On 2026-03-01 --> accrued days = 2 (delayed accrual, off by one month) 

cause of the issue:
-------------------
Commit 30c7011 introduced a condition that accrues time off on the carry over date:
https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/hr_holidays/models/hr_leave_allocation.py#L559

This incorrectly evaluates accruals across the carry over period instead of restricting to the current month, causing February accruals to be skipped.

**Reason February accruals are skipped:**
https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L559-L561
https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L541-L544

* After January, the last_executed_carryover_date is set to 2026-01-01.
* Therefore, February uses last_executed_carryover_date = 2026-01-01.
* The condition evaluates as true for February:
```python3
last_executed_carryover_date <= allocation.nextcall <= carryover_period_end
2026-01-01 <= 2026-02-01 <= 2026-02-01
```
As a result, the February accrual is skipped.

**Why it works correctly in March:**
* After February, the last_executed_carryover_date is updated to 2027-01-01.
* March now uses this updated date:
```python3
last_executed_carryover_date <= allocation.nextcall <= carryover_period_end
2027-01-01 <= 2026-03-01 <= 2027-02-01
```
The condition is not satisfied, so accruals are processed correctly.

solution:
----------
Add a condition to check if the loop has already run for the current carryover 
period. This ensures the system avoids applying the carryover twice,
allowing subsequent accruals to process as expected.


opw-5020834

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

Backport of 0432a982dfea6e68419f137502c018c0a9241181

### Steps to reproduce:

1. In the settings enable: Multi-steps route
2. Put your warehouse in 2-step deliveries
3. Create a kit product:
   - With one component
   - There is one component in the stock
4. Create and confirm a SO with 1 x K
5. Process the pick and ship
6. Return the delivery
7. Set the sol qty to 0

### > Two unexpected pickings are created to put the kit in output

Decreasing the sol quantity to 0 will call the `_action_launch_stock_rule` in order to create and run procurements related to that quantity change. However, the quantity currently handled by other procurements is determined here by the
`_compute_kit_quantities`:
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_mrp/models/sale_order_line.py#L154-L166 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/mrp/models/stock_move.py#L578-L580
Now, the issue is that `_compute_kit_quantities` does not handle move chains properly, as all delivery moves contribute to the `incoming_qty` and all return moves contribute to the `outgoing_qty`. This results in an `incoming_qty` of 1 (for the pick) + 1 (for the ship) and an `outgoing_qty` of 1 (for the 1-step return), that is a `qty_processed` of 1. As a result, the procurement will be generated for a quantity of `0 - 1` (rather than 0):
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388-L402 which leads to the unexpected picking creations.

opw-6006543

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