**Steps to reproduce:**
- Install l10n_cl
- Switch to a Chilean company (e.g. CL Company)
- Activate a foreign currency (e.g. USD)
- Make sure that the rate of the foreign currency is not 1 For example:
  * Unit per CLP: 0.001057876419
  * CLP per Unit:945.29
- Create an invoice in USD with 2 lines having different amount:
  * 15.80
  * 15.00
- Save the invoice
- Print the invoice

**Issue:**
On the printed invoice, a slightly different currency rate is displayed for each invoice line.

**Cause:**
The currency rate to display is computed for each invoice line, based on the following formula:
`abs(self.balance) / self.price_subtotal`
However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it.

**Solution:**
Compute the rate from the total values instead of the subtotal of each line.
The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice.

opw-4242448


Linked enterprise PR: https://github.com/odoo/enterprise/pull/73035

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

Forward-Port-Of: odoo/odoo#185230

When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this behaviour is to add a stored field whose default value uses translations, while at the same time adding any other stored field. If the translation is fetched in a sudo environment we can get an error when the System partner has `NULL` language.

Steps to reproduce:
1. On a cleanly initialized DB (only `base`) add any extra language (en_GB would do).
2. Open Users & Companies (show inactive users) open System user.
3. Open Related Partner.
3. In the form view of the System partner set the language to None.
4. Try to install via the command line a module with the fields as described above (see below for a code example).

We get an error like:
```
2024-10-30 08:48:40,831 41180 INFO test_16 odoo.modules.registry: module mymodule: creating or updating database tables
2024-10-30 08:48:40,839 41180 ERROR test_16 odoo.sql_db: bad query: SELECT "res_company"."id" AS "id", "res_company"."name" AS "name"
... <many more fields, redacted>  ... "res_company"."bar" AS "bar", "res_company"."foo" AS "foo" FROM "res_company" WHERE "res_company".id IN (1)
ERROR: column res_company.foo does not exist
LINE 1: ...e" AS "write_date", "res_company"."bar" AS "bar", "res_compa...
```

The solution we propose is to skip the prefetch of `res.company` fields when we are in the process of guessing the language. In this case the language is correctly picked from the System partner's company.

This issue has been observed in many upgrades to 18, but it's present in older Odoo versions as well. The language field in `res.partner` is not required, thus it is also possible to set the language to `NULL` via code.

Example data observed in upgrades:
```
> select id,name,active,lang from res_partner where lang is null
+----+-----------------------+--------+--------+
| id | name                  | active | lang   |
|----+-----------------------+--------+--------|
| 4  | Public user           | False  | <null> |
| 5  | Default User Template | False  | <null> |
| 6  | Portal User Template  | False  | <null> |
| 2  | System                | False  | <null> |
+----+-----------------------+--------+--------+
```
There may be other standard flows that lead to such setup where System partner has no language set.

Example inherit of `res.company` that triggers the issue:
```py
class A(models.Model):
    _inherit = "res.company"

    bar = fields.Many2one(
        comodel_name="ir.sequence",
        default=lambda self: self.env["ir.sequence"].sudo().create({"name": _("Dummy")}),
        required=True,
    )
    foo = fields.Integer()
```

Standard example of this code pattern that triggers the issue during upgrades to 18:
https://github.com/odoo/odoo/blob/dd71d998/addons/account/models/company.py#L140-L152

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

Forward-Port-Of: odoo/odoo#185810

This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by tax calculators are only informational. When they return e.g. 5% tax, the actual amount can be different from 5% because of differences in rounding or (partial) exemptions. The authoritative tax is returned as a value amount (e.g. $10). Because of this, we cannot rely on Odoo to calculate the tax from account.tax records. It's not always going to match.

It's not possible to fix this by externally calculating taxes on the down payment invoice. The single down payment line cannot accomodate all different tax categories. Creating a down payment line per tax category (e.g. avatax_category_id) was considered, but a specific down payment product would need to be created per used tax category which would clutter the database. On top of that, down payment products are removed in later versions [1] which would complicate this approach even further.

This solves the issue by not calculating taxes on down payments at all. The down payment invoice will not be sent to external tax calculators. The resulting down payment lines on the SO won't have taxes set, and those lines will be excluded from the request to the external tax calculator. The final, "regular invoice" transaction will happen as if no down payments were made. The down payment lines won't be sent, so this will look like a regular invoice from the external calculator's view.

By default, the downpayment lines equal the subtotal of the selected down payment amount. We remove tax_ids from the lines because we cannot count on calculating tax locally (see above). To keep the behavior analogous we override the downpayment wizard to create a single down payment line with a total equal to the entered total in the wizard.

[1] odoo/odoo@9aa52dd6418e5881adc2d96d15d062b55d6150c5

opw-3971513

Forward-Port-Of: odoo/enterprise#73027
Forward-Port-Of: odoo/enterprise#70517

**Steps to reproduce:**
- Install l10n_cl
- Switch to a Chilean company (e.g. CL Company)
- Activate a foreign currency (e.g. USD)
- Make sure that the rate of the foreign currency is not 1 For example:
  * Unit per CLP: 0.001057876419
  * CLP per Unit:945.29
- Create an invoice in USD with 2 lines having different amount:
  * 15.80
  * 15.00
- Save the invoice
- Print the invoice

**Issue:**
On the printed invoice, a slightly different currency rate is displayed for each invoice line.

**Cause:**
The currency rate to display is computed for each invoice line, based on the following formula: abs(self.balance) / self.price_subtotal However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it.

**Solution:**
Compute the rate from the total values instead of the subtotal of each line.
The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice.

opw-4242448


Linked community PR: https://github.com/odoo/odoo/pull/185230

Forward-Port-Of: odoo/enterprise#73035

### Steps to reproduce:

- Enable "Multi-Steps Routes" in the settings
- Add a barcode to a different location that WH/Stock
- Go to the barcode > Operations > Internal Transfers > New
> The header propose to scan a product
- Do not scan the product by click on `+ ADD PRODUCT`
- Add 1 unit of your favorite product
> The header propose to scan a product or a destination location
- Scan the location you had set
#### > The location scan is ignored

### Cause of the issue:

During the `_parseBracode` called to determine what was scanned by the barcode, a location corresponding to the barcode scanned will be found. To use this barcode, if it makes sense, the `_setLocationFromBcode` will be called in turn. However, during internal transfers, this location will only be used as a destination location under very specific conditions:
https://github.com/odoo/enterprise/blob/8035abddf9991f6bfb71bb7889b703e5ed31a179/stock_barcode/static/src/models/barcode_picking_model.js#L1603-L1619 And, since we did add the product manually rather than using a scan, in our case, `this.previousScannedLines.lengt` will be null rather than positive so that the location will not be used to set the destination.

opw-4201489

Forward-Port-Of: odoo/enterprise#72582
Forward-Port-Of: odoo/enterprise#72283