Currently, when buying a product with a division tax using price included
the base price used to compute the total is not correct and will show a wrong total value.

Steps to reproduce:
-------------------
* Go into the **Accounting** app
* Under **Configuration** select **Taxes**
* Create a new Tax
  * Tax Computation: `Percentage of Price Tax Included`
  * Amount 10%
  * Advenced Options > Included in price: `True`
* Go to the **Point of sale** App
* Create a new product.
  * Price: 200
  * Tax: the one just created
* Open shop session
* Create an order with the new product and pay it
> Observation: On the receipt, on the tax details, we can see: Tax: 10%, Amount: 20, Base: 200, Total: 220. This is not correct, the client paid 200 as tax is included in price.

Why the fix:
------------
Currently the Base value on the receipt is given `taxValues.base`. The same quantity is also used for the computation of the Total shown.

https://github.com/odoo/odoo/blob/49cecec35421cc36258f900d99c1040596601167/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.xml#L75-L76

However, if we look where the `taxValues` come from we see that they correspond to `tax_details` in `export_for_printing`.
https://github.com/odoo/odoo/blob/49cecec35421cc36258f900d99c1040596601167/addons/point_of_sale/static/src/app/store/models.js#L1314

When checking the function `get_tax_details` we realize that `taxValues.base` actually refers to the `display_base`
https://github.com/odoo/odoo/blob/49cecec35421cc36258f900d99c1040596601167/addons/point_of_sale/static/src/app/store/models.js#L2228

As disucssed with LAS, here is how the values on the receipt should be computed:
```
Amount = amount = 20
Base = display_base = 200
Total = base + amount = 180 + 20
```

Technically, prior to the fix, here is how the value shown are computed:
```
Amount = amount = 20
Base = display_base = 200
Total = display_base + amount = 180 + 20
```

This computation is problematic only in the setting explained earlier as this is the only one which will have a different value for `base` and `display_base`:
https://github.com/odoo/odoo/blob/b8baa83e575a36dd539c9fda10d5ffbe3ef01183/addons/account/static/src/helpers/account_tax.js#L408-L411

Why do we write
```<span t-esc="props.formatCurrency(taxValues.display_base || taxValues.base, false)" />```
instead of just
```<span t-esc="props.formatCurrency(taxValues.display_base, false)" />``` with the changes currently applied in `get_Tax_details`?

Well, when using the kiosk, information about the `display_base` does not exist in `_compute_tax_details`:
https://github.com/odoo/odoo/blob/b8baa83e575a36dd539c9fda10d5ffbe3ef01183/addons/pos_self_order/models/pos_order.py#L41-L61

Thus we avoid an error when using the function `export_for_printing` by using `taxValues.base` as there is no `taxValues.display_base` provided.

This is currently the only other time where the function `export_for_printing` sets the value sent for `tax_details`.

opw-4032366

Currently, when a loyalty program has a reward of type product and uses `reward_product_tag_id` (set up for at least 2 products), the addition of rewards to the pos order will have mismatched reward lines when adding the second free product (the first product needed to be added first).

Steps to reproduce:
-------------------
* Go to **Point of Sale** App
* Go to **Products** and add a tag (the same) for two products
* Under **Products** select `Discount & Loyalty`
* Create a new program of type **Buy X Get Y**
* Rule:
  * Min qty: 2 products $0.00
  * Among Products: Put all chairs products for example
* Reward:
  * Type: Free Product
  * Product: None
  * Product tag: The tag put on the products previously
* Open shop session
* Add 2 chairs
* Select reward, add the first one
> Everything ok until now
* Add 2 chairs
* Select reward, add the second one
> Observation: Reward computation is wrong we have the following lines:
  ```
  4 Chairs,
  Reward 1,
  Reward 2,
  Free product reward 1
  ```
  > We are missing the free product line related to the second product added and the button to select reward is still highlighted.

Why the fix:
------------
To explain this fix I will use the example given above.

Here are the steps that have been executed already
* Add 2 chairs
* Add the first reward product
* Add 2 chairs

We are currently in the middle of the step "Add second reward product". During that process, we end up in the function `_computeUnclaimedFreeProductQty` while computing values for the reward line. At this very moment in time, the order has the following lines:
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2 

