Currently, the Luxembourg Balance Sheet incorrectly maps accounts
`502000` and `503000` under the `III. Investments` section.

**Steps to reproduce:**
- Install the `l10n_lu_reports` module and switch to the `LU Company`.
- Navigate to Accounting > Accounting > Journal Entries and create and
  post two journal entries:
  - One with account `502000 Own shares or own corporate units`.
  - Another with account `503000 Shares in undertakings with which...`.
- Navigate to Reporting > Balance Sheet and check the `III. Investments` section.

**Observation:**
- `502000 (Own shares...)` is wrongly added under `3. Other investments`.
- `503000 (Shares in undertakings...)` is wrongly added under `2. Own shares`.

In the generated XML report:
- `502000 (Own shares...)` balance is added inside `<NumericField id="195">`.
- `503000 (Shares in undertakings...)` balance is added inside 
   `<NumericField id="209">`.

**Expected behavior:**
According to the Luxembourg documentation mapping tables [1],
- Account `502000 (Own shares...)` should be mapped to `<NumericField id="209">`.
- Account `503000 (Shares in undertakings...)` should be mapped 
  to `<NumericField id="195">`.

**Root Cause:**
At [2], the `account_codes_formula` values are incorrectly assigned:
account code `503` is mapped under `2. Own shares`, while account code
`502` is mapped under `3. Other investments`. This reverses the expected
mapping of the two accounts in the Balance Sheet report.

[1]:
https://ecdf.b2g.etat.lu/ecdf/pcnMappingTables

[2]:
https://github.com/odoo/enterprise/blob/29c186827f0171292f1243e0deb8fe040c027a89/l10n_lu_reports/data/account_financial_html_report_bs.xml#L335-L348

opw-6275340

Forward-Port-Of: odoo/enterprise#130603
Forward-Port-Of: odoo/enterprise#128386

Currently, an error occurs when generating the SAF-T report for a
journal entries with the `asset_current` account type.

**Steps to reproduce:**
- Install `l10n_no_saft` and `accountant` modules and switch to a NO Company.
- Go to Contacts and set the ZIP code and state, then add a contact for
  the NO Company record.
- Create a new Journal Entry, click `Add a line`, and set an account of
  type `Current Assets` (e.g., `1000 Development, acquired`) with the
  partner set to the NO Company.
- Navigate to Reporting > General Ledger.
- Click the gear icon and select `SAF-T`.

**Error:**
`KeyError: 'accounts'`

**Root Cause:**
At [1], from `19.0`, `asset_current` was mistakenly included in the 
second-to-last account type condition of the domain. As a result, 
partners linked to `asset_current` accounts are included in the
`customer_vals_list` at [2].

However, `_l10n_no_saft_get_partners_accounts()` at [3] does 
not retrieve accounts of type `asset_current`. Therefore, when 
the `if` condition is not satisfied, the `accounts` key is not added 
to `partner_vals`.

Since the partner has already been added to `customer_vals_list` at [2],
the SAF-T template at [4] later tries to access `partner_vals['accounts']` 
when generating the `BalanceAccount` nodes, resulting in the error.

**Fix:**
This commit prevents the error by removing `asset_current` from 
the domain, similar to previous versions.

[1]:
https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L307-L313

[2]:
https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L356-L362

[3]:
https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/models/account_general_ledger.py#L37-L42

[4]:
https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/data/saft_report.xml#L27-L37

opw-6441743

Forward-Port-Of: odoo/enterprise#127744

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR.

But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint.

Fix:
`is_created_by_ocr` should have `copy=False` and should not be transferred when merging. Make the merge skip fields that are not copyable.

This prevents the True value from being transferred to the destination, avoiding the unique constraint error.

A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed.

Steps to Reproduce on Runbot:
1. Create 2 contacts with the same exact name and have one created by OCR.
I used a server action to manually set the value of
'is_created_by_ocr' to simplify this process.
2. Select the contacts and merge. In the merge window,
set the non-ORC contact to be the destination contact.
3. Upon confirming merge contacts, the validation error will appear.

Related ticket:
opw-6513607

Forward-Port-Of: odoo/odoo#285150

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR.

But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint.

Fix:
is_created_by_ocr should have copy=False and should not be transferred when merging. Make the merge skip fields that are not copyable.

This prevents the True value from being transferred to the destination, avoiding the unique constraint error.

A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed.

Steps to Reproduce on Runbot:
1. Create 2 contacts with the same exact name and have one created by OCR.
I used a server action to manually set the value of
'is_created_by_ocr' to simplify this process.
2. Select the contacts and merge. In the merge window,
set the non-ORC contact to be the destination contact.
3. Upon confirming merge contacts, the validation error will appear.

Related ticket:
opw-6513607

Forward-Port-Of: odoo/enterprise#129623

Issue:
When creating an asset using an "154.01.01 Vehicles", the depreciation values of the journal entries created are zero

Steps to reproduce:
1. Install l10n_mx and enter a Mexican company
2. Create an asset and setting the fixed asset account as 154.01.01 Vehicles
3. Click on "Compute Depreciation" and in the "Depreciation Board" page, all the journal entries created will not have any depreciation values

Cause:
In the l10n_mx chart of accounts, all accumulated depreciation accounts are set as "expense_depreciation" whereas they should be asset accounts because accumulated depreciation accounts are used to credit asset accounts to decrease asset values. If an account of type "expense_depreciation" is used, then when the depreciation account is credited and the expense account is debited, all financial events will occur within expense accounts, which is why no depreciation values were recorded as the asset balances stay the same. Additionally, the "asset_depreciation_account_id" field on "account.account" has a domain restricting selection to "account_type" of "asset_fixed" or "asset_non_current"

Solution:
Change the "account_type" of l10n_mx accumulated depreciation accounts from "expense_depreciation" to "asset_fixed" and l10n_mx accumulated amortization accounts from "expense_depreciation" to "asset_non_current"

Updrade PR: [odoo/upgrade/pull#10936](https://github.com/odoo/upgrade/pull/10936)

opw-6359618

Forward-Port-Of: odoo/odoo#284309
Forward-Port-Of: odoo/odoo#278185