**Steps to reproduce:**

1. Install the modules: `accounting`, `l10n_ar`, and `l10n_latam_check`.
2. Create a third-party check journal:
   * Add payment methods: *New Third Party Checks* (inbound) and *Existing Third Party Checks* (outbound).
   * Configure outstanding accounts for both methods.
3. Create a vendor payment:
   * Use the third-party check journal.
   * Select the *Existing Third Party Checks* method.
   * Leave the check list empty.
   * Keep the payment in *Draft*.
4. Create a customer payment:
   * Use the same journal and select the *New Third Party Checks* method.
   * Add a new check under the *Checks* tab.
   * Post the payment.
5. Return to the draft vendor payment created in step 3:
   * Add the newly created check to it (via *Add a line*).
   * Post the payment.
6. Go to **Customers → Third Party Checks**.

**Observed behavior:**
- The check still shows a `current_journal_id` even though it has both inbound and outbound operations.
- As a result, the check incorrectly appears in the 'On Hand' filter.

**Root cause:**
- `_get_last_operation` was sorting operations by `date`.          
- In some scenarios or flows where multiple operations share the same `date`, the wrong operation could be selected as the "last one", leading `_compute_current_journal` to assign a journal incorrectly.

**Solution:**
- Sort operations by `write_date` to always pick the true last operation.
- This ensures `_compute_current_journal` correctly clears `current_journal_id` whenever both inbound and outbound operations exist.


opw-5012903

Forward-Port-Of: odoo/odoo#225556

The TableSizeComputer.compute() method can return cells with incorrect cell indexes. This can result in the _addColumn function only adding a column to some rows in the report editor.

TableSizeComputer.compute() does not handle cases where a conditional is used inside of a th element but the corresponding td element does not have a conditional.

Steps to reproduce
-----
1. Open the Delivery Slip in the report editor.
2. Click the header to show the dropdown and select elif: o.move_line_ids and o.state=='done'.
3. Hover over the last th element to select the column button.
4. Click Insert right and see that only the header row has an additional column.

Cause
-----
TableSizeComputer.compute() calculates how many possible cells can be in a row which can be more than the total number of columns you have if you have th or td elements with a conditional inside of them.

In the Delivery Slip report, a th element is present when using serial numbers and a different th element is present when not using serial numbers. The corresponding t-body has two different tr elements for these conditions. The compute method will have one less cell in these rows because the corresponding conditional is handled outside of the row.

Solution
-----
Only count mutually exclusive th or td elements once. This prevents the cellIndex from being larger than the total possible columns.

opw-ticket 5173345

Forward-Port-Of: odoo/enterprise#98207

Steps to reproduce:
===================
1- Add a Contact Us form.
2- Change the "Phone" field type to "Attachment" and save. → Traceback occurs.

Cause:
======
After changing the field type, the field still keeps its `fillWith` value. When saving or refreshing, the system tries to prefill it with a phone number. Since the type is now "file", it cannot be prefilled, causing a traceback.

Why it didn't happen before:
============================
In older versions, fields were fetched using `serializeArray()`:
https://github.com/odoo/odoo/blob/ad03751ef0a9e617c2b24a30b1c06aa4e25d48a1/addons/website/static/src/snippets/s_website_form/000.js#L167
That method automatically filtered out unsupported input types: 
https://github.com/odoo/odoo/blob/ad03751ef0a9e617c2b24a30b1c06aa4e25d48a1/addons/web/static/lib/jquery/jquery.js#L9001

Fix:
====
Exclude fields of file-like types from the prefill logic, similar to the behavior of `serializeArray()`.

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

Forward-Port-Of: odoo/odoo#231185

## Issue:
On Safari, the Apply and Dismiss buttons of the LinkPopover did not trigger their actions In some cases, it seemed to work only because a temporary link was not properly cleared
The Link Type Selection was also broken by the same bug

## Cause:
Safari triggers a `pointerdown` event through the `LinkPopover`, which changes the `selection` and calls the `handleSelectionChange()` method https://github.com/odoo/odoo/blob/e43135e94bf22bc2f7a115c37e8a082f96871ed0/addons/html_editor/static/src/main/link/link_plugin.js#L672-L678
At that point, `documentSelection` is `null`, causing the overlay to close before the `onClickApply()` on the Apply button
It's the same issue with the Dismiss button and the Link Type Selection

