Friday, March 13, 2026
14 changes · 18.0
New functionality added to Odoo
This update enables Danish companies to automatically generate official FIK payment references when creating customer invoices. Users simply configure their bank's FIK creditor number in the sales journal, ensuring compliant Danish payments without disrupting existing workflows. This improves financial reporting accuracy and simplifies payment processes for Danish clients.
Original PR description
Before: - Danish companies had to rely on manual or non-standard payment communication on invoices. - They could not generate official FIK payment references. After: - Sales journals can now generate Danish FIK payment references automatically. - Users configure an 8-digit bank-issued FIK creditor number on sales journal. Impact: - Enables compliant Danish FIK payments without changing user workflows. Related PR: https://github.com/odoo/enterprise/pull/102612 taskID-5401553 Forward-Port-Of: odoo/odoo#240829
Resolved issues and error corrections
This update resolves an issue preventing Argentinian companies with 'IVA Sujeto Exento' (VAT exempt) status from creating 'Export Invoices'. The fix ensures that these companies can properly generate export invoices, aligning with AFIP regulations and improving business functionality. This change corrects a restriction that shouldn't have been in place.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Create a Argentinian company with "AFIP Responsibility Type" set to "IVA Sujeto Exento" (VAT exempt) - Switch to the created company - In Accounting settings, set up "AFIP Web Services" - Create a journal for export invoices - Create a customer with "AFIP Responsibility Type" set to "Cliente del Exterior" - Create an invoice - Select the created customer - Try to set the document type for export invoices **Issue:** It is not possible to select "(19) EXPORT INVOICES" as "Document Type" for companies having "AFIP Responsibility Type" set to "IVA Sujeto Exento". It is not because the company is "VAT exempt" that it should not be able to create an export invoice. opw-5974268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252232
This update corrects a naming issue with the ZUGFeRD e-invoice XML file, ensuring compatibility with various validation tools. Previously, the incorrect filename caused validation errors. Now, the file passes validation across multiple recognized e-invoice validators, improving the accuracy of invoice processing.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252681
This update fixes an issue where taxes weren't being assigned correctly to the right companies within Point of Sale sessions. The change ensures that taxes are sorted by company ID before grouping, preventing taxes from the same company from being split into multiple groups and ensuring accurate tax calculations.
Original PR description
itertools.groupby only groups consecutive elements. When taxes from different companies are interleaved in loaded_data, taxes from the same company get split into multiple groups, causing incorrect tax assignment per company. Sort the tax list by company_id before calling groupby to ensure all taxes per company are contiguous. opw-5931261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252954
This update resolves an issue where validating a delivery record would fail if the associated sale order was created without any order lines. The fix ensures a default sequence value of zero is used in these scenarios, preventing the 'max() arg is an empty sequence' error and allowing deliveries to be successfully validated. This improves the reliability of the sales order fulfillment process.
Original PR description
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and…
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and `confirm` it. - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`. - In the `Additional tab`, select the `sale order (the one without order lines)`. - Now `validate` this delivery. **Error:** `ValueError: max() arg is an empty sequence` This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error. This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used. [1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164 sentry-7089149997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where loyalty programs weren't accurately tracking points when the pricelist feature was disabled. Previously, the system retained old pricelist configurations, leading to incorrect point accumulation. This fix ensures loyalty programs function correctly regardless of whether pricelists are enabled.
Original PR description
When `use_pricelist` is disabled, `available_pricelist_ids` retains previously configured pricelists. This caused loyalty programs restricted to a specific pricelist to still match and accumulate points incorrectly. opw-5952960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves issues with invoice processing for Vietnamese VAT submissions, specifically addressing problems with global discounts, down payments, and the inclusion of note lines. By correctly handling negative values and enabling note line uploads, this change ensures accurate and compliant VAT filings, improving the reliability of our Vietnamese accounting functionality.
Original PR description
Previously, the invoice logic did not properly handle the following scenarios: - Global discount: when a global discount was applied, negative values were sent to Sinvoice, resulting in a BAD_REQUEST_ITEM_VALUES_NEGATIVE error. - Down payment: when an invoice included a down payment to deduct the amount, negative values were sent to Sinvoice, triggering the same BAD_REQUEST_ITEM_VALUES_NEGATIVE error. - Note lines: note lines on the invoice were not being uploaded/included in the invoice submission. This commit fixes the handling of global discounts and down payments by ensuring negative values are properly transformed before being sent to Sinvoice, and adds support for uploading note lines in the invoice. task-5875158
This update corrects a bug that occurred when attempting to unbuild more product than was initially manufactured. Specifically, it resolves a situation where stock moves became invalid due to a mismatch in quantities. The fix ensures accurate handling of over-unbuilding scenarios, preventing stock discrepancies and validation errors.
Original PR description
# How to reproduce - Create a BOM for a product - Create a MO for a set quantity (Exemple: 1) for that product - Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3) -…
# How to reproduce - Create a BOM for a product - Create a MO for a set quantity (Exemple: 1) for that product - Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3) - Confirm the unbuild - Go to the stock moves of that unbuild via the smart button # The problem 3 stock move lines are created, 2 in the 'Done' state and 1 in the 'Available' state. This last move line is stuck and cannot be validated # Why The cause of this issue is due to a discrepency between the quantity set for the move lines and the quantity set for their respective moves. When creating the move lines for the produce move, we use the original move of the MO (this is done to keep Lots consistent). If the quantity of product to unbuild is more than the quantity of product built by the MO, the quantity of the move lines will be less than expected. This will then create a backorder when the produce move is set to done. This backorder will then be unvalidatable because the unbuild it is linked to will be set to 'Done'. opw-5915981 opw-5449109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a performance issue where replacing background images could cause the website to hang. The fix replaces a fragile regex-based approach with a more efficient method using CSSOM to remove transform styles, resulting in faster image loading and a smoother user experience. This improves website responsiveness and stability.
Original PR description
__Before commit__ Transform-related CSS properties are removed from an image element by manipulating the raw `style` attribute string with a regex which is fragile and costly in performance. __Steps to reproduce (saas-19.2)__ This regex was added in [18.0][1] but is only a real issue since `resetImageTransformation` was called in `on_will_save_media_dialog_handlers` in [saas-19.2][2]: 1. Add a section block. 2. Add a background image. 3. Open the media dialog and replace the background image. => The website will hang for a while. __Fix:__ Use `.style.removeProperty()` instead to speed up the process and to make it less error prone. [1]: https://github.com/odoo/odoo/commit/85698bf4f591fc9280f054b9a255a7d [2]: https://github.com/odoo/odoo/commit/781c0ae77de01f0df8667e0191f6c34
This update ensures that Danish SEPA payments are correctly formatted with the required FIK reference, resolving an issue where the payment XML was missing this crucial detail. The change also modernizes the XML generation process for better future support of country-specific payment reference formats.
Original PR description
Issue: - A related PR introduced Danish FIK payment references on customer invoices. - The generated SEPA payment XML did not include this reference, resulting in missing structured communication for Danish payments. IMP: - Extended the SEPA payment XML generation to include the Danish FIK reference when present. - Refactored the structured reference XML builder to use lxml elements instead of string-based XML construction, ensuring proper escaping of structured references. Impact: - Ensures compliant Danish SEPA payments with correct FIK references. - Makes SEPA XML generation future-proof for country-specific structured references containing non-numeric characters. Related PR: https://github.com/odoo/odoo/pull/240829 Task: 5401553 Forward-Port-Of: odoo/enterprise#102612
This update resolves an issue where rental income was incorrectly included in the Total Income batch calculation for Hong Kong payroll. The change removes these rental amounts, ensuring more accurate income reporting as required by Hong Kong tax regulations. This update improves the reliability of payroll data.
Original PR description
. Removing any rental amounts in calculating Total Income batch task-6006636
This update ensures that follow-up emails sent with invoices always include the correct invoice PDF, regardless of whether a user uploaded other attachments. Previously, emails used the main attachment, which could be unreliable. This change guarantees accurate invoice PDFs are sent, improving the reliability of automated reminders.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420
This update corrects a potential issue in the GSTR reporting module, ensuring that tax calculations are accurate. Previously, the system incorrectly applied taxes to bills even when a bill wasn't initially available, leading to inaccurate reports. Now, the system only checks for taxes on bills that have been fully processed and marked as 'posted'.
Original PR description
if bill is not available then we also create new bill without line so we check taxes only on posted one Forward-Port-Of: odoo/enterprise#110461
This update corrects an issue where incorrect folio numbering occurred when Chilean VAT (l10n_cl_edi) reports didn't have a configured CAF (Common Fiscal Area). The fix ensures that folios are generated correctly, preventing errors and maintaining accurate accounting sequences. This improves the reliability of VAT reporting.
Original PR description
`l10n_cl_edi` overrides `account.move._get_last_sequence()` to ensure the folio belongs to an available in-use CAF. When no CAF exists at all, `l10n_latam.document.type._get_start_number()` returns 0 and the fallback builds a previous sequence using start_nb - 1. Formatting -1 as `:06d` yields “-00001”, which then propagates to “FAC -00002”, “-00003” and corrupts the sequence chain. In addition, returning an invalid “last sequence” may force `sequence.mixin` to search for a free number under the UNIQUE constraint by retrying increments inside a savepoint and rolling back on UniqueViolation, which is costly when many values are already taken see [ _locked_increment()](https://github.com/odoo/odoo/blob/18.0/addons/account/models/sequence_mixin.py#L352). Now we only reset to the CAF start when an in-use CAF actually exists (start_nb > 0). opw-5918758