Steps to reproduce:
1 Install documents_hr and hr_sign on saas-19.1.
2 Go to Settings → Documents → disable Human Resources. 
3 Open the Documents app and delete the Employees - My Company folder. 
4 Upgrade the database to saas-19.2.

Issue:
- During the upgrade, the post-init hook attempts to embed the HR Sign action into predefined document folders. Since the Employees - My Company folder has been deleted (or is inactive), the folder lookup returns no record, leading to the following error:

```python3
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-19.2/odoo/service/server.py", line 1664, 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/saas-19.2/odoo/tools/func.py", line 65, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/registry.py", line 186, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 465, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 244, in load_module_graph
    getattr(py_module, post_init)(env)
  File "/home/odoo/src/enterprise/saas-19.2/documents_hr_sign/__init__.py", line 12, in _embed_sign_post_init
    folders.with_user(SUPERUSER_ID)._embed_action(sign_action.id)
  File "/home/odoo/src/enterprise/saas-19.2/documents/models/documents_document.py", line 1643, in _embed_action
    folder.action_folder_embed_action(folder.id, action_id)
  File "/home/odoo/src/enterprise/saas-19.2/documents/models/documents_document.py", line 1614, in action_folder_embed_action
    return self.get_documents_actions(folder_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.2/documents/models/documents_document.py", line 1522, in get_documents_actions
    raise UserError(_('This folder does not exist or is not accessible.'))
odoo.exceptions.UserError: Esta carpeta no existe o no es accesible.
```

