Thursday, July 23, 2026
9 changes · 19.0
Resolved issues and error corrections
Embedded views at the top of a Knowledge article now keep their intended alignment even when editor selection placeholders are present. This avoids small layout glitches when users start an article with an embedded view, keeping the editing experience consistent.
Original PR description
This commit updates the embedded view top-alignment selector to account for selection placeholders introduced by https://github.com/odoo/odoo/commit/edf7f7bb0c62978640c181eccb4934855d5d872d. This preserves the intended top-alignment behavior when an embedded view is the first editable element in the knowledge editor. Task-5951196
The Vietnam Sales Tax Report now displays VAT amounts consistently as positive values at the detailed invoice level. This avoids confusion when reviewing sales tax figures and aligns detailed lines with the totals shown in the report.
Original PR description
## 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…
## 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
The IVA Simple sales CSV now correctly reports buyers marked as “IVA No Alcanzado” under the exempt category. This prevents blank buyer type values in Argentine tax reports and improves compliance reporting accuracy.
Original PR description
### Description AFIP responsibility code `15` (IVA No Alcanzado) was missing from the `CASE WHEN` in `_vat_simple_build_sale_query`, so the "Tipo de sujeto comprador" (`responsibility_type_code`) column was left empty in the IVA Simple sale CSV for partners with that responsibility. This adds `15` to the exempt bucket (value `3`), next to its pair code `16` (IVA No Alcanzado - Otro), which was already handled there. ### Steps to reproduce 1. Set a partner's AFIP responsibility to "IVA No Alcanzado" (code 15). 2. Generate the IVA Simple sale CSV. 3. Before: the "Tipo de sujeto comprador" column is empty for that partner's rows. 4. After: it is reported as `3` (exempt bucket).
The Knowledge editor no longer offers website theme colors in its text color picker. This prevents article colors from changing unexpectedly when the website theme is updated, keeping published Knowledge content visually consistent.
Original PR description
**Steps to reproduce:** - Go to Knowledge app - Go to any article - Try to change the color of the text - Theme colors of the website are shown in the colorPicker - When applied they are mapped to `text-o-color-x` attributes - Changing the website theme affects the article colors - Published articles will have different colors if the theme was modified **Issue:** Some modules (`Knowledge`) should not be affected by the website styling. But there is no direct way to prevent this on the colorPicker. ``` // Overwrite user-defined website styles in Knowledge published articles, mainly // to avoid color customization from affecting articles content. ``` **Fix:** Remove the dynamic values from the knowledge color picker (for now). related: https://github.com/odoo/enterprise/commit/e042faab3d1d992cb471dcf9141d0a2756d06ced opw-5148839
This fix prevents an error when moving Uruguayan electronic invoicing records back to draft through remote system calls. It improves reliability for users and integrations that need to reset documents without encountering a technical failure.
Original PR description
Calling the method in RPC causes an error: ``` TypeError: cannot marshal None unless allow_none is enabled ``` Forward-Port-Of: odoo/enterprise#124740 Forward-Port-Of: odoo/enterprise#124653
This fix prevents system errors when a Knowledge article linked to an Annual Report is sent to the trash and automated cleanup runs. The related annual report data is now cleaned up together, keeping background maintenance from failing and reducing disruption for accounting users.
Original PR description
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…
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
This fixes an issue in accounting reports where the system failed to recognize when no report section had been opened yet. The correction helps reports initialize and restore sections more reliably for users.
Original PR description
**Root Cause:**
At [1], the condition `this.lastOpenedSectionByReport === {}` always
return `false` because JavaScript compares objects by reference
rather than by value. As a result, the code never detects when
`lastOpenedSectionByReport` is empty.
**Fix:**
This commit ensures the code correctly detects an empty
`lastOpenedSectionByReport` object.
[1]:
https://github.com/odoo/enterprise/blob/ae4b461edb1d6b49c25d4e264380e7ae4b67f10c/account_reports/static/src/components/account_report/controller.js#L50
**No task ID**
Forward-Port-Of: odoo/enterprise#124223This fix updates expected Mexican chart of accounts labels used in trial balance report checks so they match the official account groups. It helps keep localization validation reliable and prevents report-related checks from failing because of incorrect expected names.
Original PR description
Enterprise companion of odoo/odoo#277615 — the forward-port to 19.0 of the `l10n_mx` fix that restores the SAT account group names copied from siblings. The `l10n_mx_reports` trial balance test asserts the full Chart of Accounts XML sent to the SAT with the group names hardcoded in the expected output. Two of them were wrong (copied from sibling groups) and are corrected by the community PR: - SAT group **602** (Gastos de venta): `Cost of sales` → `Selling expenses` (`Cost of sales` is 501.01). - SAT group **614** (Amortización contable): `Accounting depreciation` → `Accounting amortisation` (that name belongs to 613). Without this, `ci/l10n` fails on `TestL10nMXTrialBalanceReport.test_generate_coa_xml` and `...test_generate_coa_xml_with_prefix_7_accounts_having_debit_and_credit_tags`. Same branch name as the odoo PR so the mergebot pairs them.
This fixes the French VAT report so the BA zone is sent using the expected free-text format instead of a standard value field. This helps ensure VAT submissions match the required format and reduces the risk of reporting validation issues.
Original PR description
The value inside the BA zone needs to be a "TexteLibre1" and not a value no task id