Steps to reproduce:
---------------------------------------
1. Install the `sale_timesheet_margin` module
2. Create a product as follows:
    * Type: Service
    * Invoicing Policy: Prepaid/Fixed Price
    * Create on order: Nothing
    * Cost: Add some cost to the product (e.g., 30)
3. Create and Confirm Sale Order with Product (Add Cost field in SOL from the optional field)
4. Now add a new Sales Order Line (SOL) with the same product


Observation:
---------------------------------------
The cost of the recently created Sales Order Line (SOL) is 0.0, which is not correctly calculated based on the product's cost.

Issue:
---------------------------------------
The `_compute_purchase_price` method has a filter (`service_non_timesheet_sols`) that excludes certain sale order lines from the parent's purchase price computation. When a new sale order line is added to an already confirmed sale order (state='sale'), the new line inherits the parent SO's state immediately. That means, the new line matches the filter criteria and gets excluded from parent computation. The `purchase_price` is never calculated from the product's `standard_price`

Solution:
---------------------------------------
The added condition, like  EITHER:
1. Has timesheets recorded (`sol.timesheet_ids` is truthy) → Preserve existing cost
2. OR product has NO standard price (`not sol.product_id.standard_price`) → Use timesheet-based costing

Code intentionally skips the computation of `service_non_timesheet_sols` lines to preserve existing values

opw-5351724

Configuration:
- Costing method: FIFO, automated valuation
- Multi-currency: PO in a foreign currency (e.g. EUR), company currency USD
- Two different exchange rates: one active at bill date, one at receipt date
- Bill posted before any goods are received

Steps to reproduce:
- Set EUR as a secondary currency with two different rates:
    - Rate 1 on January 1st:  1 EUR = 1 USD
    - Rate 2 on January 8th:  1 EUR = 2 USD
- Create a PO in EUR for 20 units @ 10,000 EUR
- Post the vendor bill dated January 3rd (rate 1 applies: 1 EUR = 1 USD)
- Receive 10 units on a date after January 8th and create a backorder
- Receive the remaining 10 units from the backorder on the same date
- Inspect the stock valuation layers and interim account journal entries for both receipts

Prior to this commit:
  The two receipts, identical in quantity, date, and PO price, would produce different unit costs in USD. The backorder receipt would be incorrectly valued due to a wrong exchange rate being used when computing `receipt_value` in `_get_price_unit()`.

Receipt 2 (backorder):
    SVL 1 value: $100,000 USD
    Converted to EUR at receipt date (1 USD = 0.5 EUR):
    receipt_value = $100,000 × 0.5 = 50,000 EUR (wrong rate)
    total_invoiced_value = 200,000 EUR
    remaining_value = 200,000 - 50,000 = 150,000 EUR 
    remaining_qty = 20 - 10 = 10
    price_unit = 150,000 / 10 = 15,000 EUR
    Converted to USD at bill date (1 EUR = 1 USD):
    price_unit = $15,000 USD
    SVL value = $15,000 × 10 = $150,000

  This bug only affects backorder receipts. The first receipt always gets `receipt_value = 0` (no prior SVLs exist), so the problematic conversion never runs.

After this commit:
  `receipt_value` is now computed using `_get_currency_convert_date()` instead of `layer.create_date`. This ensures `receipt_value` and `total_invoiced_value` are both expressed in EUR at the same reference rate.

Receipt 2 (backorder):
    SVL 1 value: $100,000 USD
    Converted to EUR at bill date (1 EUR = 1 USD):
    receipt_value = $100,000 × 1.0 = 100,000 EUR (correct rate)
    total_invoiced_value = 200,000 EUR
    remaining_value = 200,000 - 100,000 = 100,000 EUR
    remaining_qty = 20 - 10 = 10
    price_unit = 100,000 / 10 = 10,000 EUR
    Converted to USD at bill date (1 EUR = 1 USD):
    price_unit = $10,000 USD
    SVL value = $10,000 × 10 = $100,000 

  Both receipts now produce identical unit costs regardless of exchange rate differences between bill date and receipt date.

OPW: 5426718



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

**Issue Summary:**

Employees on capped accrual plans can sometimes be blocked from requesting time off in the future, even if they currently have enough available time. This happens when they've previously used more time off than the cap allows at one time.

