Daily updates from Odoo
Wednesday, June 24, 2026
25 changes · 18.0
New functionality added to Odoo
This update allows us to automatically receive vendor bills from Hungary's tax authority (NAV) via API. A new 'Sync with NAV' button lets you select a time period and fetch bills, or you can directly upload NAV-compatible XML files for import. This streamlines invoice processing and ensures accurate record-keeping.
Original PR description
In Hungary, we are already sending invoices to NAV(hungarian tax authority). Now this module `l10n_hu_edi_receive` provides functionality of receiving vendor bills through its API and also adds XML…
In Hungary, we are already sending invoices to NAV(hungarian tax authority). Now this module `l10n_hu_edi_receive` provides functionality of receiving vendor bills through its API and also adds XML importer for Hungarian localization. A button `Sync with NAV` is added in vendor bills list view, which opens a wizard where you can select time period and all bills uploaded between that time are fetched from NAV's API. Also directly uploading XML is also supported in the format NAV supports. Flow:- - After selection of time range, we call `queryInvoiceDigest` endpoint with that range and it returns a list of digests(consider each digest as separate invoice) but this digests contains only meta data not all details. - Now for each digest we call `queryInvoiceData` endpoint which returns xml response with `QueryInvoiceDataResponse` as root node. This xml contains some meta data and `InvoiceData` node which has a base64 string, when we decode that string we get an xml with `InvoiceData` as root node and this xml contains all details of the invoice, we parse both these details and create bills and refunds. Also xml importer supports any of the `InvoiceData` or `QueryInvoiceDataResponse` xml. NAV Documentation: https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf task-5237910
Resolved issues and error corrections
This update resolves an issue where a specific tax field was incorrectly appearing in Odoo instances not using the ID (Belarus) localization. The PR hides this field when it's not relevant to an ID company, ensuring data accuracy and a cleaner user experience. This prevents incorrect data from being displayed and simplifies the system for users.
Original PR description
Description of the issue/feature this PR addresses: this field pollutes into non-ID companies <img width="1905" height="810" alt="image" src="https://github.com/user-attachments/assets/65d80e78-addc-42d8-887f-67c1245b83dc" /> This PR hides it if it's not. --- I will check if other fields in this module also have similar issue
This update resolves an issue where newly uploaded documents related to vendor bills would disappear from the system after upload. Previously, the system failed to correctly link these documents to the associated vendor bill, causing data inconsistencies. This fix ensures documents are properly linked, improving data accuracy and usability.
Original PR description
**PROBLEM** There is missing values in the context of the document view of account.move, which means when you upload a new document, it's not linked to the account.move. **STEP TO REPRODUCE** 1. Go to the document app, and upload an invoice document (ubl, zugferd, something that can be imported to create a vendor bill). 2. Select the document and click on "Create Vendor Bill". 3. Go to Accounting/Vendors/Bills, and go on the created vendor bill. 4. Click on the "Documents" smart button. 5. Try uploading a new document from this view. 6. In 18.+, the document is uploaded, and then disappears from the view. In 19.+, there is a traceback. opw-6233400
This update adds a QR code and KSeF number to PDF invoices generated for Polish companies when sending invoices online for KSeF processing. This ensures compliance with Polish tax regulations and simplifies the invoice submission process for users. The QR code contains the necessary information for KSeF to validate the invoice.
Original PR description
Issue: While communicating outside KSeF, invoices should have a QR Code and their KSeF number displayed Steps to reproduce: - from a Polish company - invoice a customer - Confirm the invoice - send it to KSeF - once it is accepted - Print PDF Expected behavior: Invoice should have a QR Code and their KSeF number QR Code content spec is available here: https://github.com/CIRFMF/ksef-api/blob/main/kody-qr.md or from https://ksef.podatki.gov.pl/ksef-na-okres-obligatoryjny/wsparcie-dla-integratorow/ then "KSeF 2.0 przewodnik dla integratorów" opw-6211058
A recent test was failing due to a missing time zone setting in the testing environment. This update adds a fallback mechanism to ensure correct time zone handling, preventing the test failure. This resolves a technical issue impacting automated testing.
Original PR description
Currently the test test_holiday_in_week is failing in runbot tests This is due to the fact that during the tests the user tz in env is not set and hence it fails in the pytz library. Added a fallback to avoid the issue runbot issue opw-237623 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug in the Italian e-invoice system (l10n_it_edi) that was causing invoices to be rejected by the SDI due to lowercase 'Codice Fiscale' entries. The fix ensures the field always accepts uppercase input and improves the user experience by automatically capitalizing the text entered.
Original PR description
### Steps to reproduce: - Install "l10n_it_edi_website_sale" and switch to Italian company - Configure the website for this company - Open the website as customer - Add something to the cart, go up to delivery - There the field "Codice Fiscale" can be lowercase - When entering something lowercase here, the invoice is then rejected by SDI. - Same for "Destination Code (SDI)" ### Cause: The SDI requires the field to be uppercase. ### Solution: Change `_l10n_it_edi_normalized_codice_fiscale` to return the uppercase value. (Already the case for "Destination Code (SDI)") Add `text-uppercase` on the input so the text entered there is always capital (better for the user). opw-4655364
This update fixes an issue where Danish expense reports were incorrectly calculating taxes. Specifically, when using the 'K-EU-V-DelvisFradrag' tax, the journal entries were showing an incorrect tax amount. The change ensures that taxes with negative repartition values are handled correctly, aligning with previous Odoo versions.
Original PR description
### Steps to reproduce: - Install "l10n_dk" and switch to Danish company - Create an empty sale order - Create a new expense - Category "Communication" for example - Total of 100 for example - Select…
### Steps to reproduce: - Install "l10n_dk" and switch to Danish company - Create an empty sale order - Create a new expense - Category "Communication" for example - Total of 100 for example - Select "K-EU-V-DelvisFradrag" as a tax - Paid by company - Select the customer to reinvoice - Click "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" - Go to the Journal Entry and see the Journal Items - The tax is a 25% tax but the value in the journal entries is 20 (so 20%) ### Cause: When called from the Expense app `_get_tax_details` is called with `special_mode == total_included` ([see](https://github.com/odoo/odoo/blob/467ab37703a44ca6cf57552715b75b087dc77d0d/addons/hr_expense/models/hr_expense.py#L549)). The special mode makes all taxes computed as if they were included taxes. But taxes with negative lines should not be computed as included (as in 17.0). The code already handles that the base amount is not changed for these taxes ([see](https://github.com/odoo/odoo/blob/467ab37703a44ca6cf57552715b75b087dc77d0d/addons/account/models/account_tax.py#L1088-L1092)). But not the amount of the tax in question. ### Solution: In `_eval_tax_amount_price_included`, if the tax has `has_negative_factor` to `True` then compute the tax as excluded. opw-4532391
This pull request contains a simple test change to ensure the runbot is functioning correctly. The change involves a basic 'test' commit to verify the automated testing process. This is a low-risk update to maintain the stability of the Odoo build environment.
Original PR description
Just to test the runbot
This update resolves a technical issue that was causing performance problems when calculating accounting entries for French PDP (Point of Delivery) transactions. By removing unnecessary dependencies on company and partner information, the system now computes these entries more efficiently and reliably. This improves the overall stability and performance of the French PDP module.
Original PR description
- This removes dependency on account move fields to company : Build error 939448 - This removes dependency on account move fields to commercial_partner_id fields (avoid recompute all moves on partner info change)
This update resolves a performance issue in the HTML editor that occurred when handling complex content. The fix prevents a 'Maximum call stack size exceeded' error by efficiently processing large numbers of elements, resulting in faster page loading times. This enhancement ensures a smoother user experience when working with extensive HTML content.
Original PR description
For complex content, descendants(root) can return more than 100K elements. Using the spread operator expands all descendants into individual function arguments, which may exceed the JavaScript's argument limit and trigger a "Maximum call stack size exceeded" error. Replace with push() each node to the targetNodes. ||Before|After| |-|-|-| |getTargetNodes|Page Unresponsive|585 ms| Related ticket: opw-6303814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where work order durations were inaccurately calculated due to overlapping time entries. By filtering and merging productive and performance time, the system now provides a more precise duration for valuation purposes. Additionally, a fix was implemented to prevent timestamp issues during testing, ensuring accurate duration calculations.
Original PR description
[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf) and deduplicating overlaps * Current…
[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf) and deduplicating overlaps * Current Situation: Currently real duration is total duration of each time tracking which is not consistent with the time that use to calculate the cost for valuation , see https://github.com/odoo/odoo/pull/205154 .The real duration of a work order was incorrectly summing all time tracking entries regardless of their loss type, and using simple addition which double-counts overlapping intervals. * Solution: - Filter time entries to only 'productive' and 'performance' loss types, excluding 'availability' and 'quality' as they represent downtime/blocking time, not actual work duration. - Pool all productive and performance entries into a single Intervals call so that overlaps across both types are merged in one pass. Note: the enterprise17 implementation groups time entries by loss_type into separate buckets before calling Intervals, which means overlaps between 'productive' and 'performance' entries are not merged and get double-counted. Pooling both types together before the Intervals call avoids this. * This also fix: - Fix _set_duration to ensure newly created time entries start after the latest existing entry's end date. Without this, calling _set_duration twice in quick succession (e.g. in tests) produces two entries with overlapping timestamps, which Intervals correctly merges into one, causing the computed duration to be half the expected value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248381
This update resolves an issue where vendor bills auto-completed from purchase orders would sometimes create incorrect invoice line data, including mismatched tax information. The change ensures that invoice line data is consistently updated after auto-completion, maintaining accurate records between invoices and journal entries. This improves data integrity and reduces potential accounting errors.
Original PR description
When a vendor bill is imported and auto-completed from a purchase order, then invoice lines, taxes, fiscal position, and payment terms can change. Existing EPD dynamic lines that lose their epd_key are skipped by sync and keep stale tax tags and amounts, causing mismatches between Invoice Lines and Journal Items. This commit makes EPD sync include keyless existing EPD lines so they are rewritten or removed during dynamic recomputation after PO auto-complete. Journal items remain consistent with the final invoice lines, taxes, and early discount configuration. Ticket [link](https://www.odoo.com/odoo/project.task/6047505) opw-6047505 Forward-Port-Of: odoo/odoo#265539
This update fixes an error in the German accounting template (skr03) that was using incorrect account codes for cash discounts. The template has been updated with the correct codes, ensuring accurate financial reporting for German businesses using Odoo. This ensures compliance and proper accounting practices.
Original PR description
The default cash discout accounts referenced in the
German skr03 template used the wrong account codes.
The template has been updated with the right ones.
task-4915939
opw-4909059
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#271024This update fixes an error in the German (skr03) report template, ensuring it uses the correct account codes for cash discounts. This ensures accurate financial reporting and compliance for our German customers. The change was driven by a task and an operational priority.
Original PR description
The default cash discount accounts referenced in the German skr03 template used the wrong account codes. The template has been updated with the right ones. task-4915939 opw-4909059 Forward-Port-Of: odoo/enterprise#121180
This update corrects an issue where resetting bank entries could incorrectly flag e-reporting statuses as 'False'. The change ensures the status is accurately determined before being displayed, improving the reliability of reporting data. This resolves a potential discrepancy in e-reporting status calculations.
Original PR description
Resetting an out-of-scope bank entry to draft can recompute the e-reporting status to False. Skip that value before resolving the status label for the chatter message.
This update resolves a bug where the cursor would incorrectly snap to the end of a `<t>` block when deleting text within email templates. By removing `<t>` from a list of self-closing tags, the editor now correctly handles cursor placement, ensuring a smoother editing experience for users creating and modifying email templates.
Original PR description
## Problem:
`<t>` elements are classified as self-closing, even if they aren't used that way in a mail template. If you press backspace in the editor on some plain text that happens to be inside a `<t></t>` block, the editor would prevent the cursor from being placed back inside the block after merging because of `normalizeSelfClosingElement`. The result is the cursor being left on the outside edge of the block.
## Solution:
We will remove "T" from the list of self-closing tags.
## Steps to replicate (runbot v18):
1. Open an email template (Purchase: Purchase Order)
2. Place your cursor in some text inside a t-if element ('The receipt is expected for...'). Press backspace. Your cursor will snap to the end of the t-if block.
opw-6124284This update resolves an issue where property labels weren't appearing correctly after adding properties to a record. The fix ensures that the system waits for the update to complete before displaying the property labels, preventing a technical error. This improves the user experience when managing properties within Odoo.
Original PR description
Description of the issue/feature this PR addresses: This error occurs when a model has properties and a `computed` field or `onchange` method depends on them. `record.update()` is asynchronous. When…
Description of the issue/feature this PR addresses: This error occurs when a model has properties and a `computed` field or `onchange` method depends on them. `record.update()` is asynchronous. When an onchange or computed field is triggered, an additional request is sent to the server, increasing the time required to complete the update. See: https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/model/relational_model/record.js#L1207-L1211 However, `PropertiesField` is rendered before the `update` is completed. See: https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/views/fields/properties/properties_field.js#L86 As a result, the property labels are not yet available and the following traceback is raised: `TypeError: Cannot read properties of undefined (reading 'getRootNode') ` After this commit, the update is awaited before rendering PropertiesField, ensuring that the property labels are available. **Steps to reproduce:** 1. Install the example module. [project_task_property.zip](https://github.com/user-attachments/files/29138424/project_task_property.zip) 2. Open or create a project task. 3. From the Action menu, click `Add Properties`. The error is raised. <img width="1520" height="956" alt="image" src="https://github.com/user-attachments/assets/a3051ddf-5af0-4d3a-8ff7-c3fb4f7a69d2" /> TT63331 @Tecnativa @pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'undo' function in the planning module didn't correctly maintain allocated hours. The fix creates the necessary planning role directly within the test environment, ensuring a consistent and reliable undo operation. This prevents data inconsistencies and improves the accuracy of planning schedules.
Original PR description
Fix by creating the planning role directly within the test, making it self-contained. runbot error-939985
This update fixes an issue where URL autocomplete suggestions overflowed on mobile devices, creating a poor user experience. The fix adjusts the container's width to dynamically adapt to smaller screens, ensuring suggestions fit neatly within the viewport. This enhances usability for all users.
Original PR description
Step to reproduce: - Open Notes - Open the link popover - Type a URL in the URL input field Description of the issue/: - On mobile devices, URL autocomplete suggestions overflow the viewport. Cause: - The autocomplete suggestions container has a max-width of 600px. - On smaller screens, the container does not shrink to fit the available width, causing it to overflow the viewport. Solution: - Add width: 100% to the autocomplete suggestions container so it adapts to the available screen width on smaller devices while still respecting the existing max-width on larger screens. task-6201175
This update corrects a bug in the payroll system's attachment code matching process. The original code incorrectly used the 'in' operator, leading to unintended matches. Switching to '==' ensures accurate matching of attachment codes, preventing potential payroll errors.
Original PR description
Currently we have for deduction_codes, attachments in slip.salary_attachment_ids.grouped( lambda x: x.other_input_type_id.code ) salary_lines = slip.line_ids.filtered( lambda r: r.code in deduction_codes ) I believe the intent in the second line is to check either r.code is in deduction_codes. This assumes deduction codes is an array. the issue is that it is not an array. The return of "grouped" on the first line implies that deduction_code will always have a string that describe which is the deduction_code, and attachment_ids will be an array Now the bug happens on the comparison "in" on the second line. Since we are matching against a string, suposing we had 2 codes like TEST_CODE and TEST, both would match positively using "in" changing "in" to "==" will ensure we match codes properly opw-6206134
This update fixes a visual inconsistency within the Odoo application. The flag image for Mauritania was incorrectly displayed. This change ensures accurate representation of countries within the system, improving the overall user experience.
Original PR description
[task-6320443](https://www.odoo.com/odoo/project.task/6320443) Forward-Port-Of: odoo/odoo#271488
This update fixes a performance issue within the Odoo gevent server by proactively loading database registries. Previously, the server wasn't properly configuring these registries, leading to slower startup times. This change ensures the server is optimized for speed and efficiency.
Original PR description
The code to set the registry size was moved to `preload_registries`. The gevent server does not preload registries and thus does not set the registries size. Instead of moving the code again, we can preload registries in the gevent server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271640
This update fixes a potential issue where private tasks could be incorrectly set as parents for other tasks. This change ensures tasks remain properly organized and prevents confusion for users managing project workflows. It's a routine maintenance update to improve task management clarity.
Original PR description
In this commit, we ensure that private tasks can never be selected as parent tasks. task-5119141 Forward-Port-Of: odoo/odoo#270795
This pull request reverses a recent update that removed standard views and fields from the l10n_fr_pdp module. This change was causing issues with upgrades and is being reverted to ensure continued compatibility and stability. A subsequent update will reintroduce the cleanup with inactive views and fields.
Original PR description
Revert commit 75aff8b7bea3 ([IMP] l10n_fr_pdp: move e-reporting details to chatter). The cleanup removed standard views and fields in stable, which is not upgrade-safe and breaks forward-port upgrade checks. A follow-up PR will reintroduce the cleanup while keeping the obsolete views and fields available but inactive.
This update corrects an issue where the ICS file generated for events didn't reflect the language currently selected on the website. Previously, it always used the backend language, causing confusion for users. This change ensures the ICS description aligns with the frontend language, matching expected behavior and Google Calendar integration.
Original PR description
Steps to reproduce: - Make sure you have 2 or more languages installed - Install events and website app - For the website, apply the languages you have in settings. Make sure the default language is…
Steps to reproduce: - Make sure you have 2 or more languages installed - Install events and website app - For the website, apply the languages you have in settings. Make sure the default language is different from the chosen backend language - Create an event - Go to the event's website page through the smart button - Switch the language of the frontend to one that is different from the backend - Translate (alter) the description for this language - Click on the outlook icon to download the ics Current Behavior: The ics will contain a description based on the backend's chosen language Expected Behavior: The ics will contain a description based on the website's chosen language at the time Clarification: The current behavior is confusing for users as they will expect the ics to match the description of the current webpage which is dependent on the frontend's selected language. This current behavior also contradicts the google calendar behavior which grabs the description based on the frontend's selected language. Also in Odoo 19+, this leads to a "bug" where if a user has a selected backend language that's not present in the website, then the ics will always contain the default description since the language is not present on the website. The only way to circumvent this bug would be to add the language to the website which shouldn't need to happen opw-6235320