## How to reproduce:
- Enable Wave transfert in setting
- Go to the Receipt Operation type:
    - Create Backorder: always
    - Automatic Batches: Enabled
    - Wave Grouping: Products
- Create and confirm (don't validate) 2 Receipts for 10 units of a storable product P
- The 2 receipt should have been added to a new wave transfer with 2 lines for P
- On the first line, set the quantity to 0
- On the second line, set the quantity to 1
- Try to validate the wave transfer ==>> UserError "The following transfers cannot be added to batch transfer WAVE/XXXX. Please check their states and operation types."

## Issue:
Backorders are generated before the current batch is marked 'done' (it waits for empty pickings to be detached). The auto-batch logic incorrectly identifies the current 'in_progress' batch as a candidate for the new backorders, attempting a merge that violates validation constraints.

## Solution:
Exclude the current batch from the auto-batch search domain using a context variable passed during validation.

OPW-5413921

---

Test result before fix:
```
2026-01-13 10:37:26,541 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: Starting TestAutoWaving.test_auto_wave_skip_current_batch ... 
2026-01-13 10:37:26,820 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ====================================================================== 
2026-01-13 10:37:26,820 27952 ERROR oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ERROR: TestAutoWaving.test_auto_wave_skip_current_batch
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/tests/test_auto_waving.py", line 440, in test_auto_wave_skip_current_batch
    wave.action_done()
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 264, in action_done
    return pickings.with_context(**context).button_validate()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 145, in button_validate
    res = super().button_validate()
          ^^^^^^^^^^^^^^^^^^^^^^^^^
...
  File "/home/odoo/Odoo/src/18.0/odoo/odoo/fields.py", line 1418, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 112, in write
    self.batch_id._sanity_check()
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 323, in _sanity_check
    raise UserError(_(
odoo.exceptions.UserError: The following transfers cannot be added to batch transfer WAVE/00012. Please check their states and operation types.
```

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

This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323

When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled afterwards For example, if a rule pre-filters on field B (which depends on A), computing A should not clear the compute flag of B

### Issue:
In some automation rules, computed fields must be processed in a specific order (e.g., `effective_hours` -> `remaining_hours`)
However, if `remaining_hours` is referenced in the automation `Before Update Domain`, its compute flag may be incorrectly cleared, preventing the proper recomputation chain

This results in inconsistent behavior, such as delays in activities being created when timesheets exceed allocated time

### Cause:
The automation engine flushes fields referenced in the `Before Update Domain`, but does not restore their compute flags afterward Thus dependent fields are not recomputed as expected

### Steps to reproduce:
1. Enable Debug Mode
2. Create an Automation Rule
-- Name: Time Exceeded
-- Model: Task
-- Trigger: On Save
-- Before Update Domain: [("remaining_hours", ">=", 0)]
-- Apply on: [("remaining_hours", "<", 0)]
4. Create a Project with Timesheets
5. Create a Task inside the Project
6. Set Allocated Time to 10h
7. Use the Start button to record 11h (No activity appears in chatter)
8. Do the same again (Activity appears only after the second exceed) Before the fix, there is always a delay because the recomputation chain is broken

### Tickets:
18.0: opw-4409744
17.0: opw-5237430

Forward-Port-Of: odoo/odoo#239667

**Steps to produce:**
- Install the `Accounting` module.
- Enable analytic accounting in settings.
- Create an analytic account (e.g., "test").
- Create a journal entry and assign the analytic account in the analytic
  distribution.
- Post the entry and export it(Make sure `journal items/account` and
  `journal items/analytic distribution` are also included).
- `Archive` the analytic account.
- Import the exported entry `OR` Duplicate the previous created entry.
- Try to post the imported entry.

**Issue:**
- The entry is posted even if the analytic account used in the analytic distribution is inactive.

**Root cause:**
- The `analytic_distribution` field is stored as JSON.
- At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error.

**Solution:**
- Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active.

[1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202

opw-5350980

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

Forward-Port-Of: odoo/odoo#239988

**Steps to reproduce:**
- enable automatic accounting
- set dollars as the main currency
- activate euro and set a rate of 10 euro -> 1$
- create a storable product with category fifo/ automated
- create and confirm a PO for 1 unit for 10 euros (no tax)
- validate the receipt
- return the product and validate return
- return the return and validate
- open journal items and search your product

**Current behavior:**
- there is 6 correct lines (those with credit or debit of
1$)
- there is two incorrect extra lines one with credit 9$ and
one with debit 9$

**Expected behavior:**
those two extra lines should not be there

**Cause of the issue:**
those lines are compensation account move lines
for the case where the price of the product returned
is different than the price of the product initially received,
in the cases of:
- a return: compensate the difference.
- the return of a return (our case): de-compensate the difference.

(see PR https://github.com/odoo/odoo/pull/162697 and more specifically
test test_fifo_return_twice_and_bill).
But in this case, the compensation is wrongly triggered because
the difference comes from the fact that the currency is not
taken into account.
https://github.com/odoo/odoo/blob/c89d109c460d51fc90b6b13d5f6bc114c7316e42/addons/purchase_stock/models/stock_move.py#L208

**Fix:**
we use the original svl instead of the PO
because it avoids currency problem.
If we wanted to convert the currency of the PO,
we would need to find the date that was used to convert
the value at the creation of the first svl.
And that date came from _get_currency_convert-date()
https://github.com/odoo/odoo/blob/d3599e70973e27ed17e403cf498f76bd31e9c236/addons/purchase_stock/models/stock_move.py#L97
which can take the date of the last invoice
(if product was invoiced before the move was validated).
https://github.com/odoo/odoo/blob/57c1c510425dcd491c794a0262063db398348640/addons/purchase_stock/models/stock_move.py#L123-L125
We can not use this method because we're doing the
return of a return and if the first return
also has an invoice, the return value
of the method could be the date of this invoice
(which is not the date we're looking for).
Furthermore there is no way to know if the date returned
by _get_currency_convert_date() at the time of the creation
of the first svl is the date of the time of the creation of
the svl or the date of an invoice previously confirmed.


opw-5179239

Forward-Port-Of: odoo/odoo#238904

## Dependent PR
https://github.com/odoo/enterprise/pull/98463

## Description of the issue/feature this PR addresses:
Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled.

## Current behavior before PR:
When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA.

However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because:

- Settlement orders do not contain any lines, so a new invoice cannot be generated.
- The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice.

Thus, the user cannot proceed with the settlement.

## Desired behavior after PR is merged:
After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment.

task-5144679

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

## Description of the issue/feature this PR addresses:
The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation.

## Current behavior before PR:
When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True.

This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this.

## Desired behavior after PR is merged:
After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. 

task-id - 5144679

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

Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None.

Steps to reproduce:
1) Install 'account_reports' module with demo data and enable developer mode. 
2) Navigate to Accounting > Reporting> Partner Reports > Aged Receivable.
3) Click on 'gear icon' to navigate advance options. 
4) Click on the Options tab and set Integer Rounding to 'Nearest', click save
   and close adv options.
