Daily updates from Odoo
Tuesday, January 20, 2026
6 changes · 17.0
Enhancements to existing features
This update enhances the spreadsheet module by adding logging when exporting large datasets, particularly during spreadsheet downloads, clipboard copies, and printing. It also restricts access to frozen or XLSX spreadsheet downloads to authorized users, improving data security and control.
Original PR description
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 enhances logging when exporting large amounts of data from Odoo spreadsheets, addressing potential performance issues. It now tracks data downloads, clipboard copies, printing, and freezing, providing better visibility into spreadsheet activity. Additionally, access to frozen or XLSX spreadsheet downloads has been restricted to authorized users.
Resolved issues and error corrections
This update backports key testing components and fixes related to UBL (Universal Business Language) invoice generation in Odoo. Specifically, it addresses issues caused by changes in the UBL XML format, ensuring accurate test results and compliance. The changes improve the reliability of UBL invoice exports, crucial for accurate accounting and reporting.
Original PR description
*: `account`, `l10n_account_edi_ubl_cii_tests` This commit backports the AccountTestInvoicingCommon test helpers (in particular for record creation and XML save/assert mode) and also the new UBL…
*: `account`, `l10n_account_edi_ubl_cii_tests` This commit backports the AccountTestInvoicingCommon test helpers (in particular for record creation and XML save/assert mode) and also the new UBL tests developed by Laurent in 18.0, in 17.0. A couple fix was also backported to ensure the asserted test files stay as similar as possible betweeen the new versions and 17.0: - `cac:DeliveryParty` node now have `cac:PartyName` > `cbc:Name`, instead of `cac:Party` > (...) - allowance charge reason code for EPD taxes is now 64 instead of 66 - allowance charge reason code for fixed taxes is now conditional either 'AEV' or 'CAV' - added multiplier factor node - add tax currency node when the currency of the invoice is not the same as the company - prevent raising the constraint when having a python tax in the invoice These changes affected the general UBL XML generation, and caused some tests on `l10n_account_edi_ubl_cii_tests` to fail, most commonly because they're missing the `TaxCurrencyCode` as they were written without using local currency in mind. These errors have been corrected in their respective files. related-enterprise-PR: https://github.com/odoo/enterprise/pull/104758 task-4891206
This update resolves a problem where users with custom tax groups (beyond the standard 6) would prevent efaktur printing. The fix ensures that efaktur printing works correctly with custom tax groups, while also correcting VAT calculations for invoices with mixed tax groups.
Original PR description
Description of the issue/feature this PR addresses: This issue occured because in the previous update we add a condition to restrict multiple tax groups excluding the STLG. Apparently there is a case…
Description of the issue/feature this PR addresses: This issue occured because in the previous update we add a condition to restrict multiple tax groups excluding the STLG. Apparently there is a case where some users create their own tax groups (for example for PPH) so when they want to print an efaktur it will raise an error. Current behavior before PR: If a user create their own tax with a new tax group (outside of the 6 groups defined in `l10n_id`) and use it in invoice line along with one of the 6 tax groups excluding the STLG then it will blocked the print efaktur because it will raise an error Desired behavior after PR is merged: - The restriction in tax groups only applied for the 6 tax groups in l10n_id so if an invoice line has multiple tax groups as long as there no more than one of the 6 tax groups excluding the STLG then it should be able to print the efaktur. - Also when building the efaktur coretax value, the new tax group should not be included in the regular_tax variable which will cause the value to be 11/12 of the original value. - Add new condition to block the print efaktur if there is a tax inside the invoice but none of it belong to the 6 ppn tax groups (there is already a condition to block if no tax is given, but now since there are cases where they use tax group outside of the defined tax groups then it will print the efaktur) - If an invoice line does not have any ppn_tax_groups but there are other line in the same invoice that has it then it will still be able to print the efaktur, but the line without the ppn tax will have the OtherTaxBase and VATRate set to zero which will calculate the VAT as 0 too. [5434656](https://www.odoo.com/odoo/project.task/5434656) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a timezone discrepancy when generating invoices for ZATCA, ensuring the correct time is sent. Previously, the system added a +03:00 offset, which ZATCA requires to be in the Asia/Riyadh timezone. This fix ensures invoices are formatted correctly for ZATCA submissions.
Original PR description
The time information added to the date of the invoice post for ZATCA in iso format which adds +03:00. However ZATCA expects the time to be sent as is in Asia/Riyadh timezone. - Set up a ZATCA company and onboard a journal - To simulate the timezone issue, replace the hour value with 23h in the following line: vals['l10n_sa_confirmation_datetime'] = datetime.combine(move.invoice_date, fields.Datetime.now().time()). (use .replace(hour=23))) - Create, confirm, and send an invoice to ZATCA opw-5373067 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 fixes a reporting issue related to salary certificates for employees in Switzerland. The ‘Period until’ and ‘Period from’ dates for salary certificate generation are now dynamically pulled from the employee’s data, ensuring accurate and up-to-date reporting requirements. This change simplifies the process for HR and finance teams.
Original PR description
make Period until and from dynamic from data