## Current behavior:
In Vietnam's Sales Tax Report, when unfolding until the minimum layer, the VAT now displays the value in negative

## Expected behavior:
The VAT value in the minimum layer should be consistent with the upper layers and kept positive

## Steps to reproduce:
- Install l10n_vn (l10n_vn_reports will install as well)
- Switch to VN Company
- With demo data, go to Invoicing / Reporting / Tax Report
- Change Tax Report (VN) to Sales/Purchase Tax Report (VN)
- Unfold the lines all the way to the minimum layer: VAT on sales of goods and services 10% -> INV/2026/00003
- Observe that the VAT 10% line is at negative, which is inconsistent with the Total line below

## Cause of the issue:
- In Odoo, tax journal items store tax_base_amount with the accounting sign (negative for sales). This is expected behavior
- However, Vietnamese VAT listing expects commercial amounts, which means sales bases need to be displayed as positive numbers

## Fix:
Normalized tax_base_amount sign in _query_tax_lines function before building the SQL query

opw-6344577

Forward-Port-Of: odoo/enterprise#122785

Steps to reproduce:
- Set the user language to Dutch.
- Go to Accounting > Reporting > Annual Statements.
- Generate the XBRL export for a report other than the "company,
  abridged" (acon) balance sheet/P&L combination, e.g. an association
  (asso_a/asso_f) or "company, full"/"company, capital" report.
- Open the file: the `<met:bln1>` boolean facts are exported as
  "onwaar" instead of "false", which is not a valid XBRL boolean
  lexical value and gets rejected by the NBB validator.

Cause of the issue:
QWeb templates translate static text nodes by default. The base
module ships a generic `msgid "false" -> msgstr "onwaar"` translation,
used elsewhere in the UI, which silently hijacks the literal
"false"/"true" and unit tokens ("iso4217:EUR", "pure") in the XBRL
data templates whenever the file is generated in Dutch.

Solution:
Add `t-translation="off"` on the `<met:bln1>` boolean facts and the
`<measure>` unit tokens in the 5 remaining XBRL templates,
so these fixed-vocabulary XBRL values are never subject to translation

opw-6395785

Forward-Port-Of: odoo/enterprise#124945

Steps to reproduce
---
1. Enable Packages and turn on "Move Entire Packages" on the delivery operation type.
2. Create a storable product P and add 2 units in different package in stock: 1 in PACK001, 1 in PACK002 
3. In the Barcode app > Operations > Delivery > New
4. Scan a first package PACK001, then a second different package PACK002
5. Scan the first package PACK001 again.

Issue
---
Re-scanning an already scanned package is meant to be rejected with a "This package is already scanned." warning, but the rejection stops working as soon as a second package is present in the transfer, so the package content gets added a second time and, once validated, the source quant goes negative (the package ends up holding a negative and a positive quant of the same product).

Commit 23613c63947 added a canPackSomeLines flag that is set to true for every package line that is not the scanned one, so any other package in the transfer makes the alreadyDonePackId && !canPackSomeLines guard false and silently skips the warning. The scanned package already exposes whether it had something left to pack through scannedPackages, so gating the warning on that flag instead keeps the check working regardless of how many other packages are in the transfer.

https://github.com/odoo/enterprise/blob/3cc1a162e61662814b0e52c0c720831952d208a8/stock_barcode/static/src/models/barcode_picking_model.js#L1976-L2006

opw-6279105

Forward-Port-Of: odoo/enterprise#121755

To reproduce the issue:

1) Initialize a company in Belgium, create the tax returns 2) Submit the VAT return from January
3) Open the lock date wizard. The tax lock date is January 31st. 4) Add a lock date exception removing the tax lock date just for you, for 5 min. 5) Reset January's return
6) Reopen the lock date wizard.
    ====> Your exception is still there, but the tax lock date for everyone has been reset to December 31st.

This is plain wrong. Resetting a return should not automatically reopen the period for everyone. Lock dates exceptions/modifications are anyway required to reset the return ; they should pilot the whole flow. Nothing being magically hidden from the user means there can't be someone else mistakenly encoding something into the reopened period.

Another fix was required to make this one work: setting the tax lock date before submitting the return should work. In bigger environments, users might want to do that as a first step to reduce the number of people encoding data before actually doing the submission of the return. Therefore, the case where the tax lock date is already set at the date_to of the return when submitting it was supposed to be already supported, and allow the creation of the closing entry for that return, despite it being on the tax lock date. The test ensuring this was however badly written, and the feature didn't work: the closing was created at a later date than the lock date automatically, due to the Bills' Algorithm.

Forward-Port-Of: odoo/enterprise#124872
Forward-Port-Of: odoo/enterprise#124811

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

- Opening Studio on a form containing a `Many2many` field using the `many2many_tags_email` widget crashes with an OWL prop validation error.

- **Steps to reproduce:**

1. Open any form view (e.g., Contacts) and enter `Studio`.
2. Create a new `Many2many` custom field on a model such as `res.partner` .
3. Set the field's widget to `many2many_tags_email` and save the customization.
4. Exit Studio and populate the field with one or more related records.
5. Open Studio again on the same form view.

This results in the following error:
```.js
Error: Invalid props for component 'RecipientTag': 'onDelete' is undefined (should be a value)

```

### Current behavior before PR:

