### Steps to reproduce:
	- Create an accrual plan with the following rule: 
	— The employee has 20 days off in the first year. Total 20. 
	— The employee has 21 days off in the second year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 21 + 5 = 26 
	— The employee has 22 days off in the third year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 22 + 5 = 27 
	— The employee has 23 days off in the fourth year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 23 + 5 = 28
	- Create an accrual allocation with the created plan
	- Check future allocation data using 'Balance at the'
	- Notice the following behaviour: — until 31/12/2025 it CORRECTLY shows 20 days available.

		— from 01/01/2026 to 30/06/2026 it CORRECTLY shows 26 days (21 days for renewal and 5 days not used in 2025)
		— from 01/07/2026 it INCORRECTLY shows no days available.

		— from 01/01/2027 to 30/06/2027 it CORRECTLY shows 27 days (22 days for renewal and 5 days not used in 2026)
		— from 01/07/2027 it INCORRECTLY shows 5 days.

		— from 01/01/2028 to 30/06/2028 it CORRECTLY shows 28 days (23 days for renewal and 5 days not used in 2027)
		— from 01/07/2028 it INCORRECTLY shows no days available.

		— from 01/01/2029 it CORRECTLY shows 28 days again.
		— In the following years, after 6 months, one year shows 5 days and the next shows nothing.

### Cause:
The first cause here is that when we have validity for the carryover then we will have two calls in each year one at the start of the year and another at the expiration date of the carryover. So, when we add the days to the allocation we don't consider the second call in the condition and we only check if the allocation.actual_lastcall is equal to one of the start dates for each year

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L588

The second cause where each two years one of them shows the number of carryover days from the previous year, this is happening because when we remove the expiring days for the first year we set the number of days to 0

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L516-L517

And it will be 0 until we loop again and add the days to allocation

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L521-L522

and since this is happening after we already set the expiring days which in this year will be 0 we won't remove those expiring days from the year's allocation data

### Fix:
We add a condition to check if the actual_lastcall is either a date in the start of the allocation or one of the expiration dates for the carryover.

Also, before we set the value of the expiring_carryover_days we call _add_days_to_allocation to calculate on the correct number of days for the plan level we are checking.

opw-4606886