Root cause:
- As part of documents_sign, the documents_hr_sign action is embedded into predefined document folders (introduced in https://github.com/odoo/enterprise/pull/101890).
- The folder lookup relies on [_search()](https://github.com/odoo/odoo/blob/85992d5f5f8caeacdcc570fb9fefb4cfcec6460c/odoo/orm/models.py#L4681-L4691), which filters out inactive records 
  through the active test. Consequently, [search_fetch()](https://github.com/odoo/odoo/blob/85992d5f5f8caeacdcc570fb9fefb4cfcec6460c/odoo/orm/models.py#L1441-L1451) returns no matching

  folder when the predefined folder has been deleted or deactivated.  It will
  try to get document actions of predefined folder here, so if the folder is
https://github.com/odoo/enterprise/blob/6d334a17d10faec33d60f4a8d7d263c091bb456e/documents/models/documents_document.py#L1592
  inactive it will not be able to read the folder here.
https://github.com/odoo/enterprise/blob/6d334a17d10faec33d60f4a8d7d263c091bb456e/documents/models/documents_document.py#L1494

Fix:
- Instead of attempting to embed the Sign action into all company employee folders, filter out inactive folders before calling _embed_action().

- This ensures the post-init hook only processes active employee document folders. If a predefined folder has been deleted or deactivated, it is skipped preventing the upgrade from attempting to embed an action into an inaccessible folder and avoiding the resulting UserError.

opw-6358063
upg-4449902

Forward-Port-Of: odoo/enterprise#123846

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

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

`pos_amount_unsettled` is a stored computed field defined as the invoice's residual minus the settle lines belonging to sessions that are not yet closed. Its compute method filters the lines on `order_id.session_id.state`, but that state is not in the compute dependencies.

When closing a session holding a settle order, `_validate_session()` first reconciles the settle payment with the invoice (which lowers `amount_residual_signed` and flags the field for recomputation) and only then writes `state = 'closed'` on the session. If the pending recomputation is executed in that window (any flush of `account.move` does it: recomputing the field for any other flagged record drags the whole queue along), the settle line is deducted from the already reconciled residual, i.e. counted twice, and the field is stored as `residual - settled` instead of `residual`. Since the session state is not a dependency, writing `state = 'closed'` does not flag the field again and the wrong value is never corrected.

The partner's `invoices_amount_due` then goes negative, which hides the "Settle invoices" option in the POS partner list and inflates the "Settle due amount" proposal
(`remainingDue = total_due - pos_orders_amount_due - invoices_amount_due`): a customer owing e.g. 500 is proposed, and charged, 700.

Steps to reproduce:
1. Post a customer invoice of 1000.
2. In the POS, select the customer > Settle invoices, pick the invoice, set the amount to 700 and pay in cash.
3. Close the session. The issue only occurs when the pending recomputation runs during the closing, which depends on the other operations performed by it (not deterministic in real usage; the regression test forces it with a flush after the reconciliation).
4. The invoice's "Amount To Pay In POS" shows -400 instead of 300 and the POS proposes to settle 700 instead of 300.

Add the session state to the compute dependencies so that the field is recomputed once the session is closed, yielding the correct amount regardless of any intermediate recomputation.

opw-6375095

Forward-Port-Of: odoo/enterprise#123783

[FIX] documents_{hr|sign}: employee docs button for signed contracts
Bug reproduction:

1 - In saas-19.4, install documents_hr and hr_contract_salary with demo data
2 - As Mitchell Admin, go to Employees, open one, click on "Offers - New"
3 - Select employee_contract.pdf as PDF Template
4 - Use the button "Salary configurator" to fill in the configurator, review it and sign it.
5 - Go back to the backend, find the contract in Sign and sign it.
6 - Go back to the Employee form view, the Documents stat button shows 0 document when it should be 1.
7 - Click the stat button and you see 0 documents in Documents when there should be one.

Bug cause:

1 - The document is created for the employee in documents app
    but smart button cannot open those
2 - The res_model of the documents.document is hr.version for signed doc
    -> it is not hr.employee
3 - In current implementation:
    3.1 -> only hr.employee's documents appear after that smart button

Bug solution:

1 - _compute_document_count is reimplemented:
    -> to count also documents with res_model as hr.version
2 - override _get_documents_domain:
    -> to add version domain as an alternative with OR
        -> to get documents with res_model='hr.version'

Test:

1 - Unit test is added
2 - Create documents with the archived versions of the employee
    -> and observe the document count of the employee

Note:

-> Also, we changed the final document name in documents of the employee

task-6373620

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#125229
Forward-Port-Of: odoo/enterprise#121755

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

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

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

`pos_amount_unsettled` is a stored computed field defined as the invoice's residual minus the settle lines belonging to sessions that are not yet closed. Its compute method filters the lines on `order_id.session_id.state`, but that state is not in the compute dependencies.

When closing a session holding a settle order, `_validate_session()` first reconciles the settle payment with the invoice (which lowers `amount_residual_signed` and flags the field for recomputation) and only then writes `state = 'closed'` on the session. If the pending recomputation is executed in that window (any flush of `account.move` does it: recomputing the field for any other flagged record drags the whole queue along), the settle line is deducted from the already reconciled residual, i.e. counted twice, and the field is stored as `residual - settled` instead of `residual`. Since the session state is not a dependency, writing `state = 'closed'` does not flag the field again and the wrong value is never corrected.

The partner's `invoices_amount_due` then goes negative, which hides the "Settle invoices" option in the POS partner list and inflates the "Settle due amount" proposal
(`remainingDue = total_due - pos_orders_amount_due - invoices_amount_due`): a customer owing e.g. 500 is proposed, and charged, 700.

Steps to reproduce:
1. Post a customer invoice of 1000.
2. In the POS, select the customer > Settle invoices, pick the invoice, set the amount to 700 and pay in cash.
3. Close the session. The issue only occurs when the pending recomputation runs during the closing, which depends on the other operations performed by it (not deterministic in real usage; the regression test forces it with a flush after the reconciliation).
4. The invoice's "Amount To Pay In POS" shows -400 instead of 300 and the POS proposes to settle 700 instead of 300.

Add the session state to the compute dependencies so that the field is recomputed once the session is closed, yielding the correct amount regardless of any intermediate recomputation.

opw-6375095

Forward-Port-Of: odoo/enterprise#123783

To reproduce the issue:

1) Create a company in Belgium
2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only accepts "review" and "submit" stages, not "paid" anymore 4) Go to the list of returns, remove the TODO filter => traceback

The problem is here that the existing returns don't recompute their state when the workflow of the type is modified. In some cases, this is fine, but it others, it's annoying. In our example, the terminal state changed, so all the returns in that terminal stage should change their state to the new terminal one. "paid" is not an accepted value anymore, it should become "submitted".

Moreover, when the workflow is changed, the selection field actually containing the state must also change. As it is, it seems to work because "state" of account.return is stored, but the value it's based on (the workflow field) won't be consistent with it. It's not annoying now, but those inconsistencies could become a big source of trouble in the future (we know that from experience ... I'm looking at you, version 8 ! è-é).

