_
## Short functional explanation of the error
When we generate overtime for an employee who has 2 different versions. If each version has a different overtime ruleset and an attendance exists during the time frame of each version.
When trying to generate overtime for the ruleset of the first version, a traceback occurs.

## Reproduction Steps
1. Create an employee. Create 2 different versions for this employee. On each version, set a different overtime ruleset.
2. Create 2 attendances: one during the time frame on which the first version applies, and one during the time frame on which the second version applies.
3. Go to overtime rulesets. Click on the ruleset you applied on the first version and click Reenerate Overtimes.

### Expected behavior
The overtimes are regenerated correctly.

### Unexpected behavior
A traceback occurs:
`ValueError: Expected singleton: hr.attendance.overtime.ruleset(7, 6) `

## Origin of the issue
In the code, we retrieve the version applying to the attendance for which we want to compute overtimes, to get the ruleset with which we will compute the compensation for overtimes: https://github.com/odoo/odoo/blob/347c46f8ecff7ae97c2a686bf5750374b6c3e2d3/addons/hr_attendance/models/hr_attendance.py#L303-L306 However, `version = inter._items[0][2]` returns both versions, thus obtaining both rulesets and creating the error when trying to accss the field `self.ruleset_id.rate_combination_mode` later, as self.ruleset_id will contain both rulesets.

__
opw-5443700

Forward-Port-Of: odoo/odoo#249736

*: project_purchase, sale_project

---

Decription of the issue this commit addresses:

When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned, any custom analytic distribution done on the line of the product will be lost, resetting the analytic distribution to the default value set on the Analytic Distribution Model.

---

Steps to reproduce:

1. Install sale_project,project_purchase.
2. Activate "Analytic Accounting" in the settings.
3. Create a new Product "test"; Type: Service, Create on Order: Project.
4. Create a new Analytic Distribution Models; Partner: Acme, Product: test, Analytic Distribution: anything but blank.
5. Create a new Quotation in the Sales apps; Partner: Acme.
6. Assign the Product test to the first order line. This will automatically set the analytic distrib of the Analytic Distribution Model.
7. In the Analytic Distribution cell, add a line with any non null distribution.
8. Confirm the Quotation.
9. The analytic distribution that was anually added has been removed. Only the default analytic distribution of the model remains.

---

Desired behavior after this commit is merged:

Any custom analytic distribution done on a line is never lost. The Analytic Distribution Model's distribution serves as a template but never overrides the values set by the user.

---

opw-4934291

---

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

Forward-Port-Of: odoo/odoo#250707
Forward-Port-Of: odoo/odoo#249747

Currently an error occurs when user tries to open reception report through web studio.

Steps to replicate:
- Install stock, web_studio with demo.
- Open receipts and turn on studio mode.
- Go to reports and try to open `Reception Report`.

Error:
```
psycopg2.ProgrammingError: can't adapt type 'NewId'
```

Cause:
- Error occurs after this [PR] that prevents passing of falsy ids to orm.
- As a result the [line] passes `api.NewId()` that is received as `docids` in the function `_get_docs()` performs search using the `NewId` [here] which causes this error to occur.
- In the previous version the id passed was passed a static list `[0]` and then changed to `api.NewId()` which works perfectly fine with `browse()` but with any other operation that fires direct queries like `search()` or `_read_group()` it will cause this error to occur.

Solution:
- Removed NewIds from docids before the search.

[PR]: https://github.com/odoo/enterprise/pull/95117/changes#diff-cf8f46a54f86279b4d773f0d39b23d22f046eb6d33a39c851f2a86dcd2b5b202R645

[line]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/web_studio/controllers/report.py#L649

[here]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/stock/report/report_stock_reception.py#L190

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

Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
    - weight: 10 kg
