__

## Short functional explanation of the error
When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48.

## Reproduction Steps
1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang.
2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time.
3. Open Attendances.

### Expected behavior
When we hover the name of our employee, we can see in white on green background 0/40h.

### Unexpected behavior
Instead, we see 0/48h.

## Origin of the issue
This line:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419
is used to retrieve the correct date. We assume that `end_datetime`
will be set at midnight, so subtracting one second gives us the day
before, allowing us to ignore the date of `end_dt`, for which we don't
need to compute the intervals.
However, this doesn't take into account different time zones. Indeed,
we compute `end_datetime_adjusted` from `end_datetime`, which has
the user timezone, and not UTC, as defined here:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402
As a result, if we set the user timezone to Pyongyang, `end_datetime`
will be set at 8am, and `end_datetime_adjusted` will lead to the same
date, instead of a day before. Hence, we would compute an additional
interval for an additional day, which would in the end give us 48
hours expected instead of the 40 hours indicated in the contract.
Therefore, we have to take into account the time zones, hours, minutes
and seconds when checking the start and end dates.

__
opw-5937298

Forward-Port-Of: odoo/enterprise#110011

### Steps to reproduce:
	- Install the l10n_ae_hr_payroll module.
	- Configure at least two employees, who'll use the UAE Monthly pay structure.
	- On at least one of the employees, set the work entry source to attendance.
	- Register a paid leave time off entry, for the employee whose work entry source is set to attendance.
	- Compute a payslip batch using the UAE Monthly pay structure.
	- Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again.
	- The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually.

### Cause:
In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees

### Fix:
We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage.

opw-5979631

Forward-Port-Of: odoo/enterprise#112098
Forward-Port-Of: odoo/enterprise#111280

To reproduce the issue:

- Setup tax periodicity to "trimester"
- Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example)
- Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester
- Open the report for the second month of the trimester => The line has value 42, while it should have 1.

This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong.

Forward-Port-Of: odoo/enterprise#111721
Forward-Port-Of: odoo/enterprise#110504

Steps to reproduce:
--------------------------
1. Install sale_timesheet
2. Create a quotation with a timesheet-based product
   - Set quantity = 3
   - Set UoM to Days (timesheet UoM is Hours)
3. Confirm the quotation and click on the smart button Recorded.
4. Record 16 hours of timesheets.
5. Create an invoice using a timesheet period (starting from SO date)
6. Check the invoice quantity

Issue:
-----------
The invoice quantity is incorrect. It assigns the hour value (e.g., 16) to the invoice line even though the SOL is configured in "Days" (expected 2 days for 16 hours).

Cause:
-----------
After this commit c3b6053, The `_recompute_qty_to_invoice` method sums timesheet `unit_amount` (in hours) and assigns it directly to `qty_to_invoice` without converting it to the sale order line UoM when a timesheet period is applied.

Solution:
---------------
Convert the aggregated timesheet hours into the SOL UoM before assigning it to qty_to_invoice.

opw-6024804





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

Forward-Port-Of: odoo/odoo#255790
Forward-Port-Of: odoo/odoo#254273

**Steps to reproduce:**
* Install *purchase_stock* and *sale_management* module.
* Go to *Inventory > Configuration > Settings*. Enable *Multi-Step Routes*.
* Go to *Inventory > Configuration > Warehouses*.
* Set the warehouse delivery flow to *Pick + Pack + Ship (3 steps)*.
* Create a new product. Under the *Purchase* tab, add a vendor.
* Create a sales order for this product with some quantity.
* Confirm the sales order. Validate all three generated transfers (*Pick*, *Pack*, *Ship*).
* Create a purchase order for the same vendor.
* In the purchase order line, click *Catalog* and search for the product.

**Observed behavior:**
* In the catalog view, the *Monthly Demand* is shown as *3x* 
the original sales order quantity instead of the actual demand.

**Cause:**
* *Monthly Demand* is a computed field using `_compute_monthly_demand`, 
which relies on `_get_monthly_demand_moves_location_domain()`.
* In a 3-step delivery flow, all related moves have a final location with usage set to *customer*.
* The domain condition: `('location_final_id.usage', 'in', ['customer', 'production'])`
counts all intermediate pickings.
* Additionally, the fallback condition: `[('location_final_id.warehouse_id', '!=', warehouse_id)]`
is always true because *customer* locations are not linked to a warehouse.
* As a result, all three pickings are counted, inflating the demand. See: https://github.com/odoo/odoo/blob/6bbaea728dbcba49776e813c70dff649d041bdc9/addons/purchase_stock/models/product.py#L144-L157

