## 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 wave/batch from the auto_wave 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

Forward-Port-Of: odoo/odoo#243519

Before this commit, trigger to click on a product in the product list was the same trigger to click on a product in a cart list ...

With the following scenario, step CartPage.clickBack() can take few times to show the back screen, but as the trigger is the same for clickProduct on a product list screen than a cart screen, the last step clik on "o_self_product_box" ... but in the cart (and not in the product list)

ProductPage.clickProduct("Coca-Cola"), => OK
ProductPage.clickProduct("Coca-Cola"), => OK
Utils.clickBtn("Checkout"), => OK
CartPage.checkProduct("Coca-Cola", "5.06", "2"), => OK CartPage.clickBack(), => OK
ProductPage.clickProduct("Coca-Cola"), => NOK

To fix it, it is enought to just be more precise on the trigger to avoid confusions.
This fix fixes probably a pair of tours.

error-runbot-id~227669
(and probably others)

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

When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email.
This fix changes the order to generate the DDT number before sending the email.

Steps to reproduce:
- Create a database with an Italian company and the `l10n_it_stock_ddt` module installed
- Turn on `Settings > Inventory > Shipping > Email Confirmation`
- Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates`
- Edit the `Shipping: Send by Email` template
- Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`.
- Create a SO, validate it
- On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery.
- In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name.
- If you open the report, the title of the PDF is also missing the DDT name.

Ticket [link](https://www.odoo.com/odoo/project.task/5364265)
opw-5364265

Forward-Port-Of: odoo/odoo#243492

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

Forward-Port-Of: odoo/odoo#243604
Forward-Port-Of: odoo/odoo#233769

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

Forward-Port-Of: odoo/enterprise#104197
Forward-Port-Of: odoo/enterprise#98463

The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing
the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese.

By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users.

Technical details:
- Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header
- Added Vietnamese translations for all tax records in the template
- Translations follow Vietnamese tax terminology conventions
- The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields

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#241681
Forward-Port-Of: odoo/odoo#236502