### Issue:

A quantity of `3` gets displayed as `3.00...004`.

### Steps to reproduce:

- Settings > Technical > Database Structure > Decimal Accuracy
- Change the `Digits` of `Product Unit of measure` to 5
- Create a storable product P1 with a BOM: - In the operation tab: one operation in `Assembly line 1` - In the component tab: 1 unit of P2 consumed in the operation
- Create and confirm an MO for 3 units of P1
- Go to the shopfloor module, remove the MO ready filter Two issues can be noticed:
- Click on Register Production A pop up opens. Before validating it:
The displayed producing quantity of P1 and the quantity of P2 that should be consumed by the operation is`3.00...004`. After validation, the produced quantity is rounded. However, if you click on the cross the rounding error will remain. In addition, the second rounding issue will remain even after validation of the consumed qty.

### Cause of the issue:

Our float utils introduce tiny rounding errors, especially at higher precisions. In our case, these errors are introduced during the call of the write method of the `web_save`.

### Fix:

We eliminate the rounding errors for the display in the same way as initially ptoposed by https://github.com/odoo/enterprise/pull/58880
see commit https://github.com/odoo/enterprise/commit/1c2f0068d319917bb4af163396d0861a1ff6c9e1 and adapt it to also apply to the raw_move_ids of the MO.

opw-3861892
---

Forward-Port-Of: odoo/enterprise#62510

This PR introduces a `l10n` test over the Balance Sheet reports.

Each Balance Sheet report in the `LOC_DATA` global at the head of the file will be tested.
The test generates a journal entry with a line in every account that is not `off_balance`.
It then checks whether the Balance Sheet is balanced.
The test does this both for debits and for credits.

The test will give a warning for any installed Balance Sheet report which is not specified in the LOC_DATA global. The aim is to change this to an error once all existing Balance Sheets are tested, to make this test mandatory for any new localizations.

For each localization with a Balance Sheet, the test needs to know the XMLIDs of:
- the CoA
- the Balance Sheet report
- the Total Assets line of the Balance Sheet
- the Total Liabilities line of the Balance Sheet
- the Total Equity line of the Balance Sheet (if applicable)

Setting the global `IDENTIFY_INCORRECT_ACCOUNTS` to `True` switches the behaviour of the test: it identifies the accounts that cause the imbalance using a binary search. This is off by default for runbot. 

**Performance impact**
- For each Balance Sheet, the test does the following:
     - load the chart template
     - create an account.move with 4 AMLs for each account (one debit and credit in the account; and one debit and credit in the counterpart account)
     - generate the report once.
- The Binary Search (which can be toggled when testing locally) is quite efficient: 
    - If there is just one incorrect account, then the report needs to be generated `log2(<number of accounts>)` times.
    - If there are `X` incorrect accounts, then in the worst-case the report may need to be generated `X * log2(<number of accounts>)` times.

On the Belgian CoA, with no incorrect accounts, the test takes 14s on my PC. With 4 incorrect accounts, the test takes 33s.

Task: 3060790

Forward-Port-Of: odoo/enterprise#66007
Forward-Port-Of: odoo/enterprise#36838

Before this commit, selection item options were not updated properly.

1. When adding some options, validating and then removing the options
and go to sign, the removed options would still be there.
This happened because when passing an empty array to the backend
it would be recognized as an empty set of commands,
it's like we are telling odoo to do nothing.

To fix this we use the command [6, false, [new_ids]].

2. `state.option_ids` were updated using `changes.option_ids` which is very fragile,
for example in 16.0 we the changes are given in the form of `[6, false, [id1, id2, ..]]`
but in 17.0 we have a list of commands for adding and removing for example `[[4, id1], [3, id2]]`
To count on some fixed form of updates would introudce bugs if this form changes in future.

To fix this we use `record.data.option_ids.currentIds` which is basically the live set of Ids.

3. when updating both options and responsible at the same time before validating,
responsible won't update. This happened becase of the return statement when the options change.

To fix this wer remove the return keyword and allow them both to be updated.

Task: 3972994

Forward-Port-Of: odoo/enterprise#64333