**Fix:**
* Prevent counting intermediate pickings in 3-step delivery by 
restricting the domain to moves with `move_dest_ids = False`,
ensuring only the final move is considered for monthly demand computation.

---

opw-5453991

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

Forward-Port-Of: odoo/odoo#244180

__

## Short functional explanation of the error
When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48.

## Reproduction Steps
1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang.
2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time.
3. Open Attendances.

### Expected behavior
When we hover the name of our employee, we can see in white on green background 0/40h.

### Unexpected behavior
Instead, we see 0/48h.

## Origin of the issue
This line:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419
is used to retrieve the correct date. We assume that `end_datetime`
will be set at midnight, so subtracting one second gives us the day
before, allowing us to ignore the date of `end_dt`, for which we don't
need to compute the intervals.
However, this doesn't take into account different time zones. Indeed,
we compute `end_datetime_adjusted` from `end_datetime`, which has
the user timezone, and not UTC, as defined here:
https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402
As a result, if we set the user timezone to Pyongyang, `end_datetime`
will be set at 8am, and `end_datetime_adjusted` will lead to the same
date, instead of a day before. Hence, we would compute an additional
interval for an additional day, which would in the end give us 48
hours expected instead of the 40 hours indicated in the contract.
Therefore, we have to take into account the time zones, hours, minutes
and seconds when checking the start and end dates.
__
opw-5937298

Forward-Port-Of: odoo/odoo#252847

### Issues:

Cancelling the move dest of a manufacturing order does not cancel the MO nor log's an activity warning for the responsible to update the manufacturing demand manually.

Additionally, when selling MTO manufactured products, cancelling the delivery and then changing the sol's demand will update the MO for an incorrect amount.

### Steps to reproduce:

- In the settings: Enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive the MTO route
- Create an MTO product with BOM
- Create and confirm an SO for 3 units of that product
- Cancel the delivery of 3 units
> There is no notification on the unrelevant MO linked to the SO
- Adapt the quantity of the SOL from 3 to 10
#### > A Delivery is created for 8 units and the MO's demand is updated from 3 to 11

### Expected behavior:

Since the the SOL demand is updated to 10 units and none are currently delivered, a delivery for 10 units should be created and the MTO behavior should therefore add 10 units to be manufactured.

### Cause of the issue:

Adapting the quantity on the sale order from 3 to 10 will launch a call of the `_action_launch_stock_rule` with a `previous_product_uom_qty` of 3. The purpose of this call being to create and run a procurement to fulfill the new demand:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L388-L402
The demand of this procurement is therefore matching the new quantity of the sol minus the qty that is already handled by other procurements (determined by the `_get_qty_procurement` method): https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L310-L320
Note that this `_get_qty_procurement` call should determine the qty that is already planned to be delivered to and returned by the customer. In particular, this `_get_qty_procurement` call should return a value of 0.0 because the entire delivery has been cancelled and nothing is expected to be returned from the customer. However, the call will return an unexpected value of `-3.0` units which will in turn provide a procurement to the customer location for `5 - (-3) =  8` units and hence lead to the creation of a delivery for 8 units and adapt the MO by MTO for 8 additional units.

The discrepancy happening in the `_get_qty_procurement` is due to two recent changes. To begin with, since the 19.0 version the `move_finished_ids` of the production is linked to the sol (part of its `move_ids`) because of these lines:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/stock.py#L134-L139 This change ensuring that MO created by MTO is linked to the SO see 2713876dbc70d3984e584a9037a2206dcda4e84a for more details.

As such, the move of the produced product can now be part of the moves initially considered in the `_get_outgoing_incoming_moves` and that should be filtered out to not be accounted in the qty handled by the current sol:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L322-L331

Now, the reason this production move is not excluded from the incoming move pool is because of the change of this other fix: 37f1377344864770cd2a745dd4cb6999af07bbdf https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/sale_stock/models/sale_order_line.py#L353-L358 To be more precise, while the move is not not a refund, it satisfies the second part of the condition that `move.rule_id.id in triggering_rule_ids` for the incorrect reason that the move has no `rule_id` so that and that `move.rule_id.id` is False and the `triggering_rule_ids` contains the False value but this key is irrelevant and should never have been added as the purpose of the `triggering_rule_ids` list is to keep track of rules starting a push chain.

opw-6010109
opw-5885741

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

Forward-Port-Of: odoo/odoo#254636

Since Odoo 18.4, the general logic for the fetchmail Cron Job was
refactored to align it with the new changes to how cron jobs are
handled (i.e. the _commit_progress etc.)
See https://github.com/odoo/odoo/pull/191911

