Versions
--------
- 18.0+

Steps
-----
1. Have a combo product Foo;
2. ensure the combo items have a weight set;
3. enable & publish a shipping connector;
4. add combo product to cart;
5. go to checkout;
6. attempt to select shipping connector as delivery method.

A similar message appears when trying to add a delivery method to a backend order if the order has downpayment lines.

Issue
-----
> The estimated shipping price cannot be computed because the weight is
  missing for the following product(s): Foo

Cause
-----
The combo product doesn't have a weight, as it's not a discrete item, but a collection of multiple items.

The shipping connectors haven't been updated yet to account for this, and still expect every non-service product to have a weight.

Solution
--------
When looking for lines without weight, filter out products of type `combo` (similar to how `service` products are handled) using a new `_get_invalid_delivery_weight_liens` helper method, added to `sale.order.line`.

Also ignore lines where `product_qty` is zero, e.g. `display_type` lines & down payment lines.

Enterprise PR: https://github.com/odoo/enterprise/pull/91243

opw-4940973

## Short functional explanation of the error
When clicking on "create and edit" on a Sales Order Item field in a task, the company field is left blank. As a result, the taxes linked to the product don't appear.

## Reproduction Steps
1. Install the modules sales, timesheet and project.
2. Make sure that you have at least 2 different companies in the settings.
2. Click on the project app and create a new project. Check the Billable and Timesheets boxes.
3. Create a task and click on it. Set a customer: the field "Sales Order Item" should appear.
4. Click on the "Sales Order Item" field. Type random letters and click on "create and edit".
5. Select a product that has at least one tax.

### Expected behavior
The company field should be filled as soon as we click on the create and edit button, and the taxes field should be filled with the taxes of the
 product as soon as we select said product.

### Unexpected behavior
The company and taxes field remain empty.

## Origin of the issue
Some fields were set at "default_."

__
opw-4904861

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

Forward-Port-Of: odoo/odoo#221342

…ml internal dropship return

**Problem:**
when the subcontracting setting is active, the return of a dropshipped product (not necessarily subcontracted) to the internal subcontracting location will create an account move that credits "stock valuation" instead of debitting it

**Steps to reproduce:**
- enable the "Anglo-Saxon Accounting","Multi-steps routes" and "Subcontracting" settings
- create a storable product with dropshipping route and a vendor
- in 'general information' write a non null cost
- make sure the product category's inventory valuation' is 'automated'
- create a new quotation for this product, confirm it and confirm the linked purchase order
- click on the dropship smart button and validate the picking
- click on return and select 'Physical Locations/Subcontracting Location' as the return location
- validate and click on the valuation smart button
- on the only stock valuation layer for this move, click on the book shaped widget

**Current behavior:**
the account move credits Stock Valuation and debits stock interim (received)

**Expected behavior:**
As we are returning the product to stock it should increase the value of the stock valuation account.
Therefore, it should debit stock valuation and credit stock interim (received)

**Cause of the issue:**
If the mrp_subcontracting_dropshipping module is active, and if we call _is_dropshipped_return on a stock move which is the return (to the subcontracting location) of a dropshipped move : the method will return true. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L29-L35 Therefore, inside _account_entry_move, _is_in will be false (contrary to if mrp_subcontracting_dropshipping is not installed or if the destination is another internal location)
https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L580 The aml vals will be computed inside _prepare_anglosaxon_account_move_vals https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L596 Here the fact the destination location is internal does not change the fact that it should debit the stock valuation account (meaning it should used acc_valuation as the second parameter of _prepare_account_move_vals) if the cost is positive. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L610-L614

opw-4894755

Forward-Port-Of: odoo/odoo#221009

Currently, an error is produced on creating/saving the record of the chart of account if the company of any tax belongs to a company which company is not in the allowed Companies.

**Steps to reproduce:**
- Install the `accountant` and `l10n_be` modules.
- Activate the **IN Company** and keep **YourCompany** as the default.
- Navigate to `Accounting > Configuration > Accounting > Chart of Accounts`.
- Open the new form view of the model by clicking the **view** button.
- In **Companies** field, select the **IN Company**.
- Select the **5% GST** tax in **Default Taxes** field.
- Now, remove the **IN Company** from the **Companies** field.
- Attempt to save the record.

**Error:**
`AttributeError: 'account.account' object has no attribute 'company_id'`

Here, the `_check_company` method at [1] verifies that all relational fields (such as tax groups) belong to the selected companies. While building the user error message, it assumes that all involved records (e.g., `account.account`) have a `company_id` field. However, `account.account` does not define `company_id`, which results in an attribute error.

