Thursday, March 5, 2026
8 changes · 17.0
Enhancements to existing features
This update enhances Odoo's ability to handle taxes in UBL and CII EDI formats by introducing an 'allowance/charge' mechanism. Previously, tax handling was limited, now businesses can accurately represent complex fiscal scenarios like discounts and charges. Comprehensive testing ensures correct export and import of invoices with these new tax configurations.
Original PR description
This **PR** introduces support for the Allowance/Charge mechanism in UBL and CII EDI formats. Previously, allowance and charge handling was static and implicit: fixed taxes were always exported as…
This **PR** introduces support for the Allowance/Charge mechanism in UBL and CII EDI formats. Previously, allowance and charge handling was static and implicit: fixed taxes were always exported as charges with code AEO, while line discounts were exported as allowances with code 95, which did not allow correct modeling of many real-world fiscal scenarios. A new configuration is added on the tax form to explicitly define whether a tax is treated as a regular tax or as an allowance/charge. When marked as an allowance/charge, the corresponding code and reason can be defined. The sign of the amount determines the semantic: negative values are treated as allowances, while positive values are treated as charges. When applied on invoices, such taxes are exported as AllowanceCharge elements in UBL and CII for EDI purposes. Support is also added for importing invoices containing such allowance/charge entries. Additionally, test cases are added to validate correct behavior across export and import flows, including scenarios combining standard taxes with allowance/charge entries. **task**-5424216
Resolved issues and error corrections
This update ensures that e-invoices generated for Malaysian customers (credit notes, debit notes, refunds) accurately reflect MyInvois API requirements. Specifically, the 'prepaid amount' is now correctly set to zero for relevant document types, and the 'payable amount' is updated to the full invoice total, resolving a discrepancy in the UBL export.
Original PR description
Currently, the `prepaid_amount` in the UBL export is calculated as `amount_total - amount_residual` for all document types. However, for credit notes, debit notes, and refund notes (both standard and self-billed, corresponding to document type codes 02, 03, 04, 12, 13, and 14), this amount should be 0 to comply with Malaysian e-Invoicing (MyInvois) API requirements. This commit introduces the following fixes: - Sets the `prepaid_amount` to 0 for document types '02', '03', '04', '12', '13', and '14'. - Update the `payable_amount` to the full `invoice.amount_total`. Task-5971843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing Firefox users from installing push notifications due to a change in Firebase's SDK. By reverting to the legacy import syntax, we ensure compatibility with Firefox and enable all users to set up push notifications. This improves the overall user experience for push notifications.
Original PR description
When we released the first [fix], Firebase had stopped maintaining the legacy `importScript` syntax for their SDK and only provided an ECMAScript module, which prevented Firefox users from installing the service worker. Since Firebase has now released a legacy script, we will use it to enable Firebox users to set up push notifications. [fix]: odoo/enterprise#73390 Task-5124645
This update fixes a potential issue where users could refund multiple orders through a single refund transaction, leading to errors. The change now restricts refunds to a single order, ensuring data integrity and preventing unexpected system behavior. This improves the stability and reliability of the Point of Sale module.
Original PR description
Before this validation, it was possible to refund multiple orders per refund, but this resulted in a traceback if some orders were invoiced. This validation blocks the possibility of having multiple orders per refund, as in the following versions. opw-4791231
This update clarifies error messages related to stock package consistency checks. Previously, the messages didn't identify the specific problematic package, causing delays for users with large transfers. Now, the error messages pinpoint the issue, enabling customers to quickly diagnose and resolve the problem themselves.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical error that was causing debit notes to be rejected by the Italian SDI system. The issue stemmed from a typo in a field related to linked invoices, which prevented the correct XML format from being generated. This change ensures accurate data transmission and compliance with Italian tax regulations.
Original PR description
# Problem:
When sending debit notes to the SDI, they are rejected with the following error:
`File non conforme al formato : Invalid content was found starting with element 'Datifatturecollegate'. One of '{DatiOrdineAcquisto, DatiContratto, DatiConvenzione, DatiRicezione, DatiFattureCollegate, DatiSAL, DatiDDT, DatiTrasporto, FatturaPrincipale}' is expected.`
# Cause:
In the `account_invoice_it_FatturaPA_export_debit_note` there's a typo in 'Datifatturecollegate' as it should be 'DatiFattureCollegate'
https://github.com/odoo/odoo/blob/bc1c264b6232c78c33a96169110b37d9d4430243/addons/l10n_it_edi_ndd_account_dn/data/invoice_it_template.xml#L5-L8
opw-5930596
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA recent update caused a disruption in our SEPA direct debit payment processing. Customers were unable to complete transactions using this method due to a technical error. This fix resolves the issue, restoring reliable SEPA direct debit payments.
Original PR description
Issue: --- The SEPA direct debit is broken. Steps to reproduce: --- 1- Enable SEPA direct debit in payment providers. 2- Add something to cart and try paying using SEPA direct debit. You get the error: `payment.provider object has no attribute company.` Cause: --- This is introduced after #108469. opw-5993720
This update corrects a technical issue preventing German customers from completing their Amazon orders. The system was incorrectly sending building names as the primary address line, which caused delivery validation errors. By swapping the fields, we ensure accurate address formatting and successful order fulfillment for German customers.
Original PR description
When filling in a German address on Amazon, customers are presented with two fields: - Street, and - Building or company name. The street is sent as AddressLine2, while the building/company name is sent as AddressLine1. However, delivery providers validate address existence, which fails when address line 1 is not a street name. To resolve this, we swap these two fields for German addresses. opw-4668178