- When opening Studio on a form containing a `Many2many` field with the `many2many_tags_email` widget, the field is rendered with `onDelete` set to undefined by `Many2ManyTagsField`. Starting from `saas-19.1`, the `many2many_tags_email` widget uses the new [RecipientTag](https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/static/src/core/web/recipient_tag.js) component, which requires onDelete to be defined. As a result, Owl's prop validation fails when RecipientTag receives `onDelete = undefined`, causing Studio to crash with an Invalid props for component 'RecipientTag' error.

### Desired behavior after PR is merged:

- `RecipientTag` should allow `onDelete` to be optional so that it can also be used when the parent field does not provide a delete callback. This prevents the Owl prop validation error when opening Studio, while keeping the existing delete functionality unchanged for editable fields where onDelete is available.

opw:6395209

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

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `mrp` module
- Go to the setting enable `Lots & Serial Numbers` and `Storage Locations`
- Create a storable product tracked by Lots
- Configure a Putaway Rule for the product so it is stored in a
  sub-location
- Create a Bill of Materials for the product with at least one
  component
- Create and confirm a Manufacturing Order
- Increase the production quantity (e.g. using the "Change Production
  Quantity" wizard)
- Click **Generate Lot/Serial Number**
- Click **Produce All**

Issue:
------
Completing the Manufacturing Order raises:

    Invalid Operation
    You need to supply a Lot/Serial Number for product:
    - Product

even though a single lot should be sufficient for a lot-tracked
product.

Cause:
------
When the production quantity is increased, `change_prod_qty()` updates
the finished move's demanded quantity and re-reserves it through
`_update_finished_moves()`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/wizard/change_production_qty.py#L77

which calls `_action_assign()` on the finished move:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/wizard/change_production_qty.py#L49

Since finished moves originate from the production location, they
bypass the normal reservation flow:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2070

`_action_assign()` then tries to reuse the move's existing move line,
but the lookup requires `location_dest_id` to still match the move's
generic destination:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2092-L2106

That existing line's `location_dest_id` was already redirected to the
putaway sub-location by the previous `_apply_putaway_strategy()` call
(at MO confirmation), so the lookup no longer matches and a second,
distinct move line is created and appended instead of the first one
being reused:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2170

Later, clicking **Generate Lot/Serial Number** creates a single lot and
stores it on the production order's `lot_producing_ids`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L1602

When **Produce All** is clicked, which trigger `button_mark_done()`  it calls
`_post_inventory()`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L2227

which assigns that lot to the finished move through `move.lot_ids`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L1925

Since `lot_ids` is declared with `inverse='_set_lot_ids'`, this write
triggers that inverse method:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L192

The current implementation of `_set_lot_ids()` only assigns the lot to
a single available move line, regardless of tracking type:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L656-L668

Since only one lot is ever generated for a lot-tracked product, only
the first finished move line receives a `lot_id`. The second move line
created after increasing the production quantity is left without one.

When `button_mark_done()` validates the finished move lines, it
detects that one of them still has no lot assigned and raises the
"Invalid Operation" error, even though a single lot is valid for the
entire production of a lot-tracked product.

Fix:
----
`action_generate_serial` produces a single lot for the whole production.
In `_post_inventory()`, right after the generated lot is set on
the finished move, propagate it to any remaining lot-less move lines
of a **lot**-tracked finished move.

---

opw-6366060

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

Forward-Port-Of: odoo/odoo#275000

# Step to reproduce
- Install eCommerce
- Activate dev mode with tests assets (important!)
- Go to the website & add a Countdow in the footer
- Add a new product from the website system tray
- Put any name & Save
- Go into Edit mode
- In the Style tab, (un)toggle "Tax Indication" (may need to do it multiple times)

> Note that the issue is quite inconsistent to reproduce
# Issue
A traceback is shown

# Cause
The only thing I'm sure of is that the error is caused by this code :
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/website/static/tests/tour_utils/lifecycle_dep_interaction.js#L18-L20

And that it is linked to `browser.localStorage`. I suspect it is due to some weird localStorage and
WysiwygAdapter interaction :
https://github.com/odoo/odoo/blob/d6a08b67a948f569a1ca893b6337ce50b4ef9f07/addons/website/static/tests/tours/widget_lifecycle.js#L53-L60

But I can't be sure because debugging tools do not seem to be working. See the inverstigation comment
in the associated PR for more information.

# Proposed Solution
Since this code is only used for this test :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L14-L15

And the test directly parses from the `window.localStorage` :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L50

We can use `window.localStorage` instead of `browser.localStorage`  as it fixes the issue

opw-6246850

Forward-Port-Of: odoo/odoo#272736

## Problem
When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused by the `order` variable being reused from a previous loop.

## Solution
We will pull the order name directly from the order line in the current iteration.

## Steps to reproduce (Runbot v19)
1. Create a product with AVCO perpetual valuation
2. Make sure all accounts are configured properly (Income, Expense, Stock, and stock variation accounts)
3. Add units to the stock (it can be with an adjustment, as long as the product has a cost already set)
4. Create 2 separate sales orders for this product
5. Deliver both of the sales orders, do not invoice them
6. Now go to the Accounting App Review>Invoices to be issued
7. Select the 2 invoices that were created.

The Revenue accrual lines are correct, with each SO being referenced, but on the Stock variation lines, only the last SO selected will appear.

opw-6361032

Forward-Port-Of: odoo/odoo#277058