This issue typically happens at upgrade. We had cases in FR and AE already. We solve that by a generic override of the write to sort things out when such change needs to happen. An upgrade PR will also be done to adapt the script so that we eventually solve the inconsistencies on dbs that have already migrated to 19.0.

Forward-Port-Of: odoo/enterprise#124144

# How to reproduce
- Have a lot of reusable & locationless packages (e.g. > 10 000)
- Go to any transfer via the barcode application

# The issue
There is a very long loading time, even in local testing. The client of the tickets experiences loadings up to 120 seconds with 50k packages

# Cause
When opening a transfer, we load barcode data by doing an API call to `_get_stock_barcode_data` : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L85

During this we preload a lot of records, notably packages : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L128

The issue is that in the fields we read for the packages, two of them (`location_dest_id` & `contained_quant_ids`) have a `_read_group` in their compute (or in the compute of one of the fields they depend on) :
https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L65 https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L146

Fortunately, this does not mean that we make a query for every records. Instead, in Odoo, we fetch records in batch of 1000.

So, for the case of the client, every time he loads the database, the backend does 50 000 / 1000 x 2 = 100 queries, which hinders performance a lot

A [PERF] commit was done to limit the number of packages that are fetched base on a config parameter. The problem is that this parameter does not have a default value, so clients still end up with the problem.

[PERF]: https://github.com/odoo/enterprise/commit/efe18bc1ea479270e42846986d7ed449b0865617

# Proposed Solution
Add a default value for that config parameter. The exact value is up to discussion

opw-6200730

Forward-Port-Of: odoo/enterprise#124538
Forward-Port-Of: odoo/enterprise#123696

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

`pos_amount_unsettled` is a stored computed field defined as the invoice's residual minus the settle lines belonging to sessions that are not yet closed. Its compute method filters the lines on `order_id.session_id.state`, but that state is not in the compute dependencies.

When closing a session holding a settle order, `_validate_session()` first reconciles the settle payment with the invoice (which lowers `amount_residual_signed` and flags the field for recomputation) and only then writes `state = 'closed'` on the session. If the pending recomputation is executed in that window (any flush of `account.move` does it: recomputing the field for any other flagged record drags the whole queue along), the settle line is deducted from the already reconciled residual, i.e. counted twice, and the field is stored as `residual - settled` instead of `residual`. Since the session state is not a dependency, writing `state = 'closed'` does not flag the field again and the wrong value is never corrected.

The partner's `invoices_amount_due` then goes negative, which hides the "Settle invoices" option in the POS partner list and inflates the "Settle due amount" proposal
(`remainingDue = total_due - pos_orders_amount_due - invoices_amount_due`): a customer owing e.g. 500 is proposed, and charged, 700.

Steps to reproduce:
1. Post a customer invoice of 1000.
2. In the POS, select the customer > Settle invoices, pick the invoice, set the amount to 700 and pay in cash.
3. Close the session. The issue only occurs when the pending recomputation runs during the closing, which depends on the other operations performed by it (not deterministic in real usage; the regression test forces it with a flush after the reconciliation).
4. The invoice's "Amount To Pay In POS" shows -400 instead of 300 and the POS proposes to settle 700 instead of 300.

Add the session state to the compute dependencies so that the field is recomputed once the session is closed, yielding the correct amount regardless of any intermediate recomputation.

opw-6375095

Forward-Port-Of: odoo/enterprise#123783

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

When importing an EnvioDTE XML containing several DTEs (journal upload or incoming DTE mail server), one vendor bill is created per DTE, but the first bill receives the invoice lines and references of ALL the DTEs in the file, causing the total amount mismatch.

Cause: `_split_xml_into_new_attachments()` creates new attachments for the documents beyond the first one but leaves the original `file_data['xml_tree']` untouched; the decoder must scope itself to the first document (as l10n_it_edi and l10n_es_edi_facturae do), which `_l10n_cl_import_dte()` never did.