It's important to note that the cap sets the maximum balance an employee can hold at once, not a limit on the total amount they can accrue over time. For example, if the cap is 12 days, an employee can never hold more than 12 days at a time. However, as long as they continue using time off regularly, they can keep accruing more, theoretically without limit.

To clarify what "future" means here: it refers to any date after the accrual plan's nextcall, which is the next scheduled update to the employee's balance. So even if they have time available now, they might not be able to request leave for dates beyond that point.

Fix 1: See accruals even if the future leaves would be capped.
- `_get_future_leaves_on` gives the difference between today's allocation and the allocation in the future after accruals.
- However, if there's an accrual cap, and today's allocation is at the cap, Odoo can't see accruals in the future since no days would be accrued.
- We want to see future accruals even if we're at the cap.
- Solution: Calculate the future accruals as though it had no cap, then cap the gained leaves to the accrual cap.

Fix 2: Base accruals on virtual leaves, not real leaves.
- When leaves are virtual (not validated), `max_leaves` is too low because it's getting capped to 2, whereas with validated leaves it's 3 successfully.
- This is the result of method `_process_accrual_plans` calling
`_add_days_to_allocation` with the `leaves_taken` argument. It doesn't see non-validated leaves, but it should so that future leaves are correct.
- Solution: Give `_add_days_to_allocation` virtual leaves instead of real leaves.

Fix 3: Show correct max leaves for capped accruals in the Time Off Dashboard.
- The `max_leaves` on leave types is computed based on the user's employee, and appears in the display name when creating new leaves in the dashboard.
- `max_leaves` after Fix 1 will now report the full leaves amount, which in the Dashboard context is wrong since it will say "X out of [max_leaves]" but we need `max_leaves` to reflect the cap.
- Solution: Add logic in `get_allocation_data` to cap `max_leaves` based on accrual cap.

opw-4720344

Co-authored-by: Dirk Douglas <dido@odoo.com>
Co-authored-by: Harrison Hutton <hahu@odoo.com>

## Issue
When creating a job application with a new email address, a `res.partner` is created with both its name and email set to the email address, even if a `partner_name` is provided.

## Steps to reproduce
1. Install *Recruitment* (`hr_recruitment`) and *Contacts* (`contacts`)
2. In Recruitment, create a job application:
    - Any Subject
    - Name N
    - Email E
3. Save the job application
4. Go to Contacts
5. **The partner created from the job application has both its name and email set to the Email E used to create the job application.**

## Cause
The `_inverse_partner_email` passes the email address to `find_or_create` to create the new res.partner:

https://github.com/odoo/odoo/blob/fc58ff23f491a2063b10ffcd6393a08b90dc7975/addons/hr_recruitment/models/hr_applicant.py#L317-L324

This method is implemented to parse both a name and an email address in the same string.

https://github.com/odoo/odoo/blob/fc58ff23f491a2063b10ffcd6393a08b90dc7975/odoo/addons/base/models/res_partner.py#L937-L945

We can thus provide both the `partner_name` and the `email_from` to the method to create a user with a name and an email address properly set.

## POS tests modifications
Before this first commit, some partners in `hr_recruitment` demo data were created with their email address as their name. This is the case, for example, for "Johan Duck", whose name was set to `coincoin@gmail.example.com`.

<img width="627" height="86" alt="260296" src="https://github.com/user-attachments/assets/e4bab843-8ba3-4930-af20-ca8603983929" />

In the POS tours, the list of loaded partners is limited to 100 partners and ordered by their order count (which is often null), __and their name__. 

https://github.com/odoo/odoo/blob/e7345340efbd66473da70ccf6680181b158047ce/addons/point_of_sale/models/pos_config.py#L845-L865

By "renaming" the partners from `hr_recruitment`, they started appearing higher up in the list because their name now starts with capital letters whereas their email began with lower letters, which are sorted after capital letters by the `ORDER BY` SQL clause. As a result, partners from multiple tours were pushed out of the 100 first partners, meaning they were no longer loaded during the tours, causing the tests to fail.

One solution, which is already used in other tests, is to give the test partners names that make them appear higher in the partner list, ensuring they remain within the first 100 loaded partners.



opw-6111598