Where Product 1 and Product 2 are the reward products, having the same tag.

Let's focus on this piece of code, with the current example: https://github.com/odoo/odoo/blob/76023820c4d725c81677d2bf3e010c8cee1edd19/addons/pos_loyalty/static/src/js/Loyalty.js#L1464-L1475

Where `product` in this case is `Product 2`. What is happening here at the end is that we have `available = 1` because of line 4 and `claimed = 1` because of line 3. The program considers that we have already claimed the quantity and is the reason why it is not adding the reward line.

The first idea to fix this issue was to write the condition:
```js
if (reward.reward_product_ids.includes(product.id) && reward.reward_product_ids.includes(line.product.id)) {
```

instead of this one
```js
if (line.get_product().id === product.id) {
```

Now both line 2 and 4 are counted toward the `available` quantity. This way the code knows that we have two availaible free product but only 1 was claimed.

While this fixed the original issue, a new issue was created. Now, when we add the second product, the two reward lines were grouped together, using the price of the first free product added. Why was this happening?

Well, once the fist call to the function `_computeUnclaimedFreeProductQty` was done and the reward line was added we had the following order (temporarily)
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2
* Free product (related to Product 2)

Which is what we expect but we face an issue when the loyalty programs are updated. When the programs update, we go through the function `_updateRewardLines`. In this function we discard the reward lines from the order and then for each claimed reward (Product 1 and Product 2) we re-apply the reward.

While applying the reward for Product 1, we again go through the function `_computeUnclaimedFreeProductQty`. In this case, the order looks like this:
* 4 Chairs
* Product 1
* Product 2

and the function will say that there are 2 available free product and 0 claimed. Were it is technically true, in this case we want to have the available quantity to 1. We want the initial condition:
```js
if (line.get_product().id === product.id) {
```

In the second passage, for product 2, we have `available = 2` and `claimed = 2`.

opw-3587020

Forward-Port-Of: odoo/odoo#175514
Forward-Port-Of: odoo/odoo#173529

Steps to reproduce the bug:

- In Website edit mode.
- Drag and drop enough snippets to have a vertical scrollbar.
- Scroll the page to the top.
- Drag and drop a dynamic snippet (e.g. Products) at the bottom of the viewport.
- Bug: The page doesn't scroll to the dynanmic snippet.

The bug was due to the fact that we needed to know the top position of the snippet to set the scroll value. However, it wasn't possible to get the offset of the element because the dynamic snippets were set to "display: none" when this calculation was made.

It's a bug we had before and fixed with this commit [1]. It worked. But since this other commit [2] where dynamic snippets are no longer hidden with the Bootstrap class "d-none" but with the class "o_dynamic_empty", the fix no longer works.

[1]: https://github.com/odoo/odoo/commit/963f0ed02eba929fcbc65fe51bef95c2a1dcf2ea
[2]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878

task-4072655

Forward-Port-Of: odoo/odoo#175207

**Description**

