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 the `sync_shopee_pickings` cron tries to fetch
shipment labels for multiple batches of shipments. If some shipments do not
contain the required data in the Shopee API response, the error causes the
cron to stop, preventing the remaining batches from being processed.

Error:
`ValueError: KeyError('status') while evaluating 'model._sync_shopee_pickings()'`

This issue was introduced by a recent refactoring commit [1] focused on linting
and formatting the Python file. The commit replaced the generic `Exception`
with `UserError` when handling errors during batch label printing.

As a result, errors other than `UserError` are no longer handled at the batch
level. When such an error occurs, the entire cron process stops instead of
failing only the affected batch and continuing with the remaining batches.

This commit fixes the above issue by handling generic `Exception` during
shipment label generation, ensuring that the error is handled for the
affected batch while the remaining batches continue to be processed.

[1]: https://github.com/odoo/enterprise/commit/cfe5d947579739ad770ac3f1525ce157af530846#diff-e072c3ecf980add685bb4a4f25cf2b0ab5d4625988e4afc2c4d4faeae687ca88R199

sentry-7685943988

Forward-Port-Of: odoo/enterprise#130181

Commit [1] introduced the possibility to select the output device used for all softphone call voices and ringtones.

For the ringtone, it only worked for the outgoing calls though. Indeed, the ringtone object specific to each session* was only known by the AudioManager instance once an incoming call was actually >answered<. While the softphone was ringing, the output device used was left to default browser selection which often means default OS selection.

Steps to reproduce:
- Have a working Odoo voip provider
- Have two audio outputs on your computer and the OS allowing output to both at the same time (if connecting a headset, it often means having to select the computer speaker as the main source os side).
- Call your softphone with your smartphone => The softphone rings, through the main OS selection
- Change output device in the softphone setting => Bug 1: Nothing changes
- Hangup
- Change output device to something other that the default OS output in the softphone setting
- Call your softphone with your smartphone => Bug 2: The softphone rings, still through the main OS selection

*: this bug is another symptom of the fact that we really should have
   only one ringtone service instead of one object per session. This
   will be probably be done in master later, as it requires more checks.

[1]: https://github.com/odoo/enterprise/commit/e964e4b28604f32550566ad1b9f17aed89653597

Related to task-6533808

Forward-Port-Of: odoo/enterprise#130501

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