But it certain (legitimate) edge-cases, the current logic might not
handle real-life scenario correctly

Analysis:

When having a high number of legitimate and working fetchmail.server records (>10).
The cron job was repeatably finishing in a "partially done" state,
reporting 0 done progress and retriggering immediately.
Also if there was a notable latency when establishing the IMAP connection,
this had for effect of:

- The cron would process the first few (empty, no new unseen mail) inboxes
 stop break early because of this
 https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/mail/models/fetchmail.py#L329
 , i.e. if no progess is commited, the cron job handler stops the job
 after 10 secs see https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/odoo/addons/base/models/ir_cron.py#L495-L498
- Thus the job would stop early in the partially done state, which would
create a cron trigger and relaunch it at the earliest
(usally 1 min later if no other jobs running)
- In the new run, because _fetch_mails always browses the fetchmail.server
 records in the same order, it will check the same inboxes again, and
 because they are empty and there is a connection lag, it would take
 longer than 10 secs again and stop the cron early
 in partially done → rinse and repeat
- In practice in this edge-case we will never check the remaining
fetchmail servers, so unseen emails on those would never be processed →
customer complains that emails are not coming in
- The repeated triggering of the job and it never officially reporting
progress seems to trigger the automatic deactivation on the odoo.sh
platform, further aggravating the situation

Issues with current business logic of the cron:

1) The `total_remaining` variable (tracking the "units" of work to be done)
 does not distinguish between number of servers to be process and the
 number of unseen emails to be processes on the current fetchmail server.
 At the same time it does not commit an explicit progress when finishing
 an outer loop (at the server level) when the inbox was empty
2) The use of `remaining_time` as a circuit-breakers seems like a good
idea at first, but combined with point 1, will terminate the cron early
if checking empty inboxes takes too long and will break the inner loop
(fetching emails) early on subsequent loops of the cron
3) `_fetch_mails` will always return the model records in the same order,
and everything being equal, will not account for that fact if some
fetchmail.server records have been fetched more recently than others

Proposed changes to logic:

1. We add a time buffer to the 'cron_end_time' context value, initialized at the beginning of a job an usually accounting for 10 secs of wall-time per job. We scale the time buffer as 4 * N secs, N being the number of total fetchmail records that need to be checked. This is to ensure that, assuming that all mail inboxes are empty, we have enough time to loop over all of them even if there is "extreme" latency of 2s to connect and 2s to get a response from the mail server.

2. We make the ordering in _fetch_mails "smarter" by  adding a
    custom order argument for more dynamic queuing:
	A) Records with the lowest priority first
	B) Records having the oldest date first, i.e we dynamically penalize
    records that were fetched recently given the date fields get's
    updated every time it fetched/checked a server successfully

3. If a customer still hits the implicit threshold (i.e. it takes longer than 10 + 4 *N s to loop over all current fetchmail servers), the cron will simply rerun at the next recurrence and the custom order should ensure that the backlog get's resorbed. If the time buffer is still not enough in extreme latency scenarios, then users should either fix the root cause (connection latency between the Odoo DB and the mail servers) or opt for an alternative to route the emails to the DB (setting up an MX record and redirecting mails into a mailgate).

OPW-6054244
OPW-6019730

Forward-Port-Of: odoo/odoo#255110

**Problem:**
cogs don't adapt to partially consigned quantities

**Steps to reproduce:**
- enable 'consignment' setting
- create a tracked product with perpetual category
(bug happens with avco, fifo and standard price category)
- set a cost of 10 
- add a quantity of 1 without owner and a quantity of 
1 with an owner
- create a sale order for a quantity of 2 of your produce
- confirm, validate picking and confirm invoice

**Current behavior:**
the cogs is 20 

**Expected behavior:**
the cogs should be 10 because the consigned 
quantity shouldn't be taken into account in the cogs

**Cause of the issue:**
to compute the cogs line amount, we multiply the quantity 
of the line (2 in our case) by the price unit of the cogs.
To compute the price_unit we call _get_cogs_value()
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/account_move.py#L122-L123 
In our case the price_unit (so the 'price per cogs unit') should 
be 5 because we have 2 units, 1 valued at 10 and 1 valued 
at 0 (the consigned one).
But the value returned by _get_cogs_value() is 10.

The reason for this is that _get_cogs_value uses the return 
value of _get_cogs_price_unit() because the delivery is validated.
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/account_move_line.py#L67-L68