- From 16.0, while opening invoices of accounting and clicking on the web studio button, it is showing traceback for French localization of the "l10n_fr" module. As per [this](https://github.com/odoo/odoo/pull/171275) file in V16, module [l10n_fr_invoice_addr] has been optimized to adapt the documents as per new French law. Although, the traceback is showing due to the fact that while performing the "l10n_fr_invoice_addr" module's view, the "shipping_field" has set the groups to null in this [account_move.py](https://github.com/odoo/odoo/pull/171275/files#diff-5125aad1cd2220c7e0c4cfe80ec0541acf5e9f4dbce46fb370e94cd281012b36R17) file which should not be the case. Due to this, as per this [condition](https://github.com/odoo/odoo/blob/16.0/odoo/models.py#L1464), it is trying to find groups in V16.0, which will lead to traceback as the groups are set null here. Whereas in stable version 15.0, it was working due to the fact that previously the groups were set to null through the [account_move.xml](https://github.com/odoo/odoo/blob/15.0/addons/l10n_fr_invoice_addr/views/account_move_views.xml#L9) file.

- As a result, to resolve this issue this commit will pop the groups of "shipping_field" instead of setting it to null to bypass the traceback for the invoices of "l10n_fr" localization. 

**Steps to Reproduce (V16.0)**

- Change the language to French. 
- Install "l10n_fr" module
- Get an FR company.
- Create an invoice, it's partner(customer) should be of FR , then confirm the invoice.
- Open the invoice and then click on the web studio button.

**Solution**

- To resolve this issue this commit will pop the groups of "shipping_field" instead of setting it to null to bypass the traceback for the invoices of "l10n_fr" localization. 

**Current behavior before PR:**

![V16_behavior](https://github.com/user-attachments/assets/de318ec6-664c-427e-a497-3322b6ee445c)

---
opw-[4044861](https://www.odoo.com/odoo/project.task/4044861?cids=2)

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

Forward-Port-Of: odoo/odoo#173162

The purpose of this PR is to be able to process a lot of serial numbers at once. In receipt and deliveries
In the current situation, the number of serial already in stock has an impact on the perf (due to `update_available_quantity` that do a `_gather` on current stock). All the metrics below are made with 50 000 SN already in stock

Before (in seconds):
|| Receipt | Delivery |
|--------|--------|--------|
|100| 1.63 | 34.21 |
|5000| 87.04 | 242.56 |
|30 000| 563.75 | T.O. | 

After:
|| Receipt | Delivery |
|--------|--------|--------|
|100| 0.91 | 5.62 |
|5000| 47.21 | 56.28 |
|30 000| 195.27 | 307.80 | 

By operations/ receipts (for 5000):
|  | action_assign | button_validate | total |
|--------|--------|--------|--------|
| Before patch | 5.38 |  82.02 | 87.04 |
| After patch | 3.82 |  43.39 | 47.21  |

By operations/ deliveries (for 5000):
|  | action_assign |  button_validate | total |
|--------|--------|--------|--------|
| Before patch | 180.06 | 62.50 | 242.56 |
| After patch | 20.51 |35.77 | 56.28 |

The main issues:
- The constraint check on quant/stock.move.line are done one by one since there is nothing done in batch, same for computed field (Not fixed here)
![delivery-pre-patch](https://github.com/odoo/odoo/assets/5512395/8a7294f1-67b9-45aa-8aa9-8cf3cfc071be)
- The put away takes an important amount of times without any putaways rules
![putaways](https://github.com/odoo/odoo/assets/5512395/43e63984-2724-409e-ad31-91d193ea3c0c)
- The optimisation made in  #116803 was a good idea but it was only use in action_assign. `_action_assign` use strict=False in `_gather` (mts case). It means a child_of operator is in the domain, and it will perform an extra query anyway
- The lot_name matching to lot_id is made `stock.move.line` by `stock.move.line` on 30 000, half of the time is spent to find them.
![search_lot_name](https://github.com/odoo/odoo/assets/5512395/83a16210-f85e-4a48-bab8-7db269343b1c)

After some testing. The quant_cache could contain too many items than needed by the current operation. Example receive 1 serial number (that will not have an existing quant) will use a quant_cache with all the serial number of the products. As a result, the group by will be super slow. Allow to add an extra domain, to limit the cache size. /!\ could be dangerous if it filter out too much
![extra_domain](https://github.com/odoo/odoo/assets/5512395/42921423-b38d-4686-897f-d2a2c16e9d97)

Forward-Port-Of: odoo/odoo#163799
Forward-Port-Of: odoo/odoo#146494

**Steps to reproduce:**
- Install Accounting
- Go to "Accounting / Configuration / Accounting / Chart of Accounts"
- Create an account (e.g. Test Account)
- Go to "Accounting / Accounting / Miscellaneous / Journal Entries"
- Create a journal entry:
  * Journal Items:
------------
        Account    |    Debit    |    Credit
    --------------------------------------------
     Test Account  |    $0.00    |    $410.34
         [any]     |   $410.34   |     $0.00

- Post the journal entry
- Go to "Accounting / Accounting / Management / Automatic Transfers"
- Create an automatic transfer:
  * Origin Accounts: Test Account
  * Automated Transfer:
-----------
        Percent (%)    |    Destination Account
    -----------------------------------------------
           15.00       |           [any]
           42.50       | [any, but a different one]
           42.50       | [any, but a different one]

- Activate the automatic transfer
- Compute transfer

**Issue:**
A UserError is raised while trying to create a journal entry because of a $0.01 difference between the total credit and the total debit.

**Cause:**
When the amounts of each line are computed from the percentage, they are not rounded.
These amounts are used to create the journal entries generated by the automatic transfer.
However, each created journal entry line is rounded, which can generate a rounding difference.

**Solution:**
Directly round the amounts when they are computed from the percentage to be sure that the amounts used for the computation and the ones that will be set in the journal entries are the same.

opw-3998808

Forward-Port-Of: odoo/enterprise#67693
Forward-Port-Of: odoo/enterprise#67644

### Steps to reproduce:

Have 2 companies: CO1 and CO2

- In the setting, enable Multi-Step Routes and Inter-Company Transactions
- With CO1 and CO, enable Synchronize Sales and Purchase Order 
- Go to Inventory > Configuration > Warehouse Management > Routes
- Unarchive the MTO Route
- With CO1 create a route with a buy action and destination CO1/stock
- With CO2 create a route with a manufacture action 
- Go to Inventory > Configuration > Products > Attributes
- Create a product attribute with a value that "is_custom"
- Create a storable product P with using MTO and tour CO1 and CO2 routes
- Set CO2 as a vendor for the product
- With CO1, create a SO for 1 unit of your product P
- a popup asks you for a custom product attribute value, write "test"
- Confirm the SO > Automatically creates a PO (w/ description)
- Confirm the PO > Automatically create an SO in CO2 (w/ description)
- Confirm the SO in CO2 > Automatically create an MO

#### Issue:
#### The custom description is missing on the final MO.

#### Note:
If you were to create an SO directly in CO2 for 1 unit of P, the custom description associated with the custom attribute value would be present on the associated MO.

### Cause of the issue:

The MO is created by a procurement generated from the SOL during the call of the `_action_launch_stock_rule` method:
https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L345 
The custom description that will appear on the MO and containing the informations related to the custom attribute values is generated here: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L267 
However, this method will return an empty string because the `product_custom_attribute_value_ids` is absent from our SOL https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale/models/sale_order_line.py#L338-L347 
On the other hand, this `product_custom_attribute_value_ids` was set and is still existing on the original SO that started the flow in CO1. The reason that it is not present anymore on the last SO is because this SOL field has no equivalent on the `purchase.order.line` model and the information was therefore forgotten on the MO and has not been transferred directly from the PO of CO1 to the SO of CO2.

### Fix:

We rely on the `sale_line_id` field of the `purchase.order.line` model in order to determine the original SOL of the final SOL and update the `product_custom_attribute_value_ids` accordingly.

### Note:

As a side effect of our change in `sale_purchase_stock` linking our sol to the pol via the procurement commit 63ef74b can be reverted since the message is already automatically posted (the message is now written by the user who cancelled the SO rather than Odoobot).

opw-3998861
---

Forward-Port-Of: odoo/enterprise#67172

### Main Issue:
When creating a sales order that triggers a delivery via Sendcloud, the delivery address on the label may be incorrect. It is due to a limited regex when trying to extract the house number from the 'street' field of the partner.

### Main change:
Updated the regex pattern used to extract house numbers from postal address lines to increase accuracy and cover more address formats.

### Before:
- Regex Pattern: `([1-9]+\w*)`
- Explanation: This pattern captures one or more digits (not starting with zero) followed by any number of word characters (letters, digits, or underscores).

### After:
- Regex Pattern: `(\d+[-\/]?\d* ?[a-zA-Z]?\d*)(?![a-zA-Z])`
- Explanation: This improved pattern captures a broader range of house number formats, including those with dashes, slashes, spaces, and letters.

### Examples of the Differences:

    "Friedrichstr. 13/1"
        Before: '13'
        After: '13/1'

    "Rue du pont 11 A"
        Before: '11'
        After: '11 A'

    "Place Albert 1er 15B"
        Before: '1er'
        After: '15B'

    "123-456 Main Street"
        Before: '123'
        After: '123-456'

    "789 C Oak Avenue"
        Before: '789'
        After: '789 C'

[opw-4042552](https://www.odoo.com/odoo/project/49/tasks/4042552)

Forward-Port-Of: odoo/enterprise#67286