Odoo Changelog — 2026-05-07

Thursday, May 7, 2026

4 changes · 17.0

Bug Fixes(4)

Resolved issues and error corrections

[FIX] l10n_no_reports: fix VAT declaration XML validation errors

Enterprise17.0l10n_noMEDIUM

This update corrects errors in the Norwegian VAT XML export, ensuring it passes validation checks by Skatteetaten (the Norwegian tax authority). The changes include precise decimal formatting, correct rounding, mandatory legal note additions, and proper handling of company identification codes. This ensures accurate VAT returns and avoids potential delays or penalties.

Original PR description

Before commit:
The Norwegian VAT XML export fails Skatteetaten validation due to incorrect
decimal formatting, mathematical rounding mismatches between base and tax
amounts, missing mandatory legal notes, and invalid KID number formats.

Fix:
To strictly follow Skatteetaten validation rules for the Norway VAT XML, the
following changes were implemented:
- Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted 
  fractional rates like `11.11` to `11,11` in XML.
- Rounded down the `tax_amount` to align precisely with government mathematical
  expectations.
- `base_amount` converted into absolute value to ensuring the calculation
  (`base * rate = tax`) resolves perfectly.
- Add the mandatory `<merknad>` explaining the reverse charge method for codes
  81, 83, 86, 88, and 91.
- Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix.

Expect:
The generated XML payload now adheres perfectly to Skatteetaten's strict
structural and mathematical rules, allowing the VAT return to pass government
validations successfully.

Related Community PR: https://github.com/odoo/odoo/pull/258390

Task-6033027

#vat#norway#tax#compliance

[FIX] web_grid: enable top part of grid view on mobile

PR #113400

Enterprise17.0web_gridMEDIUM

This update resolves an issue where the 'Add a line' button was unresponsive on the initial view of mobile grid views. The fix adjusts how elements are positioned to ensure consistent button functionality across all rows, regardless of scrolling position. This improves the user experience for mobile users.

Original PR description

**Steps to reproduce**
On mobile:
- Open a grid view (e.g. Timesheets > All timesheets)
- Try to click on "Add a line" for the first employee
- Issue: nothing happens. Notice that by scrolling down the list to employees at the bottom, it becomes possible to click on "Add a line".

**Cause**
`o_grid_cell_overlay` elements (with `h-100`) were taking more than the expected height in mobile, because the `o_grid_section_title` divs only have `position: sticky` on larger viewports. With the default `position: static`, the child element's height was exceeding its parent's height.

opw-5853489

#mobile#grid view#UI

[FIX] website_sale: Fix dynamically variant creation

PR #256127

Core17.0website_saleMEDIUM

This update resolves an issue where product variants were automatically created when viewing products on the eCommerce site. The change ensures variants are only generated when a Sales Order is placed, aligning with the intended Dynamically attribute behavior. This improves the user experience and prevents unnecessary variant creation.

Original PR description

For now, when a product is created with a Dynamically attribute, a variant is automatically created when viewing the product on the eCommerce site. However, the Dynamically behavior is supposed to create a variant only when a Sales Order (SO) is created.

This PR fixes the issue by preventing the variant from being created when simply viewing the product on the eCommerce site.

opw-6060733

#ecommerce#variants#dynamically

[FIX] mrp_account: filter kit component lines for reconciliation

PR #258013

Core17.0stock_accountmrp_accountsalepurchaseMEDIUM

This update resolves a bug that prevented accurate reconciliation of inventory items when selling kits containing components. The issue stemmed from how valuation layers were handled, leading to repeated reconciliation attempts. This ensures correct accounting and reporting for products sold as kits.

Original PR description

Steps to reproduce
-----
- Modules: Sale, Purchase, Mrp, Accounting
- Enable automatic accounting & anglo-saxon valuation
- Create an AVCO Product category (AVCO automatic valuation)
- Create a Kit product storable & AVCO
    - Kit bom
    - Comp as a component (storable & AVCO)
- Settings > Decimal Accuracy > Product Price > set to 4 digits
- Purchase 3 units of Comp at 3.3333 piece & validate reception
- Make 2 sales for 1 unit of Comp each & validate both deliveries
- Create a SO for 1 Kit and 1 Comp & confirm
- Create & confirm invoice
- Go to the delivery, force quantity on the component and try to validate delivery

> Error message: "You are trying to reconcile some entries that are already reconciled."

/!\ Fun(?) fact: this error doesn't occur if the order of the moves is inverted.

