The idea is:

1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable.

2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpDisplay` so it doesn't do a lot of sense to define it in `MrpDisplaySearchModel`. The only exception is in the `_notify` where the cache is invalidated (TODO: to check if it still relevant.) Also, instead of havin an object with one uniq key who refers to an array (`recordCache.ids`), it will now be an array directly.

3. Make `recordCacheIds` part of the `MrpDisplay` `state`. The purpose of this change is to refresh the app everytime the cache is modified.

Also, this commit fix an issue where the record cache wasn't correctly updated when the selected employee requieres a PIN code. The issue was the cache was invalided before the PIN code was validated, a lot of async methods weren't awaited and the dialog itself wasn't bound to a callback in a way to be able to invalidate cache at the right moment.

OPW-4256568

Forward-Port-Of: odoo/enterprise#74421

Steps to reproduce:
1. Install l10n_mx on runbot and go to MX company
2. Set rates for Day 1 (19.839 MXN/USD) and Day 2 (19.9338 MXN/USD)
3. Create an invoice with date Day 1 for 23,664 USD
4. Add a payment for 9 USD on Day 1
5. Create a bank transaction for a large MXN amount (let's say 600,000) on Day 2
6. Click "Match" for this transaction
7. In reconciliation widget, select invoice created before
8. Change amount in currency reconciled from invoice to 6,954.76 USD (amount in MXN should update to 137,975.49)
9. Validate the reconciliation
10. Go to the journal items and show items from journal entry linked to invoice > check partial reconciliation. The reconciled item has a residual of -0.01 and not 0.

Analysis:
During reconciliation, the rate used is always that of the invoice, not the rate of the invoice residuals.

https://github.com/odoo/odoo/blob/4e724323d811dec76c186b5cfff6e4b0135b2128/addons/account/models/account_move_line.py#L1874

However, in the bank reconciliation widget, the residuals' rate was being used to compute the company currency balance of the new AML to create.

This led to a different amount than the amount that can actually be reconciled.

See [this google sheet](https://docs.google.com/spreadsheets/d/1IoKfuOmSeBS9MrU_DkH_73PGtJd7tb73KuAKm5QsrqI/edit?usp=sharing) for analysis

Solution:
Use the invoice rate in the bank reconciliation widget.

opw-4222310

Forward-Port-Of: odoo/enterprise#76935

Before:
The typofix feature treats terms in the old and new values with similar text content as the same term, migrating the translations of the old term to the new term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after `write`, the new term reuses the old translation of 'Draft'. However, the translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the en_US value and is responsible for verifying translations afterward. However, it is problematic during upgrades because users cannot easily identify which records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below Translations can be inherited after `write` from old terms to new terms which share the very close text contents
1. when `write` in production mode, text contents for translation terms are more important than the HTML/XML structures of them, and the old term translations should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the text content
2. when `write` in upgrade time, the HTML/XML structure is more important than the text content, and the new term structure should be remained as much as possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may contain behavior relevant diff (e.g. `invisible`), even if text contents are not changed.
    * users have no idea which records' values are changed during upgrade and are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with the new source term, other attributes will be copied from the source term if available.

Forward-Port-Of: #194181

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Description of the issue/feature this PR addresses:
Task ID: 4342267

Current behavior before PR:
-Error When printing draft invoice due to unset invoice_date.

-Report spacing between header & body in second page overlaps due to paperformat spacing.
Due to the long address format of saudi arabia, the default paperformat header spacing and margin top are not enough to show the full address without overlapping the second and onward pages.

-English labels on the exchange rate table in l10n_sa_edi are translated and not shown together with the arabic labels.

-Remove unnecessary spans in xpaths

Desired behavior after PR is merged:
-Fix printing draft invoice with invoice_date as today's date

-Fix report spacing header by adding a new A4 paperformat for l10n_sa which is set as the saudi arabia companies default paper format.

-Fix exchange rate table to show both arabic and english labels and remove unnecessary translations (no longer used)

-Remove unnecessary spans in xpath.



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

Forward-Port-Of: odoo/odoo#193364
Forward-Port-Of: odoo/odoo#190172

### Issue:

- The negative values in Vendor Bills are not being reflected in the Analytic Account linked to a project.
- the negative value does not reduce the project’s total cost in the Analytic Report cost calculations.

### Steps to reproduce:

1- Create a project and set an analytic account or use the "Renovations" project.
2- Create a vendor bill.
3- On the VB add two lines one with a positive Price and the other with a negative Price.
4- on `Analytic` of each line set the project to `Renovations` or the project you created.
5- Validate the vendor bill.
6- Go to the project app and click on the 3 dots of the project you choose and click on `Project Updates`.
7- Notice the total cost of the project is not reflecting the negative value of the vendor bill.

### Solution:

- The issue is caused by the condition ('price_subtotal', '>', 0) in the query for account.move.line.
- Removing this condition ensures both positive and negative price_subtotal values are included.

opw-[4416931](https://www.odoo.com/web#id=4416931&view_type=form&model=project.task)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#194837
Forward-Port-Of: odoo/odoo#194300

Problem: When printing an invoice with l10n_cl installed, the tax total will display the lavel as 'VAT.' The user expects 'VAT' to be translated to maybe 'IVA.' It is hardcoded into the view, thus the .pot file needs to be updated.

Note: Starting from v17, there are missing translations
for strings "Net Amount", "Total", "Exempt Amount" in the
.pot file for the view l10n_cl.tax_totals_widget. However,
these are present for v16. Will probably need to modify
the fw-ports to include these strings in the file.

Purpose: Updating the .pot file to include the hardcoded VAT string will ensure there are translations for that label.

Steps to Reproduce on Runbot:
1. Install l10n_cl and Accounting
2. Add Spanish as a language
3. Switch to the CL company
4. Create an invoice for a customer whose language is Spanish
5. Print the invoice and notice 'VAT' is not translated

opw-4383092




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

Forward-Port-Of: odoo/odoo#194800
Forward-Port-Of: odoo/odoo#190605