Forward-Port-Of: odoo/odoo#221433
Forward-Port-Of: odoo/odoo#209669

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/358931f33 [REL] 18.4.5 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/8ab8485e4 [FIX] Color: Support colors with alpha in colorScale helpers [Task: 4951926](https://www.odoo.com/odoo/2328/tasks/4951926)
https://github.com/odoo/o-spreadsheet/commit/808a34539 [IMP] demo: Add error handler [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d2e91ea45 [FIX] chart: chartJS extensions loaded too late [Task: 4954034](https://www.odoo.com/odoo/2328/tasks/4954034)
https://github.com/odoo/o-spreadsheet/commit/b6d9f269a [FIX] Topbar: Fix Z-index [Task: 4981390](https://www.odoo.com/odoo/2328/tasks/4981390)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Steps to reproduce the bug:
- unarchive the subcontracting route
- Create a storable product C1 with the following route:
    - Buy + Resupply Subcontractor on Order
- Create a storable product P1 with:
    - BoM type: Subcontracting - Type: subcontracting - Subcontractor: Azure Interior - Component: C1

- Create a purchase order for 20 units of P1
- Confirm the purchase order
- Validate the resupply transfer
- Go to the receipt of P1
- Record 19.8 units of the component (ignore the remaining 0.2)
- Validate the receipt with no backorder

Problem:
A user error is raised:
```
The operation cannot be completed: The quantity to produce must
be positive!
```

When clicking No Backorder, the `process_cancel_backorder`  method is
called:

https://github.com/odoo/odoo/blob/18.0/addons/stock/wizard/stock_backorder_confirmation.py#L75-L77

This triggers the validation of the picking, so updates the subcontract
order quantity:

https://github.com/odoo/odoo/blob/16a1d9b19b8b07435a9c4b4db2cad3c1e37e4e17/addons/mrp_subcontracting/models/stock_picking.py#L53

At this stage, we check whether it should reduce the MO quantity or
cancel the order entirely. However, the logic compares the quantity to
remove against the initial order quantity without using `float_compare`,
which leads to minor rounding differences. This results to update the
MO quantity to zero instead of canceling it, which then triggers an SQL
constraint error because the MO quantity cannot be zero:

https://github.com/odoo/odoo/blob/e7e2a088495eed3c2886a69054af689c01628f32/addons/mrp_subcontracting/models/stock_move.py#L304-L311

https://github.com/odoo/odoo/blob/29d1f637d3ec6f3ebb218d103001a6182af1b8a4/addons/mrp/models/mrp_bom.py#L93-L95

opw-4905031

Forward-Port-Of: odoo/odoo#221451
Forward-Port-Of: odoo/odoo#219650

Issue Before This Commit:
============================
- Merging a batch that lacks a `scheduled_date` causes a traceback: `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'.`
- Merging a single batch does nothing but still proceeds silently, even though merging a single record has no practical effect.

Steps to Reproduce:
============================

- Install the `stock_picking_batch` module.
- Create two batches, one with a scheduled_date, one without.
- Try merging only one batch → it proceeds silently, which makes no sense.
- Try merging both; a traceback error occurs due to a missing scheduled date.

With This Commit:
============================
- Raise a proper UserError when the user tries to merge fewer than two batches.
- Prevent traceback by filtering out batches without a scheduled date before finding the earliest one.

This commit ensures that users can proceed with the batch merging process without encountering a traceback when one or more batches have no scheduled date. It also introduces a UserError when attempting to merge only a single batch, similar to the behaviour in purchase order merging. Since merging a single record has no practical effect.

Before this commit, the available quantity was incorrect when using the "Inventory At" feature with a past date in the inventory report

For products using multi-step delivery routes, the `_compute_quantities_dict()` method incorrectly treated internal moves as outgoing moves As a result, the same outgoing quantity was added multiple times, leading to an overestimation of the available stock

This commit adds a filter to the `domain_move_out_done` domain used for past dates, excluding internal moves based on `location_dest_usage``

## Steps to reproduce:
- Create a new product
- Active the multi-step routes in Settings
- Set the Warehouse's Outgoing Shipments to Pick, Pack, then Deliver
- Create a RFQ for 100 products and Receive Products
- Create a Quotation for 20 products
- Validate each delivery steps
- Go to Inventory -> Report -> Stock
- Click on Inventory At
- Set the date to 2025-01-01
- Search for your product
- The `In Hand` quantity should be 0 but is 40 before the fix

opw-4848473

Forward-Port-Of: odoo/odoo#217732

When importing a winbooks file the following issues and or inconsistencies may be found

**Issue 1**
We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it will be set as tax payable account id according to https://github.com/odoo/enterprise/blame/d8d4812414dba8825a1c785c29d00f7d0fd98360/account_winbooks_import/wizard/import_wizard.py#L174 However, this means it needs to be a `liability_payable` account with reconcile enable, in order to comply with the following check https://github.com/odoo/odoo/blame/ad6c9001b447f5ffebafe1581512f48708c7d746/addons/account/models/account_tax.py#L80

*Note*
Even if we set it as liability_payable, the import may fail later on in case the same account is used in a sales move where those types of account are not allowed https://github.com/odoo/odoo/blame/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/account/models/account_move_line.py#L1247 A solution is to skip the `_check_payable_receivable` check for winbooks lines

**Issue 2**
Move line data may reference an unkown journal, causing a validation error because no journal is retrieved from the database and a move always need a journal

**Issue 3**
Account created during import may be marked for deprecation, which occurs at the end of the import process.
However, if the account has been used in a tax repartition line, trying to set it as deprecated will raise an error.
https://github.com/odoo/odoo/blame/2cdc41c012f637849ba030989ce928b6b1152e7e/addons/account/models/account_account.py#L1028

opw-4850314

Forward-Port-Of: odoo/enterprise#89426

Issue
-----
On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu.

Steps to reproduce
-----
- Open barcode
- Click the center scan button
- Scan a barcode

--> Traceback

Discussion
-----
There are 2 issues occuring here.

1. We play either an ogg or mp3 file. However, the method to know if the format is supported by the browser returns one of 'probably', 'maybe', ''.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#return_value

This means that when we do

https://github.com/odoo/enterprise/blob/70e5013ea022ed04ff27db71ea3ecccb55ae1f70/stock_barcode/static/src/main_menu/main_menu.js#L37

We might end up using ogg even if the browser doesn't actually support it, as 'maybe' is truthy.

To reduce the risk of this happening, we can specify the codec as "vorbis" (all ogg files of Odoo are vorbis). This is already done in mail:

https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/mail/static/src/core/common/sound_effects_service.js#L46

2. The browser might not have the permission to play the sound. In such cases, the best we can do is try to play the sound and log potential errors.

-----
Ticket:
opw-4820022

Forward-Port-Of: odoo/enterprise#91158

Before this commit, the available quantity was incorrect when using the "Inventory At" feature with a past date in the inventory report

For products using multi-step delivery routes, the `_compute_quantities_dict()` method incorrectly treated internal moves as outgoing moves As a result, the same outgoing quantity was added multiple times, leading to an overestimation of the available stock

This commit adds a filter to the `domain_move_out_done` domain used for past dates, excluding internal moves based on `location_dest_usage``

## Steps to reproduce:
- Create a new product
- Active the multi-step routes in Settings
- Set the Warehouse's Outgoing Shipments to Pick, Pack, then Deliver
- Create a RFQ for 100 products and Receive Products
- Create a Quotation for 20 products
- Validate each delivery steps
- Go to Inventory -> Report -> Stock
- Click on Inventory At
- Set the date to 2025-01-01
- Search for your product
- The `In Hand` quantity should be 0 but is 40 before the fix

opw-4848473

Forward-Port-Of: odoo/odoo#217732

Steps to reproduce the bug:
- unarchive the subcontracting route
- Create a storable product C1 with the following route:
    - Buy + Resupply Subcontractor on Order
- Create a storable product P1 with:
    - BoM type: Subcontracting - Type: subcontracting - Subcontractor: Azure Interior - Component: C1

- Create a purchase order for 20 units of P1
- Confirm the purchase order
- Validate the resupply transfer
- Go to the receipt of P1
- Record 19.8 units of the component (ignore the remaining 0.2)
- Validate the receipt with no backorder

Problem:
A user error is raised:
```
The operation cannot be completed: The quantity to produce must
be positive!
```

When clicking No Backorder, the `process_cancel_backorder`  method is
called:

https://github.com/odoo/odoo/blob/18.0/addons/stock/wizard/stock_backorder_confirmation.py#L75-L77

This triggers the validation of the picking, so updates the subcontract
order quantity:

https://github.com/odoo/odoo/blob/16a1d9b19b8b07435a9c4b4db2cad3c1e37e4e17/addons/mrp_subcontracting/models/stock_picking.py#L53

At this stage, we check whether it should reduce the MO quantity or
cancel the order entirely. However, the logic compares the quantity to
remove against the initial order quantity without using `float_compare`,
which leads to minor rounding differences. This results to update the
MO quantity to zero instead of canceling it, which then triggers an SQL
constraint error because the MO quantity cannot be zero:

https://github.com/odoo/odoo/blob/e7e2a088495eed3c2886a69054af689c01628f32/addons/mrp_subcontracting/models/stock_move.py#L304-L311

https://github.com/odoo/odoo/blob/29d1f637d3ec6f3ebb218d103001a6182af1b8a4/addons/mrp/models/mrp_bom.py#L93-L95

opw-4905031

Forward-Port-Of: odoo/odoo#221451
Forward-Port-Of: odoo/odoo#219650

**Current Behavior:**

When users click on the activities icon, both active and archived activities are displayed. 
This can lead to confusion, as users expect to see only ongoing (i.e., pending or overdue) activities.

**To reproduce this issue:**
1) Install the Contacts module and create two partner records. 
2) Create a late activity for each of the two records. 
3) Mark one activity as Done by clicking the DONE button. 
4) Open the Late Activities for Contacts from the top-right corner.

