Odoo Changelog — 2025-03-17

Monday, March 17, 2025

3 changes · 18.0

Improvements(3)

Enhancements to existing features

[PERF] point_of_sale: backport loading perf

PR #201879

Core18.0point_of_saleMedium

This update improves how Point of Sale data loads when opening sessions. It helps reduce slow startup times that were blocking a customer upgrade, making cashier workflows more responsive.

Original PR description

18.0 backport of odoo/odoo#198123

We need the fix in 18.0 because a customer's upgrade is blocked
because of slow loading speed of point of sale sessions.

opw-4582980

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

#performance#point of sale#loading

[IMP] l10n_nl_reports: allow defining custom start dates for the tax closings in the Netherlands

PR #81324

Enterprise18.0l10n_nl_reportsMedium

Dutch tax reporting settings now allow businesses to define custom start dates for tax closings. This gives companies more flexibility to align VAT or tax closing periods with their specific reporting needs.

Original PR description

opw-4592126

#netherlands#tax reporting#configuration

[IMP] account_reports: Properly handle groupby made on non-stored related fields in custom engines

PR #81495

Enterprise18.0account_intrastataccount_reportsl10n_be_reportsl10n_cz_reports_2025l10n_ee_reportsl10n_es_reportsMedium

Custom financial report engines now handle grouping by related account fields in the same way as standard reports. This makes consolidation report setup more flexible, especially when multiple source-company accounts share the same code, and adds automated coverage to catch similar issues earlier.

Original PR description

Since odoo/enterprise@a94227b, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of…

Since odoo/enterprise@a94227b, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to the same code, without having to ensure a 1 to 1 relationship between the accounts of the source and consolidating company.

This, however, was only implemented for standard engines. Custom engines were not modified, and none of them did the proper call to _fields_to_sql, to ensure the join condition of the query is adapted to run this grouping. This commit adds it, together with a test ensuring the custom engines are all evaluated on runbot with a non-stored custom groupby, so that errors are spotted directly and the developers just don't have to remember this "by heart".

task-4596355

18.0 backport of odoo/odoo#198123 We need the fix in 18.0 because a customer's upgrade is blocked because of slow loading speed of point of sale sessions. opw-4582980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Since odoo/enterprise@a94227b, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to the same code, without having to ensure a 1 to 1 relationship between the accounts of the source and consolidating company. This, however, was only implemented for standard engines. Custom engines were not modified, and none of them did the proper call to _fields_to_sql, to ensure the join condition of the query is adapted to run this grouping. This commit adds it, together with a test ensuring the custom engines are all evaluated on runbot with a non-stored custom groupby, so that errors are spotted directly and the developers just don't have to remember this "by heart". task-4596355