Daily updates from Odoo
Friday, August 22, 2025
7 changes · 18.0
Enhancements to existing features
This update strengthens electronic invoice validation for Australia, New Zealand, Malaysia, and Singapore so invoices are less likely to be rejected for missing tax or address details. It adds safer fallback values when tax IDs are absent and checks required seller and buyer address information for Singapore tax categories.
Original PR description
Description of the issue/feature this PR addresses: - AU&NZ: Current behavior is that when VAT is not set on the partner, the tax category code defaults to zero. This becomes problematic with certain…
Description of the issue/feature this PR addresses: - AU&NZ: Current behavior is that when VAT is not set on the partner, the tax category code defaults to zero. This becomes problematic with certain rules (e.g. the tax totals of tax category code 'O' should have amount of zero, but current code can set this value to something other than zero). The change focuses on edge cases when VAT of partner is not set. Changes are not related to the Q2 2025 release changes. - MY: Added fallback for <cac:PartyTaxScheme> to always have <cbc:CompanyID>. Currently breaks if the partner does not have VAT set. Changes are not related to the Q2 2025 release changes. - JP: No changes are made. - SG: Invoice with taxes of certain tax category codes must have seller and buyer street address and post code. Added constraint to make sure they are set. New PINT SG rule adds one more tax category code (Standard Rate, SRRC). New code is added to `ubl_cii_tax_category_code` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Guatemalan EDI module now avoids heavy invoice data calculations during installation, reducing the risk of memory errors on large databases. It also no longer installs automatically with the base Guatemalan localization, giving businesses more control over enabling it.
Original PR description
This commit adds `_auto_init` to the `account.move` object in the Guatemalan EDI that prefills all computed stored fields in the move object with null values. This prevents computation on those fields when installing the module, and also prevents MemoryError on large databases. task-5031330
Resolved issues and error corrections
Fully flexible employees can now request time off in hours as well as full days. This helps related apps such as Timesheets and Planning correctly record paid holidays and unavailable working intervals.
Original PR description
In this PR, we allow fully flexible employees to take time off in hours or days, to allow other apps such as timesheet to encode their paid holidays or planning to use unavailable intervals
Invoices can no longer be saved with a zero or invalid currency rate, preventing crashes when working with multiple currencies. The system now validates the rate and provides a safe default where needed, improving reliability for invoicing workflows.
Original PR description
Currently, an error occurs when a user tries to save an invoice with a currency rate of 0. Steps to reproduce: - Install `Invoicing` and enable at least 2 currencies. - Open an Invoice and change…
Currently, an error occurs when a user tries to save an invoice with a currency rate of 0. Steps to reproduce: - Install `Invoicing` and enable at least 2 currencies. - Open an Invoice and change currency to something other than USD. - Now change the currency rate displayed to 0 and save. Error: `ZeroDivisionError: float division by zero` Cause: - Error occurs due to a recent [feature](https://github.com/odoo/odoo/pull/214308) that allows changing currency rate. - Error occurred because the user set the currency rate to `0`, and line [1] attempted a division by zero, resulting in the error. Solution: - Added a constraint that restricts the currency rate and raise validation. - Added a default value for the currency rate in cases where the rate might be 0. [1]: https://github.com/odoo/odoo/blob/698e71b3a5b35fec5c7a27f2487df0e368c541b3/addons/account/models/account_move_line.py#L1505 sentry-6762861372,6787738443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Saudi e-invoicing no longer blocks invoices when the invoice company differs from the journal company in standard branch setups. The QR code now uses the correct company information for both branch and main company scenarios, reducing friction for businesses operating with branches.
Original PR description
This commit removes the previously enforced restriction in https://github.com/odoo/odoo/commit/d6175d0552c18006913e969eac7006666164609c that required the company specified on an invoice to match the company specified on the associated journal and makes sure that the company used to create the QR is the appropriate company whether in a branch or in a main company task-5005477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222935
A failed sale order confirmation no longer leaves the customer's signature saved in a way that blocks future signing attempts. This ensures customers can correct the issue and sign the order again after the underlying confirmation problem is resolved.
Original PR description
In this bug, sale order signature is commited before confirm, causing sale order not be able to be signed later, if confirm fails. To reproduce the bug: 1- Create a consumable product with `Buy` and `Dropship` routes enabled in the inventory tab 2- Do not put in any vendors in the purchase tab 3- Create a sale order with this product and uncheck the online payment option. 4- On an incognito browser, sign in as portal user and open the sale order 5- Click on the `Accept & Sign` button and confirm 6- We get an invalid operation error because of not having vendors 7- Reload the order. As you see, it is not possible to sign it To fix the issue, we use flush instead of commit, so when confirm fails it can rollback. Note: It is not easy to write a test for this case, because the `action_confirm` fails in a specific case when `purchase_stock` and `stock_dropshipping` are installed. opw-4864150 Forward-Port-Of: odoo/odoo#223610
Kenyan e-invoicing now ignores cancelled or draft credit notes when checking whether refunds exceed the original invoice. This prevents valid new credit notes from being blocked because of earlier reversals that are no longer reconciled with the invoice.
Original PR description
[FIX] l10_ke_edi_edi_oscu: ensure quantity and monetary values checks are performed on reconciled reversals only. Fixes a behavior where the checks performed on the credit notes related to their quantities and monetary values include non reconciled credit notes. Steps to reproduce: 1 - activate `l10n_ke` on some company. 2 - Create an invoice. 3 - Create a partial or full credit note ( this one will be reconciled with the invoice automatically ) 4 - cancel the credit note or reset it to draft. 5 - create another credit note where the quantities and/or monetary values exceed that of the invoice if summed up with the cancelled credit note. Following the steps will result in an error message saying that the monetary value or quantities on the credit notes exceed that of the invoice. The correct behavior is to simply not count any credit note that isn't explicitly reconciled with the invoice. opw-4779976