Cause
-----
When the purchase delivery is validated, a stock valuation layer is created for 3 units with a value of 10. As they are sold individually, these 3 units generate a valuation layer for 3.33 per unit summing to 9.99.

When we validate the last delivery, the 0.01 difference is detected and an adjustment is made on the valuation layer in `_prepare_out_svl_vals`.

However this adjustment is made for the product when the invoice line concerns the kit. As a result, the first reconciliation fails and the line is added to the list to be reconciled later.

Then, when handling the line for COMP2, it will successfully reconcile the lines while it is still in the pool to be reconciled, resulting in an error when attempting to reconcile it later.

This is caused by `_stock_account_anglo_saxon_reconcile_valuation` where the `product_stock_moves` only contains the kit move when called with the kit product as argument, but it contains both moves when called with the component itself as argument. This leads to the same AML being reconciled twice.

https://github.com/odoo/odoo/blob/f0b9f4c234cd0101f5cb259e58620e1cf65bb2b7/addons/stock_account/models/account_move.py#L222-L225

-----
Ticket:
opw-5722072

#inventory#accounting#kit#reconciliation

Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal notes, and invalid KID number formats. Fix: To strictly follow Skatteetaten validation rules for the Norway VAT XML, the following changes were implemented: - Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted fractional rates like `11.11` to `11,11` in XML. - Rounded down the `tax_amount` to align precisely with government mathematical expectations. - `base_amount` converted into absolute value to ensuring the calculation (`base * rate = tax`) resolves perfectly. - Add the mandatory `<merknad>` explaining the reverse charge method for codes 81, 83, 86, 88, and 91. - Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix. Expect: The generated XML payload now adheres perfectly to Skatteetaten's strict structural and mathematical rules, allowing the VAT return to pass government validations successfully. Related Community PR: https://github.com/odoo/odoo/pull/258390 Task-6033027

**Steps to reproduce** On mobile: - Open a grid view (e.g. Timesheets > All timesheets) - Try to click on "Add a line" for the first employee - Issue: nothing happens. Notice that by scrolling down the list to employees at the bottom, it becomes possible to click on "Add a line". **Cause** `o_grid_cell_overlay` elements (with `h-100`) were taking more than the expected height in mobile, because the `o_grid_section_title` divs only have `position: sticky` on larger viewports. With the default `position: static`, the child element's height was exceeding its parent's height. opw-5853489

For now, when a product is created with a Dynamically attribute, a variant is automatically created when viewing the product on the eCommerce site. However, the Dynamically behavior is supposed to create a variant only when a Sales Order (SO) is created. This PR fixes the issue by preventing the variant from being created when simply viewing the product on the eCommerce site. opw-6060733

Steps to reproduce ----- - Modules: Sale, Purchase, Mrp, Accounting - Enable automatic accounting & anglo-saxon valuation - Create an AVCO Product category (AVCO automatic valuation) - Create a Kit product storable & AVCO - Kit bom - Comp as a component (storable & AVCO) - Settings > Decimal Accuracy > Product Price > set to 4 digits - Purchase 3 units of Comp at 3.3333 piece & validate reception - Make 2 sales for 1 unit of Comp each & validate both deliveries - Create a SO for 1 Kit and 1 Comp & confirm - Create & confirm invoice - Go to the delivery, force quantity on the component and try to validate delivery > Error message: "You are trying to reconcile some entries that are already reconciled." /!\ Fun(?) fact: this error doesn't occur if the order of the moves is inverted. Cause ----- When the purchase delivery is validated, a stock valuation layer is created for 3 units with a value of 10. As they are sold individually, these 3 units generate a valuation layer for 3.33 per unit summing to 9.99. When we validate the last delivery, the 0.01 difference is detected and an adjustment is made on the valuation layer in `_prepare_out_svl_vals`. However this adjustment is made for the product when the invoice line concerns the kit. As a result, the first reconciliation fails and the line is added to the list to be reconciled later. Then, when handling the line for COMP2, it will successfully reconcile the lines while it is still in the pool to be reconciled, resulting in an error when attempting to reconcile it later. This is caused by `_stock_account_anglo_saxon_reconcile_valuation` where the `product_stock_moves` only contains the kit move when called with the kit product as argument, but it contains both moves when called with the component itself as argument. This leads to the same AML being reconciled twice. https://github.com/odoo/odoo/blob/f0b9f4c234cd0101f5cb259e58620e1cf65bb2b7/addons/stock_account/models/account_move.py#L222-L225 ----- Ticket: opw-5722072