The issue:
When importing a FEC file, the created COAs lack correct translation for languages other than English. This discrepancy arises because the xml_id generated during COA creation does not match the xml_id produced by the _load_translations function. The new COAs' xml_id is a composite of the module ('l10n_fr_fec_import' in this case), company ID, prefix ('account' in this case), and a key derived from the account number code in the CSV file (not Odoo's default code). Consequently, when calling the _load_translations function, it attempts to update translations using a different xml_id, causing failure in locating records.

The fix:
Include the template_data, if available, during COA translation, as it is more efficient than loading and parsing the entire CSV file. This template data already contains the necessary information, including the correct xml_id. Additionally, introduce a key 'is_xml_generated' in the context to prevent the generation of an incorrect xml_id.

Community PR: https://github.com/odoo/odoo/pull/152090

opw-3646861

Issue:
===============
When a manufacturing order (MO) is created, the default components are 
automatically reserved and are made visible in the barcode module. However, 
even if these components are later unreserved, they will continue to be 
displayed in the barcode module.

Resolution:
================
To address this issue, we've taken the step to avoid forcefully re-reserving 
the components when a component is unreserved. This resolves the persistent 
display of components in the barcode.

Steps to Reproduce:
======================
1. Create a manufacturing order (MO) and confirm it.
2. Navigate to the barcode module within the manufacturing order.
3. By default, the components are reserved, so they are visible in the 
   barcode module.
4. Go to the form view of the MO in MRP and unreserve the components.
5. Check the barcode module again, and notice that the unreserved components 
   are still visible.

Expected Result:
==================
After implementing the solution, When we opens the MO in the barcode module 
only reserved components should be visible. When a component is unreserved, 
it should no longer be visible in the barcode module for manufacturing order.

task-3869731

**Current behavior:**
If you create a SEPA report for an employee that has address
information in their `hr.employee` record but not their
`res.partner` record, the creditor address will not use the
`hr.employee` information- the corresponding XML node will not
be included.

**Expected behavior:**
The employee address should be in the report if they have one
listed in their HR information.

**Steps to reproduce:**
1. Install the `test_l10n_be_hr_payroll` module, switch to
     'My Belgian Company'

2. In the Employee application, go to an employee (e.g., Bernice
     Jensen) and make sure their listed bank account is verified
     to be able to receive payments

3. In the Payroll application, create a new `To Pay` record for
     the employee from step 2, register it, then create the
     payment report

4. In the Exported File notebook tab, you can see that there is
     no Creditor Address listed in the XML Sepa Report

**Cause of the issue:**
The report builder constructs the creditor address only from
the `res.partner` record.

**Fix:**
Extend the postal address construction such that we get an
address from a partner's employee record (when applicable). The
information should not be mix-and-matched; we will use whichever
address has the most complete information.

opw-3716705

Forward-Port-Of: odoo/enterprise#58743

Currently, several l10n_pe_edi tests are failing every night. This is
due to:
- Error 98 meaning that not enough time is given to the remote sever to
process cancellation requests -> wait and check several times before
asserting
- Duplicated name: Sometimes, some invoices have duplicated names. We
make sure it is not possible by 'incrementing' the name for each invoice
we create.

-----

1. `test_send_delivery_guide` was failing because the picking vehicule
was not set up properly in the test. After this was fix, another issue
appeared: the company needed proper credential to connect to the SUNAT.
Since those were not available, the function connecting to SUNAT has
been patched to simulate a basic answer from SUNAT.

2. `test_generate_delivery_guide`'s expected document has been updated
to include the vehicule set up in the previous step.

3. Since there is no more call to an external API. The `external` and
`l10n_external` tags are not necessary anymore. This allows to group
both tests under the same class.

task-3718645

Forward-Port-Of: odoo/enterprise#63266
Forward-Port-Of: odoo/enterprise#62452

Before this commit, there was a race condition in the way kanban
progressbar were handled: when the kanban view was reloaded, two
(sequences of) rpcs were done:
 1) by the model, to load the data (e.g. 1 web_read_group followed
    by n web_search_read)
 2) by the progress bar hook, to load progressbar data.

1 and 2 weren't synchronized, and if 2 returned after 1, the view
wasn't re-rendered to reflect the new progressbar data. This issue
was caused by a misuse of owl reactivity: in the progressbar hook,
in onWillUpdateProps, we didn't call loadProgressBar on the reactive
version of the progressbar state, so changes in that state didn't
trigger a rendering.

Fixing this highlighted a bunch of other issues, all of them kind
of related to the fact that the model and the progressbar don't
synchronize when fetching their data. In particular, scenarios
where the progressbar data was loaded before the kanban data failed,
because the rendering triggered by the progressbar state mutation
(now that it is reactive) altered its caches (see `getGroupInfo`)
or even the groups (see `applyFilter`), with almost outdated
datapoints that were about to be replaced (as soon as the new root
would be loaded).

Properly fixing this isn't possible in stable versions as it might
require an in-depth rework of the way the progressbar interacts
with the model. This will be done in master.

For stable, we found a workaround that seems to be enough: instead
of hooking on `onWillUpdateProps` to reload the progressbar (i.e.
in parallel of the model), we hook on `onWillRender` (i.e. once
the model has loaded the data), and we only load the progressbar
data when the root changed (i.e. as often as before). But by doing
that sequentially, we ensure that the data are always loaded first,
and that the rendering produced by the mutations done on the
progressbar state is done with the correct datapoints.

Master task-3928143

opw-3634027

Forward-Port-Of: odoo/odoo#149626