[1] - https://github.com/odoo/odoo/blob/887f3fa98f6172dc5d35f9981d43d6ccb4cf86dc/odoo/models.py#L4396

This commit added constraint that raises a **UserError** if any tax in the **Default Taxes** field belongs to a company not included in the selected **Companies**. This prevents errors during the company check.

Sentry - 6636043482

This error occurs when we create a live session, modify a question at the end of the survey, and then refresh the page.

Steps to reproduce:
---
- Install ``survey`` module
- Create new Survey > Add a question > Click on ``Create Live Session``
- Complete the survey(wait on Thank You page)
- Now go to the previous tab remove the question and add another question
- Now refresh another tab (Thank You page)

Traceback: 
---
``ValueError: False is not in list``

We encounter the error at [1] because ``page_or_question`` is empty. Its value comes from the ``_is_last_page_or_question`` method, where ``survey.session_question_id`` is also empty. This happens because when a question is removed, ``survey.session_question_id`` becomes empty, and when a new question is added, the ID for that question is not retrieved.

[1]- https://github.com/odoo/odoo/blob/e35d2a0c08f69ad1d122e07726786450e4c30b5a/addons/survey/models/survey_survey.py#L810

sentry-6043084559

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

When the user refuses the application with its duplicate application,
a traceback will appear.

Steps to reproduce the error:
- Go to Recruitment > All Applications >
  Create 2 applications with the same candidate
- Open that application > Refuse > Select refuse reason >
  Select other Duplicate application > Refuse

Traceback:
```
AttributeError: 'hr.applicant' object has no attribute '_get_similar_applicants_domain'
  File "odoo/http.py", line 2364, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1891, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1954, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1921, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2168, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 40, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 517, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/hr_recruitment/wizard/applicant_refuse_reason.py", line 75, in action_refuse_reason_apply
    duplicate_domain = self.applicant_ids._get_similar_applicants_domain()
```

https://github.com/odoo/odoo/blob/e4a4806e5c58c599815204a73c78a228ee230613/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L75
``_get_similar_applicants_domain`` method is removed in this commit 9359d08d331beac389fde0e6c82c895341f7dbc5 but still used here.
So, it will lead to the above traceback.

sentry-5986653915

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

\* = bpost, dhl{,_rest}, easypost, sendcloud, ups, usps{,_rest}

Versions
--------
- 18.0+

Steps
-----
1. Have a combo product Foo;
2. ensure the combo items have a weight set;
3. enable & publish a shipping connector;
4. add combo product to cart;
5. go to checkout;
6. attempt to select shipping connector as delivery method.

A similar message appears when trying to add a delivery method to a backend order if the order has downpayment lines.

Issue
-----
> The estimated shipping price cannot be computed because the weight is missing for the following product(s): Foo

Cause
-----
The combo product doesn't have a weight, as it's not a discrete item, but a collection of multiple items.

The shipping connectors haven't been updated yet to account for this, and still expect every non-service product to have a weight.

Solution
--------
When looking for lines without weight, filter out products of type `combo` (similar to how `service` products are handled) using a new `_get_invalid_delivery_weight_liens` helper method, added to `sale.order.line`.

Also ignore lines where `product_qty` is zero, e.g. `display_type` lines & down payment lines.

Community PR: https://github.com/odoo/odoo/pull/221696

opw-4940973

# How to reproduce the issue

With l10n_es fiscal position:

- Create a bill in a previous period (e.g., amount 1000). Partially credit note this bill for 500.
- Register a partial payment of 250 on this bill.
- In the tax report, go to model 349.

Under the Rectificationes section, the new rectified value will be 250. This is incorrect, as the rectifications in this report should only reflect the value of the original move from a past period after applying the credit note. Payments or other transactions should not impact this report.

This commit adjusts the computation of the report (and the BOE export) to ensure that, instead of using `amount_residual` (which includes payments and other transactions), the report uses the sum of the credit notes linked to the move included in the rectification report.

Also changed the test test_mod349_credit_note. The rectification section is supposed to show the adjusted amount after rectification. In the test a bill of 400 is fully refunded. Instead of 400, the report should show 0.
(https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 in TIPO DE REGISTRO 2: REGISTRO DE RECTIFICACIONES. in 153-165 Numérico Base Imponible Rectificada section)

opw-4895636

Forward-Port-Of: odoo/enterprise#90174
Forward-Port-Of: odoo/enterprise#89431