### Issue before this commit:
When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report.

### Steps to reproduce the issue:
1. Create a sales order for product A
2. Deliver product A
3. Create invoice
4. Create credit note by clicking on "Reverse and create invoice"
5. The new invoice correctly remains linked to the Sales order
6. However, the source document disapear on the PDF

### Cause of the issue:
In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked.

### Reason to introduce the fix:
To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF.

opw-6034574

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

Forward-Port-Of: odoo/odoo#254290

# How to reproduce
- Create a time off request for a single employee
- Refuse it
- Duplicate it
- Refuse the duplicate
- Try to go back to draft

# The problem
The user is deadlocked and cannot go back to draft because of a client validation on the field employee_ids. The user cannot change that field because it is readonly, so he is stuck.

# Why
When duplicating a hr.leave, employee_id is copied but not employee_ids. Going back to the issue steps, if you look at the Employees field of the duplicate, it is empty. This later cause the issue with the client side validation.

Copying employee_ids when there are multiple employees did not seem like the best idea because a lot of flows relies on employee_id. employee_id is computed as follows :
```py
    def _compute_from_employee_ids(self):
        for holiday in self:
            if len(holiday.employee_ids) == 1:
                holiday.employee_id = holiday.employee_ids[0]._origin
            else:
                holiday.employee_id = False
```
So if we copy multiple employees in employee_ids, employee_id will be null, which might break these flows.

opw-5995398

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

Forward-Port-Of: odoo/odoo#253075

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

**Issue:** In Odoo 18/19, purchase move lines default to the WH's main stock location (`lot_stock_id`) as the `location_final_id`. However, when a user configures a sub-location on the Receipt Operation Type, the picking destination is correct, but the move lines are defaulted to the main warehouse. This mismatch causes the Forecasted Quantity to not increment for the intended sub-location

**Solution:** Prioritize the `default_location_dest_id` before falling back to the default stock location

opw-6032018

### **Current behavior before PR:** 
When confirming a PO, the `location_final_id` on stock moves defaults to the `lot_stock_id`, regardless of the specific destination set on the Operation Type. This causes a mismatch in 1-step receiving flows where a sub-location (e.g., WH/Stock/Test) is intended, since the move lines revert to the root warehouse location (WH/Stock). Thus, the forecasted quantity for the specific sub-location doesn't increment as expected.

### **Desired behavior after PR is merged:** 
The `_get_final_location_record` method will now evaluate if the Operation Type's `default_location_dest_id` is a child of the warehouse's main stock. If it is, the sub-location is used as the `location_final_id` for the moves and move lines. This ensures that the forecasted quantity reflects the intended destination upon PO confirmation while still maintaining the fallback to the warehouse root for standard multi-step routes.




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