e.g. l10n_es_edi_facturae:633:

```python
# Only decode the first invoice of the Factura-e file.
tree = tree.xpath('//Invoice')[0]
```

Fix: scope the tree to the first DTE node before filling the bill. Kept behind a `len > 1` guard so files with a bare <DTE> root (matched by `xpath('//ns0:DTE')` but not by `findall('.//ns0:DTE')`) keep working.

Introduced in: https://github.com/odoo/enterprise/pull/75327.

opw-6378954

Steps to reproduce:
- Set the database language to Spanish (Latin America).
- Create a customer invoice, confirm it and send it to the SII.
- Print it using Print > Invoice PDF copy (Chile).
- Scroll to the CEDIBLE section at the bottom of the PDF.

Cause of the issue:
The CEDIBLE footer is merged into l10n_cl.report_invoice_document, which account.report_invoice (odoo/addons/l10n_cl/views/report_invoice.xml) renders with t-lang set to the invoice partner's lang, not the database/user language. The disclaimer text was hardcoded in English and relied on the regular translation to be shown in Spanish, so as
soon as the partner's lang field isn't Spanish, the translation lookup falls back to the untranslated English source, regardless of the database language.

Solution:
This disclaimer is boilerplate mandated by Chilean law: it must always be printed in Spanish, independently of the invoice partner's or current user's language. The same template already follows that rule a few lines above for the SII stamp block ("Timbre Electrónico SII..."), which is hardcoded in Spanish instead of relying on translation.

opw-6390207

**Steps to reproduce:**

- Enable "Move Entire Packages" setting on deliveries
- Make a product A, that has a package P1, on hand qty of 1
- Make product B that don't have a package, but on hand qty of 1
- Make a delivery that has both of those products, requested qty of 1 for both
- Mark it as todo
- Go to the barcode app, select the delivery
- Select the line with product B
- Select the line with product A
--> The line with product B is not unselected

**Why the fix:**

When we have a mix of packaged products and products without a package on the same operation, they are handled separately.
The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 
that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 
But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**.

As we do not touch this variable, the selected package line stays selected.

The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 
This function does not care for the **selectedLineVirtualId** which represents the selected line without a package.

To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation.

This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 
to unselect every line regardless of packages.

opw-6266203

Forward-Port-Of: odoo/enterprise#124717
Forward-Port-Of: odoo/enterprise#122038

# How to reproduce
- Have a lot of reusable & locationless packages (e.g. > 10 000)
- Go to any transfer via the barcode application

# The issue
There is a very long loading time, even in local testing. The client of the tickets experiences loadings up to 120 seconds with 50k packages

# Cause
When opening a transfer, we load barcode data by doing an API call to `_get_stock_barcode_data` : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L85

During this we preload a lot of records, notably packages : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L128

The issue is that in the fields we read for the packages, two of them (`location_dest_id` & `contained_quant_ids`) have a `_read_group` in their compute (or in the compute of one of the fields they depend on) :
https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L65 https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L146

Fortunately, this does not mean that we make a query for every records. Instead, in Odoo, we fetch records in batch of 1000.

So, for the case of the client, every time he loads the database, the backend does 50 000 / 1000 x 2 = 100 queries, which hinders performance a lot

A [PERF] commit was done to limit the number of packages that are fetched base on a config parameter. The problem is that this parameter does not have a default value, so clients still end up with the problem.

[PERF]: https://github.com/odoo/enterprise/commit/efe18bc1ea479270e42846986d7ed449b0865617

# Proposed Solution
Add a default value for that config parameter. The exact value is up to discussion

opw-6200730

Forward-Port-Of: odoo/enterprise#124538
Forward-Port-Of: odoo/enterprise#123696

**Issue:**

Envia API documentation is very bad. When trying to generate an Amazon Ground shipping with Envia, the API will sometimes reject the payload with the following error:

`Total items weight exceeds package weight. Please refer to API documentation for allowable limits. (D-703)`

