Wednesday, June 24, 2026
11 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 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
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 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 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 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 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.