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