**Issue:**
Even after marking one activity as done, both activities are shown. 
This results in two late activities appearing, instead of just one active one.

**Cause:**
When an activity is marked as Done, the `action_feedback` method is called via `markAsDone`.
https://github.com/odoo/odoo/blob/7fa14f9b8e2e886243d68d8e04b0798cd801615b/addons/mail/static/src/core/web/activity_model_patch.js#L44-L48
This method archives the corresponding `mail.activity` record.
https://github.com/odoo/odoo/blob/7fa14f9b8e2e886243d68d8e04b0798cd801615b/addons/mail/models/mail_activity.py#L556-L557

But because of the recent changes from the below-mentioned commit, 
we are now showing the archived records.
https://github.com/odoo/odoo/commit/f05c2f9c7942943140c98174f8c86917fc72fc9b#diff-cacfccf65b597df222b166a1c6d80d125bb75a1f2aeabf2eed2e88e189c144f0R59

However, this change was intended to display archived model records 
that still have active activities, not to show archived or completed activities themselves.

**Solution:**

Apply a domain filter to ensure that only active (non-archived) activity records are displayed.

opw-4946120

The aim of this commit is to keep the original foreign amount currency
if the computation ends up close enough to it.

Before this commit:
The reconciliation process was losing so much precision that it could mess up
the reconciliation of one single invoice.

