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

**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