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

Steps to reproduce:
- New Project > New Task > Timesheet 10h on task
- New subtask on task > Timesheet 5h on subtask
- Reporting > Tasks Analysis

Remaining hours are computed incorrectly, when no allocated hours are
set on a task, we have null values in database that prevent the
computation of allocated_hours and remaining_hours which also messes up
the project totals. The computation of remaining hours is also only
supposed to occur when we have a non zero amount of allocated hours,
otherwise the remaining hours are always 0.

Additionally, the 'Total Hours' column is confusing for customers
as it is meant to compute the total hours spent on a task (subtasks
included) but is enabled by default when looking at the projects as a
whole which does not make sense.

For instance, with 'Task' parent of 'Subtask':
| Name     | Allocated | Hours spent | Remaining  | Total Hours |
| -------- | --------- | ----------- | ---------- | ----------- |
| Project  | 0         | 15          | -15 (-> 0) | 20          |
| Task     | 0         | 10          | -10 (-> 0) | 15          |
| Subtask  | 0         | 5           | -5  (-> 0) | 5           |

The sum of total hours on project is meaningless and confusing so it is
preferable not to have it enabled by default (Subtask is counted twice,
once in Task and once itself).

opw-4236984

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

Forward-Port-Of: odoo/odoo#185733
Forward-Port-Of: odoo/odoo#184291

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

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