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