**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings**
> How to reproduce:
> - Create a product tracked by lots and set a barcode for this product;
> - Create a receipt for this product, with at least 2 quantities and confirm it;
> - Create a second similar receipt (you can duplicate the first one) and confirm it;
> - Add these two receipt in a new batch and confirm the batch;
> - Go in the Barcode App and open the batch, you should have two lines, one for each picking;
> - Scan the product -> the first line should be selected;
> - Scan a lot -> the lot is set on the first line and its qty is incremented;
> - Scan another lot -> the lot is set on the second line and its qty is incremented. That's the issue.
> 
> Expected behavior:
When another lot is scanned after the first one, since we are picking quantity for the first picking, the line for the second picking shouldn't be selected until the first one is processed.
To fix that, the search for a line following the scan will avoid to take a tracked line if its `picking_id` is not the same than the selected line and if the selected line is not completed. 

**[FIX] stock_barcode: increment right qty**
> When a product tracked by lots is reserved and multiple lots are reserved, in the Barcode App, each line has a "+ qty" button where the quantity is the remaining quantity.
That said, this remaining quantity was always computed regarding the difference between the move line's done and reserved quantity which means if the user scans a not reserved lot, those buttons aren't reliable anymore.
> 
> How to reproduce:
> - Create a product tracked by lots and set a barcode;
> - Update the quantity on hand for this product like following:
>   - 3x lot1
>   - 3x lot2
>   - 3x lot3
> - Create a delivery for 6x this product and confirm it;
> - Open the delivery in the Barcode App, unfold the line for the tracked product, you should have:
>   - 0/3 lot1, [+3]
>   - 0/3 lot2, [+3]
> - Scan lot1 one time and lot3 three times, you now have:
>   - 3 lot3, [+1]
>   - 1/3 lot1, [+2]
>   - 0/3 lot2, [+3]
> -> Since the total demand is 6 and 4 quantities have been processed, no button should display a quantity greater than 2 since it's the remaining quantity.
> 
> To fix that, the quantity used by the increment button is also computed regarding the parent line's quantity.

task-3688770

Forward-Port-Of: odoo/enterprise#67045
Forward-Port-Of: odoo/enterprise#54589

How to reproduce:
=================
- Enable "Storage Locations";
- Create a product with a barcode and add some qty in a sublocation (e.g.: 10 products in Shelf 1);
- Create an internal transfer from WH/Stock to WH/Stock for this product for at least 2 qty;
- Confirm the internal transfer and open it in the Barcode app;
- You can see you have one line, from WH/Stock/Shelf 1 to WH/Stock (if we follow previous example);
- Scan one time the product, then scan another location (eg.: shelf2), the line will be split.
=> Issue here: the line for the remaining quantity has WH/Stock as source location instead of Shelf 1.

Expected behavior:
==================
The source location of the split line doesn't change.

Explanation:
============
When a line is split, a new line is created for the remaining quantity. But the issue is, when a new line is created, it uses the picking's source location (or the previous scanned source) as the default location.

OPW-4016136

Forward-Port-Of: odoo/enterprise#66360

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