Inside get_cogs_price_unit, we use _get_valued_qty() to 
sum the valued quantity of each move. 
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L251
But inside get_valued_qty() for our second move, when 
calling get_out_move_lines(), no lines will be returned 
because should_exclude_for_valuation() will return True 
as the owner of the line is not the user.
So total qty will be 1.
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L529

If the product is fifo, we return the total value of the moves (10) 
divided by total quantity (1). 
If the product is standard or avco we return the standard price. 
In both cases the return value is 10.
But in both cases it should be 5.
https://github.com/odoo/odoo/blob/0dbc1c01c6b48d0a765391d5b6ab03b555440aef/addons/stock_account/models/stock_move.py#L251-L255

**fix**
The first thing to change is to not use the standard price when 
some quantities are consigned. 
The other thing is to add the quantities that would have been 
used if they weren't consigned because in this case we need them 
in the computation. 
Indeed these quantities are included in the invoice line quantity. 
At the end we are multiplying the unit price by the invoice line quantity
which includes consigned quantity, so we need to take them into 
account also when computing the price per cogs quantity.

opw-6030161

Forward-Port-Of: odoo/odoo#255043

Issue:
------------------------------------------------
When a Manufacturing Order is created via an MTO flow from a Sales Order,
the Forecast Report was displaying the Sales Order in the "Available" section
instead of the Manufacturing Order.

Steps to Reproduce:
------------------------------------------------
1. Install `sale_mrp` and `sale_management`.
2. Create a storable product with BOM and MTO route
3. Confirm a Sales Order for the product
4. Open the Forecast Report
5. Observe incorrect reference in "Available" section

Cause:
------------------------------------------------
Before v19.0, finished moves of an MO created via MTO did not carry a
`sale_line_id`, but now it will propagate to the MO finished moves.
Because `_get_source_document()` is overridden in multiple modules,
the `sale_stock` implementation now matches first and returns the
Sales Order, preventing the MRP logic from returning the Manufacturing Order.

With this commit:
------------------------------------------------
This fix ensures that the Manufacturing Order is shown as the
source document providing correct traceability and aligning the behaviour
with the purchase MTO flows.

task-5941986

Forward-Port-Of: odoo/odoo#250121

When scrapping a kit product, an error would pop if account is installed

Steps to reproduce:
-------------------
* Install stock, mrp, account
* Create a product
* Create a bom of type kit for that product
* Put some quantity of the component in stock
* Mrp>Operantion>Scrap
* Scrap the kit product

Observation:
-------------
When a product is scrapped, the ```do_scrap``` method triggers ```_action_done``` on the new kit ```stock.move```
https://github.com/odoo/odoo/blob/89e5038c224d58a2f6be8f3001fd0a2932733cbc/addons/stock/models/stock_scrap.py#L156-L158

In the ```stock_account``` module, ```_action_done``` is overridden to handle inventory valuation and update the standard price.

For products using the FIFO costing method, the move value (for move out) must be calculated before the move is processed to ensure the correct cost are considered. The sequence in ```stock_account/models/stock_move.py``` is as follows:

The move out value is calculated before processing it, to have the correct value in fifo case:
https://github.com/odoo/odoo/blob/e43f6040a6aa9e8f8c10d720a760f9c92606eab5/addons/stock_account/models/stock_move.py#L165-L166
https://github.com/odoo/odoo/blob/e43f6040a6aa9e8f8c10d720a760f9c92606eab5/addons/stock_account/models/stock_move.py#L307
The move is executed:
https://github.com/odoo/odoo/blob/e43f6040a6aa9e8f8c10d720a760f9c92606eab5/addons/stock_account/models/stock_move.py#L167
The product's standard price is updated for the outgoing move
https://github.com/odoo/odoo/blob/e43f6040a6aa9e8f8c10d720a760f9c92606eab5/addons/stock_account/models/stock_move.py#L172