## Steps to reproduce:
- Install mail to get access to an html_editor
- Enable debug mode
- Go in Email Templates and open one of them
- Select a text and open link tools
- Add Odoo.com and click on Apply
- The link may seems to be created (if it's the case, there is no preview)
- You can confirm that with the link type selector that closed the popover before the fix

opw-5115887

Forward-Port-Of: odoo/odoo#233401
Forward-Port-Of: odoo/odoo#233241

Description of the issue/feature this PR addresses:

This pull request addresses a bug in Odoo's analytic accounting module. Specifically, when updating analytic lines that have empty distributions, the vals_list[0] ends up being empty. This situation causes an error in the write method, which prevents the system from properly updating analytic lines without distributions.

Current behavior before PR:

Before this fix, attempting to update analytic lines with empty distributions triggers an error in the write method. As a result, operations that involve updating such lines fail, potentially interrupting normal accounting workflows.

Desired behavior after PR is merged:

After merging this PR, the system will first check whether an analytic line has a valid distribution before attempting to update it. Lines with empty distributions will be safely skipped, preventing errors and allowing the rest of the analytic updates to proceed smoothly. This ensures more robust handling of analytic lines and avoids runtime exceptions during updates.


Video: https://app.screencastify.com/watch/03zuCLh984kWun2Q71tK
Odoo Task: https://www.odoo.com/es_ES/my/tasks/5181171

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

Forward-Port-Of: odoo/odoo#232176

## Short functional explanation of the error
When setting the 'DHLxw Package Type' of a DHL delivery method to 'DHL pallets' without changing default values, trying to validate an order delivery causes an error.

## Reproduction Steps
1. Type 'Delivery method' in the dashboard. Select DHL BE, set the region to Europe and the 'DHLxw Package Type' to 'DHL pallets'. Click on the arrow at the right of 'DHL pallets'. You should see the default values set to 1200, 1600 and 1200. These correspond to millimeters, while DHL expects centimeters.
2. Make sure you're using a company located in Belgium.
3. In the inventory settings, make sure that either 'multi-step route' is unchecked or that for your warehouse, the outgoing shipments are set to '1 step'.
3. Create a new quotation. Select a Customer with a Belgian address. Add a product for which there's at least 1 copy in stock.
4. Click on add shipping and select DHL BE. Then click add and ok.
5. Click on confirm. A smart button at the top of the page called "delivery" should appear. Click on it and set the scheduled date to a future day. Finally, click validate.

### Expected behavior
New labels should generate without issue.

### Unexpected behavior
An error occurs:
```Bad request Multiple problems found, see Additional Details
1001: The requested product(s) (N) not available based on your
search criteria.(687662d08999745d3df3783068fcca24)
410107: The piece height exceeds max, N/-
410304: No products available
```

## Origin of the issue
The default values for DHL are set to 1200, 1600 and 1200, which correspond to millimeters. However, DHL expects centimeters, for which the default value is thus too high.
Note: because the issue stems from default values, after implementing the fix, the module should be reinstalled.

__
opw-4804639

Forward-Port-Of: odoo/enterprise#90272

Issue
-----
After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity.

Steps to reproduce
-----
- Unarchive MTO route
- Create a stored product
	- Routes MTO & Manufacturing
	- Empty BoM
- Create a Sale Order for 3 units of the product & confirm it
- Go to the linked MO and split it in 2 (quants of 1 and 2)
- Confirm both MOs (and produce)
- Go to the sale's delivery
> The delivery's move only shows 1 unit of the product

Why the move quantity is only 1
-----
After confirming the first of the 2 backorder productions, when we manufacture the product, we go through

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/mrp/models/mrp_production.py#L2054

Since the first backorder kept the existing move, it has the delivery move in `move_dest_ids` so we do

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091

Which creates a SML for the delivery move when reserving it

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1853-L1858

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1950-L1971

This in turn triggers the computation of the move's quantity since it depends on the move's lines

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L382-L383

Our move ends up with a quantity of 1.

When we proceed with the second MO, things are a little different since there is nothing in `moves_todo.move_dest_ids` when we do

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091

This means we don't create a new SML for the delivery move, so the quantity stays at 1.

Why there is no move_dest_id
-----
When splitting the production, we go through

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1815-L1829

We create new a MO and SM for the backorder. The SM is created here

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1894-L1915

When preparing the values, we correctly copy the `move_dest_ids` of the original MO's SM, see

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/stock_move.py#L646-L656

So when the backorder is created, its' SM has a correct `move_dest_ids`. The problem actually comes from what happens after `_split_productions` in `action_split` when we set the `date_start`

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/wizard/mrp_production_split.py#L68-L78

In the write, we get to a line where we access the production's state

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L931

This triggers a recompute of the field.

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L539-L552

In the compute, we access `move_finished_ids`, which again triggers a recompute. In this compute, we call `_create_update_move_finished`

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L800

The problem is that the move we create gets its' `move_dest_ids` from the MO instead of using the one populated using `group_orders` (098af2f).

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1142-L1167

-----
Ticket:
opw-4865082

Forward-Port-Of: odoo/odoo#232712
Forward-Port-Of: odoo/odoo#223792

Currently POS crashes with the Italian localization if they delete a product line.

Steps to reproduce:
-------------------
* Install l10n_it_pos and switch to the IT company
* Create a pos and configure Italian printer
* Open shop
* Add a product to cart
* On the numpad try deleting the line
> Observation, pos crashes

Traceback: TypeError: Cannot read properties of undefined (reading 'tax_details')

Why the fix:
------------
When first hitting the delete button we will put the price unit to 0. With that we have
```
const reduced_base_lines = Object.values(base_line_map).filter( (base_line) => !floatIsZero(base_line.price_unit, base_line.currency_id.decimal_places));
```
returning an empty list. Utlimately making `reduce_base_lines_to_target_amount` return an empty list. `[][0]` returns `undefined` and we were passing `[undefined]` in parameters of `fix_base_lines_tax_details_on_manual_tax_amounts`, we enter the loop with undefined and try to access some variables.

We also set `l10n_it_epson = False` in order to avoid recursively looping.

opw-5184113

### Issue:

The test `test_mrp_backorder_operations` behaves non-deterministically. It may fail at this assertion:
https://github.com/odoo/odoo/blob/6e37542b53f9c9ec1baf8d58b1eeca376252186f/addons/mrp/tests/test_backorder.py#L986-L989

Because the `duration` of done workorder can vary.

### Cause:

The delta time between `button_start()` and `button_finish()` https://github.com/odoo/odoo/blob/6e37542b53f9c9ec1baf8d58b1eeca376252186f/addons/mrp/tests/test_backorder.py#L983-L985
`button_finish()` triggers `Productivity._close()`
https://github.com/odoo/odoo/blob/6e37542b53f9c9ec1baf8d58b1eeca376252186f/addons/mrp/models/mrp_workcenter.py#L572-L576
Which sets `Productivity.duration` to 0 if delta time is zero. Consequently, `workorder.duration` also becomes zero.
When `bo_2.button_mark_done()` is called, the duration is set to `duration_expected` (240 in this test), which the assertion only can pass in that case.

If delta time isn't zero, then duration will also be non-zero. So it will not set to `duration_expected`. As a result the assertion will fail.

runbot-233247

Forward-Port-Of: odoo/odoo#231650

## Description of the issue/feature this PR addresses:

When obtaining the previous order for pos.order records, all orders with l10n_fr_secure_sequence_number == NULL will be recognised as the previous order for those where l10n_fr_secure_sequence_number == 1, as if their sequence value was zero.

## Current behavior before PR:

Since there can be more than one orders without sequence number, this behaviour will trigger an UserError exception, as the ORM will mistakenly deduce that there are multiple previous orders for a single one, which is not necessarily correct.

### Examples:

upg-3170341

```sql
lare_3170341=> SELECT count(id) FROM pos_order WHERE l10n_fr_secure_sequence_number IS NULL;
 count
-------
 67281
(1 row)
```

```python
# Debugging standard codebase with a Python debugger
...
match = prev_map.get(order.l10n_fr_secure_sequence_number - 1, [])    # len(match) == 67281
if len(match) > 1:
    raise UserError(_('An error occurred when computing the inalterability...'))
...
```

upg-3170341

```sql
lare_3167621=> SELECT count(id) FROM pos_order WHERE l10n_fr_secure_sequence_number IS NULL;
 count
-------
   294
(1 row)
```

```python
# Debugging standard codebase with a Python debugger
...
match = prev_map.get(order.l10n_fr_secure_sequence_number - 1, [])    # len(match) == 294
if len(match) > 1:
    raise UserError(_('An error occurred when computing the inalterability...'))
...
```

---

Traceback group: https://upgrade.odoo.com/odoo/tbg/1869

```
2025-09-30 07:48:30,945 329 INFO db_3167621 odoo.modules.loading: Loading module l10n_fr_pos_cert (110/131) 
2025-09-30 07:48:31,375 329 INFO db_3167621 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables 
2025-09-30 07:48:31,432 329 INFO db_3167621 odoo.models: Prepare computation of pos.order.previous_order_id 
2025-09-30 07:48:31,597 329 WARNING db_3167621 odoo.modules.loading: Transient module states were reset 
2025-09-30 07:48:31,597 329 ERROR db_3167621 odoo.modules.registry: Failed to load registry 
2025-09-30 07:48:31,597 329 CRITICAL db_3167621 odoo.service.server: Failed to initialize database `db_3167621`. 
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-13>", line 2, in new
  File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 485, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 206, in load_module_graph
    registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 618, in init_models
    func()
  File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_model.py", line 2007, in _reflect_relation
    self.env.invalidate_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 839, in invalidate_all
    self.flush_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 857, in flush_all
    self._recompute_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 850, in _recompute_all
    self[field.model_name]._recompute_field(field)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7359, in _recompute_field
    field.recompute(records)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1463, in recompute
    apply_except_missing(self.compute_value, recs)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1436, in apply_except_missing
    func(records)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 427, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5296, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
  File "/home/odoo/src/odoo/18.0/addons/l10n_fr_pos_cert/models/pos.py", line 79, in _compute_previous_order
    raise UserError(_('An error occurred when computing the inalterability. Impossible to get the unique previous posted point of sale order.'))
odoo.exceptions.UserError: Une erreur s'est produite lors de la vérification de l'inaltérabilité. Impossible de récupérer la dernière commande de caisse unique et comptabilisée.
```

## Desired behavior after PR is merged:

The method `pos.order._compute_previous_order` already only checks orders with a sequence number != NULL, so to address this issue, we will use the same condition to retrieve only orders with a valid sequence. This will result in no more exceptions created by incorrect data.

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

Forward-Port-Of: odoo/odoo#229585