After this commit:
We keep the original amount as it is most probably the correct one.

Context:
With a rate of 1 US$ = 5.421327349 R$ and an invoice of 143.62 R$, we
convert the amount in US$ which is 26.491668921649627 US$.
As we have to round it for the accounting, we end up with 26.49 US$ as
company currency amount, losing the rest of the decimals.
During the reconciliation process, we convert back the US$ to R$ ending
up with 143.61096147501 R$ that have to be rounded to 143.61 R$.

This creates a difference of 0.01 R$ which surfaces later on.

Chosen solution:
As we still have the original currency amount and the rate, we are able
to recompute the raw numbers and we are able to make "fairer" comparison
between the amounts.
If we can confidently tell that the amounts are close enough, we
can just keep the original amount and prevent all those rounding errors
to be taken into account.

opw-4937508

When importing a winbooks file the following issues and or inconsistencies may be found

**Issue 1**
We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it will be set as tax payable account id according to https://github.com/odoo/enterprise/blame/d8d4812414dba8825a1c785c29d00f7d0fd98360/account_winbooks_import/wizard/import_wizard.py#L174 However, this means it needs to be a `liability_payable` account with reconcile enable, in order to comply with the following check https://github.com/odoo/odoo/blame/ad6c9001b447f5ffebafe1581512f48708c7d746/addons/account/models/account_tax.py#L80

*Note*
Even if we set it as liability_payable, the import may fail later on in case the same account is used in a sales move where those types of account are not allowed https://github.com/odoo/odoo/blame/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/account/models/account_move_line.py#L1247 A solution is to skip the `_check_payable_receivable` check for winbooks lines

**Issue 2**
Move line data may reference an unkown journal, causing a validation error because no journal is retrieved from the database and a move always need a journal

