Brings various needed improvements to the module, either in place or
via a new extended module.

- Neutralization resets to pre-production
- Better handling of errors when generating the file by using the commercial partner
as expected.
- Align all the flows which update the invoice status to ensure that the data is
consistent.
- Improve validation for some special cases (lines without products, tax exemption)
- Add a new field for Malaysian TIN, mostly for foreign entities.
Will be used by default in all flows for MyInvois, with fallback on the Tax ID if empty.
- Classification code on invoice line, making the use of products optional.
- Rework the views for all fields related to ID on res.partner to align with other similar
fields. They will be Readonly on res.partner with a parent id, but displays the value of
the commercial partner.
- Industrial classification on the partner.
- "Full" support of self billing.
- Reworked flow to send to MyInvois BEFORE send & print. Which adds support for the
QR code generation, and new field to store the QR code long ID.
- Send & Print can no longer be used to send invoices to MyInvois after the new
module is installed

Task-4363294

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

Forward-Port-Of: odoo/odoo#195174
Forward-Port-Of: odoo/odoo#193497

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

Forward-Port-Of: odoo/odoo#194816

## Issue:
Commission RFQ is not auto-generated for journals(payment method lines) without outstanding accounts when an SO invoice is created, a payment is created for it, and it gets reconciled with a bank statement.

## steps to reproduce:
1. go to bank journal and remove the outstanding account from the manual payment method line
2. on the CRM app create a partner commission program with a percentage and attach it to a partner
3. create a sale order with the partner as a referrer and confirm it
4. create an invoice from the sale order and validate it
5. register a payment for the invoice using the manual payment method
6. create a bank statement line and reconcile the invoice with it in the bank reconciliation widget
7. check the purchase app and see that no RFQ was created

## Solution:
- Before version 18.0 (see [this PR](https://github.com/odoo/odoo/pull/180813)), automatically assigning a default outstanding account ensured that every payment created a journal entry. This journal entry was reconciled with the invoice, triggering `invoice_paid_hook` as the invoice transitioned from `not_paid` to `in_payment`. `_reconcile_pre_hook` filtered out payments already marked as `in_payment` to avoid double-triggering `invoice_paid_hook`. However, since the default outstanding account is no longer assigned automatically, `invoice_paid_hook` is not triggered when an invoice transitions from `not_paid` to `in_payment` and then to `paid` by reconciling it with a bank statement line.
- to address this issue we edited `_reconcile_pre_hook` and `_reconcile_post_hook` to handle in payment invoices in these cases.


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

Forward-Port-Of: odoo/odoo#194298