5) Expand a partner line.

Error:
`TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'`

Root Cause:
When integer rounding is enabled, the system iterates over formula results to round them using `float_round`(see[1]). However, specific report columns (such as totals for empty periods) may return None. The `float_round` function attempts to perform arithmetic on this value, failing because it cannot divide NoneType.

FIX:
Skip the rounding if the value received at [1] is None.

[1]- https://github.com/odoo/enterprise/blob/9b517564d95424836da1e8368f6b5dc52ae45d1a/account_reports/models/account_report.py#L3329

opw-5392883

**Issue**
When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities.

**Steps to reproduce**
- Create a product with a BOM using a component with qty 6.
- Create an MO producing qty 1.
- Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed).
- Click “+1”.
- Edit the component qty from 6 to 3.
- Exit the operation.
- Re-enter the operation.
-> The component shows 3/3 instead of 3/3 and 0/3.

**Cause**
On exit, `_onExit`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489
calls `post_barcode_process()`, which triggers `split_uncompleted_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16
correctly creating a `stock.move.line` with qty 3.

However, `_truncate_overreserved_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40
then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49

This happens because the newly created move line is initialized with `reserved_uom_qty = 0`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256
leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6.

opw-5166763

**Steps to Reproduce:**

1. Create an invoice with a due date 20 days prior and an amount of $100
2. Create a payment of 120$
3. Create an invoice of 100$
4. Reconcile the second invoice with the payment
5. Go to the customer record.
6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed".

[Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing)

**Cause:**
- The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404)
- In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due.

**Solution:**
Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679)

[opw-5216007](https://www.odoo.com/odoo/project.task/5216007)