Even though the [Envia documentation](https://docs.envia.com/reference/create-shipping-label) doesn't include it, it seems that Amazon requires the weight for each product. If the payload doesn't include the per-item weight, Amazon will set a default weight, which will cause the error to show up if the delivery contains a high quantity. This can be a blocking issue for some customers.

**Steps to reproduce on a fresh DB:**

- Install Inventory, Sales, and Envia Shipping
- Switch company to be based in India (need to provide an address to deliver from, I just used the Odoo India address - InfoCity Gate, Gandhinagar, Gujarat 382007)
- Configure an Amazon delivery carrier with Envia (India seems to be the only country that supports Amazon with Envia)
	- Inventory > Configuration > Delivery Methods > Envia.com method
	- Must be in a Production environment (because Envia's sandbox server does not work for some reason?)
	- Add an Envia Production Access Token (will have to use one with some funds)
	- Change 'Ship From' to India
	- Configure the `Envia.com Service Name`, set Carrier and Service to AMAZON and AMAZON - Amazon Shipping Standard
- Create a demo product, give it an arbitrary weight like 0.1 kg
- Create a sales order to an Indian customer, include the demo product with a high quantity (like 20), confirm (might have to create a warehouse and configure the customer's information)
- On the generated picking, set the Carrier to Envia.com on the Additional Info tab
- When trying to Validate, it should throw the error

**Fix:**
When generating the payload in _get_shipping_lines() in envia_request, include the item weight in the dictionary.

Related ticket: opw-6261682

Forward-Port-Of: odoo/enterprise#125017
Forward-Port-Of: odoo/enterprise#123935

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous [fix](https://github.com/odoo-dev/enterprise/commit/db93bd2ee313b6bb1959a41c9beb9850975b9959
) introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:
https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L1778

Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.

---

Related community PR : https://github.com/odoo/odoo/pull/267987

---

opw-6260735

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

`pos_amount_unsettled` is a stored computed field defined as the invoice's residual minus the settle lines belonging to sessions that are not yet closed. Its compute method filters the lines on `order_id.session_id.state`, but that state is not in the compute dependencies.

When closing a session holding a settle order, `_validate_session()` first reconciles the settle payment with the invoice (which lowers `amount_residual_signed` and flags the field for recomputation) and only then writes `state = 'closed'` on the session. If the pending recomputation is executed in that window (any flush of `account.move` does it: recomputing the field for any other flagged record drags the whole queue along), the settle line is deducted from the already reconciled residual, i.e. counted twice, and the field is stored as `residual - settled` instead of `residual`. Since the session state is not a dependency, writing `state = 'closed'` does not flag the field again and the wrong value is never corrected.

The partner's `invoices_amount_due` then goes negative, which hides the "Settle invoices" option in the POS partner list and inflates the "Settle due amount" proposal
(`remainingDue = total_due - pos_orders_amount_due - invoices_amount_due`): a customer owing e.g. 500 is proposed, and charged, 700.

Steps to reproduce:
1. Post a customer invoice of 1000.
2. In the POS, select the customer > Settle invoices, pick the invoice, set the amount to 700 and pay in cash.
3. Close the session. The issue only occurs when the pending recomputation runs during the closing, which depends on the other operations performed by it (not deterministic in real usage; the regression test forces it with a flush after the reconciliation).
4. The invoice's "Amount To Pay In POS" shows -400 instead of 300 and the POS proposes to settle 700 instead of 300.

Add the session state to the compute dependencies so that the field is recomputed once the session is closed, yielding the correct amount regardless of any intermediate recomputation.

opw-6375095

When a knowledge article linked to an Annual report is moved to the trash and
the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate.

Steps to reproduce the error:
- Install ``accountant_knowledge`` module
- Go to Accounting > Review > Annual Report > Create a new annual report
- Go to Knowledge > Open the knowledge article linked to the annual report > Send to Trash
- Run the ``Base: Auto-vacuum internal data`` cron

Traceback:
```py
ForeignKeyViolation: update or delete on table "knowledge_article" violates foreign key constraint 
"audit_report_knowledge_article_id_fkey" on table "audit_report" DETAIL:  Key (id)=(67) is still referenced from table "audit_report".
```

https://github.com/odoo/enterprise/blob/04cce2e400ce2e412f28aa1849078a7c40ff0e2c/knowledge/models/knowledge_article.py#L1069-L1070
The garbage collector deletes trashed knowledge articles that match its domain.
Since this domain also includes articles linked to Annual Reports,
the cron attempts to delete records that are still referenced by annual report,
resulting in a foreign key violation error.

Solution:
Ensure linked audit reports are also deleted during knowledge article garbage collection.

sentry-7488793071

Currently when a user with a product manager rights that is not admin tries to look up the product with barcode information is not auto filled.

## Steps to replicate:
- Install stock with demo data
- Barcode Database > Setup barcode lookup credentials
- Users > Marc Demo > Give Marc Demo > Master Data > Products > Create
- Login as `Marc Demo`
- Products > Barcode: `850049670180` > Click anywhere else

## Observed Behaviour:
Information on the product template is not autofilled, as it would be when using a System Admin user(Mitchell Admin).

## Root cause:
This issue occurs because barcode lookup is gated behind a check for System Admin rights. Although users in the Product Manager group have permission to create products, they do not satisfy this condition, so the barcode lookup never executes at [1].
[1]-
https://github.com/odoo/enterprise/blob/c66995fda83e19b28a38312af8efdc1601881cf0/product_barcodelookup/models/product_template.py#L17-L22 
## Why this is an issue:
The original restriction (task [2] and commit [3]) was intended to limit barcode lookup to users who can create products, preventing unnecessary API calls. This was a valid assumption in 17.3-18.0, where creating products in POS required System Admin rights but now after commit [4] this is no longer the case.

In v18, task [5] introduced the Product Manager group, making product creation independent of System Admin rights or module rights. Later, v18.3 exposed these Master Data access rights to non-debug users through commit [6].

As a result, there are users who are legitimately responsible for product creation and maintenance (regardless of POS usage) they can no longer use barcode lookup unless they are also granted full System Admin privileges, which provides broader access than required.

## Solution:
Remove the group-based permission check so that access is determined solely by product edit permissions. This ensures that only users with the ability to modify products can use the API call, preserving the original security intent.
As a result, users no longer need unnecessary administrative privileges toperform barcode lookups.

[2]:
https://www.odoo.com/odoo/project/49/tasks/3911024 
[3]:
https://github.com/odoo/enterprise/commit/444df3e48cb8d479d3b5d4a03a4bfefa48650910 
[4]:
https://github.com/odoo/odoo/commit/821bbc4504fd80a508e2412c7490ee60dd03f7b8 
[5]:
https://github.com/odoo/odoo/commit/d4886faf12ccaf63d5e899c20df2543d1ce046ab 
[6]:
https://github.com/odoo/odoo/commit/e74eaf628498155243db73ea229eaf5e74c24f2a

opw-6290999

### Issue before this commit:
When reverting a Guatemalan invoice (creating a credit note), the XML node FechaEmisionDocumentoOrigen incorrectly reports the EDI document's technical certification date instead of the original invoice's emission date. This causes the SAT to reject the document.

### Steps to reproduce the issue:
1. Download Accounting and l10n_gt
2. Revert an invoice (credit note) inserting a different date than the one of the invoice
3. See that FechaEmisionDocumentoOrigen report the date of the credit note instead of the one of the invoice

### Cause of the issue:
The _l10n_gt_edi_add_reference_values method extracted the date from original_document.datetime (the technical timestamp of when the XML was generated) rather than using the actual accounting date of the original invoice.

### Reason to introduce the fix:
SAT validation rules strictly require the reference date to match the exact commercial emission date of the original invoice. Fetching invoice_date directly ensures compliance, avoids timezone conversion errors, and prevents the XML from being rejected.
Source: https://www.lawinsider.com/es/contracts/dJXl4Vo79L2

<img width="730" height="205" alt="2026-07-17_10-19" src="https://github.com/user-attachments/assets/802e7bb3-fcf9-48db-b86f-227b494001b6" />

opw-6394409

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

When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field.

This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list.

This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected.

**Steps to reproduce:**

- Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit
- In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode
- In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field

**Current behavior before PR:**

- Custom fields do not trigger inline edit mode

**Desired behavior after PR is merged:**

- Custom fields trigger inline edit mode

opw-6378102

When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772