When scrapping a Kit, this logic breaks due to the move being exploted 
- The value calculation and standard price update are mistakenly applied to the Kit move itself, rather than the individual component moves
- During processing, the Kit move is "exploded" into its components (and [unlinked](https://github.com/odoo/odoo/blob/e4d7b400c556344ca0eaab17956efce3ea0ae04e/addons/mrp/models/stock_move.py#L398), because of this when updating the standard price it will raise and error.)

opw-5970674

Forward-Port-Of: odoo/odoo#252049

Steps to Reproduce

- Create a draft manufacturing order : Desk Combination
- Update bom using ECO
- Add a new Line with Screw with 10 qty
- Apply Changes
- Update BOM in the manufacturing order

-> Record does not exist or has been deleted.

Changing bom_id causes the computes state/move_finished_ids/move_raw_ids & workorder_ids to be triggered.

Since https://github.com/odoo/odoo/pull/195995, raw_material_production_id have ondelete='cascade'
Therefore
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/mrp/models/mrp_production.py#L828 will unlink the raw moves, see
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/odoo/orm/fields_relational.py#L980

Due to
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/mrp/models/mrp_bom.py#L265 unlink cannot be removed, so exists() will do the job.

Also fix unlinking of workorder_ids which causes the same error message in 18.0

issue: 254376

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

Forward-Port-Of: odoo/odoo#255844

### Steps to reproduce
------------------
- Install `l10n_ae` module.
- Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE").
- Upgrade the `l10n_ae` module.

### Issue
-----
The file `l10n_ae/data/res.bank.csv` references the country using its name ("United Arab Emirates"). During the module upgrade, the CSV import tries to resolve the country relation using the country name. If the country name has been modified by the user (for example to "UAE"), the lookup fails and the module upgrade crashes with:

```python3
No matching record found for name 'United Arab Emirates' in field 'Country'
```

### Root Cause
----------
Using translatable/display names in CSV data is unreliable, as these values can be customized or translated by users.

### Fix
---
Replace the country name reference with the stable XMLID `base.ae` in `res.bank.csv`.

Using XMLIDs ensures consistent resolution regardless of name changes or translations.

opw-6015302
upg-3950261
tbg-2492

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#255993

### Steps to reproduce
------------------
- Install `l10n_pe` or `l10n_ec` module.
- Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ",
  "Ecuador" → "ECUADOR").
- Upgrade the module.

### Issue
-----
The files `l10n_pe/data/res.bank.csv` and `l10n_ec/data/res.bank.csv`
reference countries using their names (e.g. "Peru", "Ecuador").

During module upgrade, the CSV import resolves many2one relations using
the country name. If the country name has been modified by the user,
the lookup fails and the module upgrade crashes with:


```python3
2026-03-06 23:48:11,112 27 CRITICAL db_3950261 odoo.service.server: Failed to initialize database `db_3950261`.
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
  File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
    load_modules(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 456, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 216, in load_module_graph
    load_data(env, idref, mode, kind='data', package=package)
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 59, in load_data
    convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 689, in convert_file
    convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 754, in convert_csv_import
    raise Exception(env._(
Exception: Module loading l10n_pe failed: file l10n_pe/data/res.bank.csv could not be processed:
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'

 select id,name,code from res_country where code='PE'
+-----+----------------------------------------------------------------------+------+
| id  | name                                                                 | code |
|-----+----------------------------------------------------------------------+------|
| 173 | {"de_DE": "Peru", "en_US": "PERÚ", "es_ES": "PERÚ", "es_PE": "Perú"} | PE   |
+-----+----------------------------------------------------------------------+------+
```


### Root Cause
----------
Using translatable/display names in CSV data is not reliable, as these
values can be customized or translated.

### Fix
---
Replace country name references with stable XMLIDs:
- `base.pe` for Peru
- `base.ec` for Ecuador

Using XMLIDs ensures consistent resolution regardless of name changes
or translations.

opw-6015302
upg-3950261
tbg-2492

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#256201
Forward-Port-Of: odoo/odoo#254096

When a PDF is received by a journal email alias, a race condition occurs between the notification email process and the OCR (IAP) callback.

The notification email template generates a portal URL. Accessing this URL triggers a lazy-generation of the 'access_token' on the account.move record. If the OCR callback (which is asynchronous) updates the same record while the main thread is busy communicating with the SMTP server, the main thread fails with a SerializationError (Concurrent Update) when it finally tries to commit the new token.

This results in a "bouncing email" error for the user, even though the invoice was created and the OCR worked correctly.

This commit forces the generation and flush of the 'access_token' immediately before the notification process begins. By ensuring the write happens early and is flushed to the DB, we avoid a conflicting lazy-write during the post-SMTP commit phase.

Traceback example (simplified):
```
# Thread A (Alias) starts parsing
INFO: iap jsonrpc .../invoice/2/parse
# Thread B (OCR Callback) finishes and updates the record
 INFO: POST /account_invoice_extract/request_done/... HTTP/1.0" 200 
# Thread A finishes SMTP and tries to flush the lazy-generated access_token 
ERROR: bad query: UPDATE "account_move" SET "access_token" = ... 
ERROR: could not serialize access due to concurrent update psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update
```

OPW-5887922

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

Forward-Port-Of: odoo/odoo#251781