This is a complement to previous fix https://github.com/odoo/odoo/commit/649a7f185dca806af3b3d54a1e4390b9baff79c6 in which the use case where both companies have "Round Globally" set as "Rounding Method" was not handled.

**Steps to reproduce:**
- Install Sales & Accounting
- Create a second company with a different currency (e.g. AED) than the first one (e.g. USD)
- Configure the rounding factor of the currency of the second company to 1.000000
- Configure the default company of the current user to the second company
- Switch to the second company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Switch to the first company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Create a SO:
  * Customer: [any]
  * Order Lines: [any line with a tax]
- Save the SO
- Edit the SO by changing the price unit of the product !!! Make sure that the tax amount has a decimal part
- Save the SO

**Issue:**
In the chatter, the note about the new value of the tracked field Total is different from the Total value shown in the SO. Also, in Customer Preview, the total to pay shown on the upper-left of the page is different than the total shown in the SO details.

opw-3814058



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

Forward-Port-Of: odoo/odoo#174560

[FIX] website_crm_partner_assign: fix sitemap grades

Context: when visiting the `/partners` url, the user has access to the
"silver", "gold" and "platinum" grades. However, when generating the
sitemap, the `/partners/grade/bronze-4` url is part of it but trying to
access it leads to a 404 server answer. Another problematic behavior is
that if the user deactivates a grade ("gold" for example), the grade is
still accessible from `/partners` (but the `/partners/grade/gold-2` url
is not on the sitemap anymore).

This can be explained as:
- When visiting the `/partners` url, the `partners` route searches for
grades from `request.env['res.partner']`. By doing so, it ensures that
grades are linked to at least one partner; this explains why the
"bronze" grade (not linked to any partner) is not shown at the
`/partners` url and why the deactivated "gold" grade is still
accessible (as a partner is still related to it).
- When the user tries to reach a `/partners` route, a 404 server answer
is returned if no partners are found for the route (e.g.
`/partners/grade/bronze-4`).
- When generating the sitemap, the system is searching for grades from
`env['res.partner.grade']`. Due to it, inactive grades (e.g. "gold") are
not shown on the sitemap and grades that are not linked to a partner
(e.g. "bronze") are shown on the sitemap.

The goal of this commit is to:
- Correct the `/partners` route so that it does not show inactive
grades.
- Generate the sitemap coherently from what is done in the `/partners`
route.

In the end, the `/partner` route only shows company website published
partners linked to active website published grades. The user has then
the possibility to filter the partners by grades or by country.

opw-3992340

Forward-Port-Of: odoo/odoo#174250
Forward-Port-Of: odoo/odoo#170582

`stdnum` library incorrectly sets `zeep` `Transport` timeout, resulting in
some requests hanging for 15 minutes. With this monkeypatch the timeout
will be set correctly. The monkeypatch is a full copy of the original
code except for adding `operational_timeout` to the `Transport` initialization.

The monkeypatch can be removed when https://github.com/arthurdejong/python-stdnum/issues/444 is resolved and the version is upgraded.

Related zeep github issue: https://github.com/mvantellingen/python-zeep/issues/140
This fix was already merged but reverted due to an unexpected side-effect:
Original commit: https://github.com/odoo-dev/odoo/commit/11062f6f77ed1292c6db9d64985dddeb46d354c8
Revert: https://github.com/odoo-dev/odoo/commit/de9df2ba5c15d399d6906ef54f3e4ac9f063a175

The issue originated from a dependency issue in the `zeep` library in [Ubuntu 22.04](https://packages.ubuntu.com/jammy/python3-zeep).
The `python3-platformdirs` dependency is missing in there, yet it is used in that version of `zeep`. This missing dependency used to be hidden by the [chains of `try ... except ImporError` of `stdnum`](https://github.com/arthurdejong/python-stdnum/blob/d5666b8bfe379688a38bb0fd6764a8c536dd3c75/stdnum/util.py#L254).
That means that it's another import from the chain that was used. So to reduce the possibility of introducing a similar bug and catch such errors, the original code from `get_soap_client` of `stdnum` has been fully copied.

opw-3980718

Forward-Port-Of: odoo/odoo#174199
Forward-Port-Of: odoo/odoo#173359

Before this commit, when calling `_getSaveLineCommand` to get the save commands for the move lines, we do each line one by one, in the order where they were marked as to save, which means we can have an update command followed by a create command, itself followed by another update command for example.

In the module `stock_barcode_picking_batch`, we add the test `test_barcode_batch_scan_lots`. In this test, we got a situation where we will write on the batch a command like that:

```python
{
    'move_line_ids': [
        [UPDATE command],
        [CREATE command],
        [UPDATE command],
        [CREATE command],
        [CREATE command]
]}
```
The 2 first commands are for the move lines in the first batch's picking. The 3 last commands are for the move lines i the second batch's picking.

The issue is, the first CREATE command won't happen. The two move lines for the second picking will be created but the move line who should be created for the first commit will not.

It fails because the compute has a depends on himself. And it's recomputed on picking_ids that have a different cache than the batch. So the second UPDATE will trigger the compute that will rewrite the move_line_ids fields and cancel the first CREATE. So it means every CREATE commands before the last UPDATE will be ignored

Enterprise PR: odoo/enterprise#65182

Forward-Port-Of: odoo/odoo#173521