- Create a delivery picking:
    - Add one unit of P1
    - Mark as “To Do”
    - Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0

Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
    - `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
    - `pack.shipping_weight` is 0 on creation.
    - The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13

opw-5357843

Forward-Port-Of: odoo/odoo#249029
Forward-Port-Of: odoo/odoo#238917

### Issue:
When creating a Working Schedule, and choosing the option "Define Amount of Hours per day" then the fields `hours_per_day` and `hours_per_week` are not recomputed correctly.

### Steps to reproduce:
- Create a new Working Schedule
- Tick the option "Define Amount of Hours per day"
- Change the duration on a line
- Hours per day and hours per week are not updated

### Cause:
This [commit](https://github.com/odoo/odoo/commit/77f860f5d3757e5a56861ac1de95b9ad29ea0dff) introduced the possibility of defining `resource.calendar.attendance` with `duration_hours` instead of `hour_from`/`hour_to`.

The fields `hours_per_week`/`hours_per_day` are recomputed when changing `hour_from`, `hour_to` or `duration_hours`. This recompute is done because an onchange is triggered and will recompute all compute fields displayed in the form view.

As the fields `hour_from`/`hour_to` are not computed, they are not changed when changing `duration_hours` on the form view but they are when saving because of `_inverse_duration_hours()`.

The compute method of `hours_per_week` only takes into account `hour_from`/`hour_to`. So if `duration_based` is False, then changing `hour_from` will recompute `hours_per_week` but changing `duration_hours` will not as `hour_from`/`hour_to` still have the previous values.

### Solution:
We need the recomputation to be made on `duration_hours` when `duration_based` is True.

As `duration_hours` is recomputed via `_compute_duration_hours()` when `hour_from`/`hour_to` change, we only use `duration_hours`.

opw-5942240

Forward-Port-Of: odoo/odoo#249446

Problems:
-------
1. For a new employee, with a contract starting in the current month but before today:
in the payslip for the current month number of days of attendance and days of out of contract
are not correct

Same for an employee, with a contract ending in the current month (before today)

2. In both cases above worked entries are not generated correctly
(from today to the end of month)

3. Additional bug:
If we create an employee with no contract and create a payslip draft for him
for the current month, work entries with type "Attendance" will be created

Objective:
---------
Problems 1 and 2 :
date_version was equal to today (date of the employee's creation),
so number of attendance days was calculated as
( end_of_payslip_month - today ) or ( today - start_of_payslip_month )

Problem 3 :
Work entries are generated even when there is no active contract

Solution:
---------
Problems 1 and 2: This commit adds an additional part (already exists in v19) in the method
write() of hr.version which sets date_version = contract_date_start

Problem 3: by generating work entries check if contract_date_start is filled

Tests ware added in odoo/hr: test_hr_version.py
and in enterprise/hr_payroll:
test_new_employee_worked_days, test_payslip_empty_contract.py

task-5430759

Forward-Port-Of: odoo/odoo#250722
Forward-Port-Of: odoo/odoo#241978

Problem:
-------
In several scenarios, Worked Days are incorrectly computed when the employee
has no contract or when the contract does not fully overlap with the payslip
period.

Case 1:
- Create an employee without a contract
- Create a payslip for this employee for the current month:
You'll see X days of attendance (= today until the end of the payslip period)
and Y days of out of contract (= number of days from the start of the payslip period until today)
- Create a payslip for this employee for the previous month:
you'll see ( Z_prev + Y )  days out of contract ( Z_prev = number of working days in the previous month)
- Create a payslip for this employee for the next month:
you'll see Z_next days of attendance (Z_next = number of working days in the next month)

Case 2:
- Create a new employee with a contract starting during the current month
- Create a payslip for this employee for the previous month
- Out-of-Contract days are incorrectly computed as:
  contract_start_date - previous_month_start.

Case 3:
- Create an employee with a contract ending during this month
- Create a payslip for this employee for the next month
- Out-of-Contract days are incorrectly computed as:
  next_month_end - contract_end_date.

Solution:
--------
When generating work days lines:
- Explicitly handle employees without a contract.
- Use adjusted date bounds when the contract does not overlap the payslip
  period.

Several tests were added to cover these scenarios, as well as the tests the corresponding commit
in odoo/odoo (PR odoo: 241978)

task-5430759

Forward-Port-Of: odoo/enterprise#108783
Forward-Port-Of: odoo/enterprise#103207

A component bought from a vendor and
dropshipped to a subcontractor should the valued into the stock valuation account and not the expense one. In case this component have its "Invoice Policy" set to "ordered quantity", the `_eligible_for_stock_account` method will test if the related stock move are dropshipped https://github.com/odoo/odoo/blob/7436e0cfaf8d4b0c0e0390e8d6a3df404ba240f6/addons/stock_account/models/account_move_line.py#L31-L35 The value `is_dropship` is only set at the validation of the stock move. Due to the invoice policy, the receipt is not validated yet.

close #243015
This commit will rather use the helper `_is_dropshipped()` that only rely on the location and not on the state.

This commit also clean and reenable the related tests.

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