**Issue 3**
Account created during import may be marked for deprecation, which occurs at the end of the import process.
However, if the account has been used in a tax repartition line, trying to set it as deprecated will raise an error.
https://github.com/odoo/odoo/blame/2cdc41c012f637849ba030989ce928b6b1152e7e/addons/account/models/account_account.py#L1028

opw-4850314

Forward-Port-Of: odoo/enterprise#89426

Issue
-----
On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu.

Steps to reproduce
-----
- Open barcode
- Click the center scan button
- Scan a barcode

--> Traceback

Discussion
-----
There are 2 issues occuring here.

1. We play either an ogg or mp3 file. However, the method to know if the format is supported by the browser returns one of 'probably', 'maybe', ''.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#return_value

This means that when we do

https://github.com/odoo/enterprise/blob/70e5013ea022ed04ff27db71ea3ecccb55ae1f70/stock_barcode/static/src/main_menu/main_menu.js#L37

We might end up using ogg even if the browser doesn't actually support it, as 'maybe' is truthy.

To reduce the risk of this happening, we can specify the codec as "vorbis" (all ogg files of Odoo are vorbis). This is already done in mail:

https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/mail/static/src/core/common/sound_effects_service.js#L46

2. The browser might not have the permission to play the sound. In such cases, the best we can do is try to play the sound and log potential errors.

-----
Ticket:
opw-4820022

Forward-Port-Of: odoo/enterprise#91158

When a user without enabling 'Batch, Wave & Cluster Transfers' from settings, tries to open the map view for any stock transfer operations (e.g., Receipts, Delivery Orders), a error is raised.

**Steps to Reproduce:**
- Install Inventory App.
- Navigate to 'Receipts' or 'Delivery Orders'.
- Switch to map view.

**Error:**
`ValueError: Invalid field 'batch_sequence' on model 'stock.picking'`

**Root Cause:**
Since [this commit](https://github.com/odoo/enterprise/pull/78373/commits/fddb39104d675af2784559fe2f7cb28f8dc6120b), the `stock.picking.view.map` view has a hardcoded `default_order` attribute that sorts by `batch_sequence` as shown at [1]. This field is only added to the `stock.picking` model when the `stock_picking_batch` module is installed. This creates an invalid view definition, where this optional module is not present, causing an error.

**Solution:**
This commit resolves the issue by removing the `default_order='batch_sequence'` from the stock picking map view at [1]. This ensures the map view no longer depends on the `stock_picking_batch module`.

[1]- https://github.com/odoo/enterprise/blob/5e0380513899f199340620d8ce17eff5b5b6aec3/stock_enterprise/views/stock_picking_map_views.xml#L8

sentry-6732756118

Forward-Port-Of: odoo/enterprise#90399

The method for generating the PDF of an audit report currently crashes when computing the template variables "revenue" and "net accounting result".

This issue arises because the underlying method used to compute these values runs raw SQL queries that perform a JOIN operation on the `account_currency_table`. However, this table is not created automatically by the system: It must be explicitly initialized by calling the method `_init_currency_table`.

This commit updates the code to ensure that `_init_currency_table` is called before invoking the methods that compute the total revenue, the net accounting result, etc. This should prevent the crash and allow the template variables to be computed correctly.

Steps to reproduce the issue on the runbot:
1. Open the Accounting App
2. In the navbar, click on "Accounting" > "Audit Reports"
3. Create a new audit report
4. Fill the form and save
5. Click on the "Print" button of the kanban card.

=> A new page should open displaying an internal error.

In the log of the runbot, we have the following log:

```
File "/data/build/enterprise/account_reports/models/account_report.py",
line 3899, in _compute_formula_batch_with_engine_domain
    self.env.cr.execute(query)
  File "/data/build/odoo/odoo/sql_db.py", line 426, in execute
    self._obj.execute(query, params)
psycopg2.errors.UndefinedTable: relation "account_currency_table" does not exist
LINE 10:                     LEFT JOIN account_currency_table
```

Task-4840940

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