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

### Steps to reproduce the issue:

1. Activate Italian Localization
2. Create a contact in any country but Italy
3. Assign VAT number starting with 'IT' (Tax ID or Identification Number)
4. Save and receive error:

>     Invalid Codice Fiscale '[VAT number]': should be like 'MRTMTT91D08F205J' for physical person and '12345670546' for businesses.

### Explanation:

When `country_id` or `vat` is changing, `_l10n_it_onchange_vat` will try to create a `l10n_it_codice_fiscale` if `res.partner` respects some conditions. Those conditions are flawed because if `country_id` is not Italy but `vat` starts with "IT", it will enter the condition.

(Kind of a hack: if `country_id` is set after a `l10n_it_codice_fiscale` has been added to `res.partner`, the first condition will not be met but the second will, and `l10n_codice_fiscale` will turn back to False.)

### Fix reasoning:

We will only check conditions related to `vat` and `country_id` and always perform changes to avoid inconsistencies where `vat` is no longer correct but `l10n_it_codice_fiscale` did not change and is still valid.

opw-4261959

Forward-Port-Of: odoo/odoo#184406

This completes https://github.com/odoo/odoo/pull/171784 by adding support for the same kind of rrule string, but without the `RRULE;` prefix.

Based on Real World™️ evidence.


Description of the issue/feature this PR addresses:

<details>

```
odoo-1  | 2024-10-24 11:20:18,785 42 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : unsupported property:  !
odoo-1  | Traceback (most recent call last):
odoo-1  |   File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 100, in _sync_all_google_calendar
odoo-1  |     user.with_user(user).sudo()._sync_google_calendar(google)
odoo-1  |   File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 78, in _sync_google_calendar
odoo-1  |     synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
odoo-1  |   File "/opt/odoo/auto/addons/google_calendar/models/[google_sync.py](https://google_sync.py/)", line 202, in _sync_google2odoo
odoo-1  |     odoo_record.with_context(dont_notify=True)._write_from_google(gevent, vals)
odoo-1  |   File "/opt/odoo/auto/addons/google_calendar/models/[calendar_recurrence_rule.py](https://calendar_recurrence_rule.py/)", line 86, in _write_from_google
odoo-1  |     current_parsed_rrule = self._rrule_parse(current_rrule, self.dtstart)
odoo-1  |   File "/opt/odoo/auto/addons/calendar/models/[calendar_recurrence.py](https://calendar_recurrence.py/)", line 375, in _rrule_parse
odoo-1  |     rule = rrule.rrulestr(rule_str, dtstart=date_start)
odoo-1  |   File "/usr/local/lib/python3.10/site-packages/dateutil/[rrule.py](https://rrule.py/)", line 1730, in __call__
odoo-1  |     return self._parse_rfc(s, **kwargs)
odoo-1  |   File "/usr/local/lib/python3.10/site-packages/dateutil/[rrule.py](https://rrule.py/)", line 1698, in _parse_rfc
odoo-1  |     raise ValueError("unsupported property: "+name)
odoo-1  | ValueError: unsupported property:
```

</details>

Current behavior before PR: Odoo stops sync of users calendars as long as they have one event with an RRULE like this.

Desired behavior after PR is merged: Odoo keeps working.




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

Forward-Port-Of: odoo/odoo#185089

Currently it can happen that slightly changing the amount in (document)
currency (field `amount_currency`) i.e. on a tax line can lead to an
unbalanced move. (See example and "Reproduce" below.)

The issue is the syncing (function `_sync_invoice`) between
- amount in currency (document currency; field `amount_currency`) and
- balance (company currency; field `balance`).

There we update the amount in currency in case the balance is changed
and the amount in currency is not changed.
But this is problematic in case we want (in the same write) set
a different amount in currency but explicitly set the same balance
(and not just not write anything to the `balance` field).
Since we write the same balance it is not detected as a
change and we update the balance based on the amount in currency.
But this should not happen; the balance should be "protected"
from being updated (since it is the value we explicitly want).

This can i.e. cause the balance of the receivable line to receive the wrong value
I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -30.00 €, balance =  -15.00
- Receivable: amount in currency = -1410.03 €, balance =  705.02

And we modify tax line 2: amount in currency = -29.99 €.
Then first we set the correct values because we basically compute the
receivable line by summing the other lines:

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.02

So we have set the balance to the same as before but changed the
amount in currency. So then we recompute the balance on the receivable
line from the amount in currency due to the syncing (`_sync_invoice`)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.01

But now the move is not balanced (the sum of the balances should be 0)
  -500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01)

After this commit we "protect" the balance and amount in currency from
being updated by `_sync_invoice` in case the surrounding `write`
sets the balance (`balance`) or amount in currency (`amount_currency`)
respectively.

Reproduce: (c.f. example above)
  1. Select company "My Company (San Francisco)"
  2. Ensure EUR currency is activated and has value 2 unit per USD
     (at the time of the invoice that will be created further below)
  3. Copy the 15% tax
  4. Create a new invoice in EUR with 2 lines
     (1) qty = 1, unit price = 1000, taxes = 15%
     (2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy)
  5. There should be 2 tax lines in the "Journal Items" tab
     (1) amount in currency = -180.00 €, credit = 90.00 USD
     (2) amount in currency = -30.00 €, credit = 90.00 USD
  6. Modify tax line (1); set amount in currency to -180.03 €
     and save.
     The credit will be updated to 90.02 USD.
  7. Modify tax line (2); set amount in currency to -29.99 €
     and try to save
  8. An "Invalid Operation" error is raised:
     The move (Draft Invoice ) is not balanced.
     The total of debits equals $ 705.01 and the total of credits equals $ 705.02.

Forward-Port-Of: odoo/odoo#171705