Thursday, April 9, 2026
16 changes · saas-19.2
Resolved issues and error corrections
This update ensures that negative values in the Mod 390 tax reports for Spain (l10n_es_reports) are accurately marked with the 'N' indicator, as required by Spanish tax regulations. Previously, these values were missing the necessary indicator, leading to potential reporting errors. This fix aligns with official documentation and ensures accurate data submission to the tax authorities.
Original PR description
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative…
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export ### Note: According to the official specification, negative amounts must be explicitly marked with N Latest documentation: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` with demo data and switch to the ES company - Create a Bill (Price: 100, Taxes: 21% G) - Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year - Open the VAT Deductible tab - The last line (65) should be negative - Export the BOE file using the gear menu - Check the last value of section 4 in the file ### Before the fix: Negative values were not marked with N opw-5482706 Forward-Port-Of: odoo/enterprise#113200 Forward-Port-Of: odoo/enterprise#111262
This update fixes an error in the Italian tax returns that was incorrectly including taxes beyond withholding taxes, such as INPS contributions. The fix ensures that the total amount calculated on the tax return accurately reflects only the withholding tax obligations, improving the reliability of Italian tax reporting. This update addresses a previous issue impacting financial accuracy.
Original PR description
### Issue before this commit: Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes…
### Issue before this commit: Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes such as 4% INPS were included in the computed total amount to pay, even though they should not be part of the withholding tax return. As a result, the final amount shown in the return was incorrect. ### Steps to reproduce the issue: 1. Download Accounting and l10n_it and switch to italian company 2. Create an invoice and a bill with a witholding tax (ex. 20% RIT PF) 3. Mark them as paid and reconcile them 4. Open a tax return and validate it 5. See that the total amount calculated includes also other taxes than only witholding taxes ### Cause of the issue: The issue was caused by a missing domain restriction when computing the tax closing entries. The method _get_vat_closing_entry_additional_domain did not properly apply a filter on tax tags for the withholding tax return type l10n_it_reports.it_withh_tax_return_type. Because of this, the query used to compute tax balances included all taxes matching the generic conditions (date, company, posted state, etc.), without restricting them to the relevant withholding tax tags. Consequently, unrelated taxes were included in the computation. ### Reason to introduce the fix: To restore the correctness of the tax return totals. opw-5905355 Forward-Port-Of: odoo/enterprise#112638
This update resolves an issue where expected hours weren't consistently calculated for attendance records, particularly with overtime. The change ensures that expected hours are always accurately updated, preventing discrepancies in reporting and improving the accuracy of time tracking. This fix addresses a bug that caused incorrect hour calculations when overtime was recorded.
Original PR description
The expected_hours field was not always being computed for attendances. self.add_to_compute is used here to ensure that it is always recomputed. 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 Forward-Port-Of: odoo/odoo#256744 Forward-Port-Of: odoo/odoo#251989
This update resolves an issue where the 'Export XML' button wasn't consistently producing the correct EU Standard (Peppol Bis 3.0) invoice file. Now, users can download invoices in this format when selecting it, ensuring accurate data exchange with trading partners in regions like Croatia.
Original PR description
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice…
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice Type as "EU Standard (Peppol Bis 3.0)" - Create an invoice - Confirm it - Click on the Wheel -> Download Current behavior: - without l10n_hr_edi: only "PDF" and "PDF without Payment" - with l10n_hr_edi: "Export XML" appear, but try to create an "ubl_hr" file Cause: "Export XML" button appear only if: - there is a default ubl option for the partner country - there is an XML attached to the invoice when clicked it exports the corresponding one. Whereas, the 'send' button rely on: 1) the partner defined edi format, 2) the default ubl option for the partner country 3) "ubl_bis3" To be noted: The route to download the XML doesn't keep the context of the active company and fallback to the first allowed company. As invoice_edi_format is company dependent it needs to be exported in the format defined for the company of the invoice. opw-5943500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257990 Forward-Port-Of: odoo/odoo#253650
This update corrects an issue where special characters (&) in vendor bill references were causing errors during SEPA payment file generation. The fix replaces '&' with '+' to ensure compliance with SEPA/SIX standards, preventing payment rejection by banks and ensuring accurate export of payment data.
Original PR description
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net &…
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer. 4. Create a batch payment with the SEPA payment and validate it. Issue: The `&` character is exported as `&` in the generated PAIN XML, while according to the SIX specification it should be replaced with `+` Cause: The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed. Solution: Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML. Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf opw-5941724 Co-authored by @bhra-odoo Forward-Port-Of: odoo/enterprise#110809
This update fixes an issue where invoices for downpayments were incorrectly using a default expense account instead of the designated ACC1 account. The change ensures that downpayment invoice lines now automatically use the correct account, streamlining the accounting process and preventing misallocation of funds. This improves accuracy and simplifies financial reporting.
Original PR description
Steps to reproduce: 1/ install purchase and accountant 2/ create and setup an expense account dedicated to your downpayments (typically code 60-, account type "expense"), ACC1. 3/ setup a service type product named "downpayment" 4/ set the default expense account on that product to be ACC1. 5/ create a PO for any product other than the downpayment (PO1). take note of the partner. 6/ create a bill for the same partner as the one set on PO1. Call it BILL1. 7/ On BILL1, add one invoice line with the "downpayment" product. Set a unit price. 8/ Confirm BILL1 and match it with PO1 via the "bill matching" smart button. Add it as a downpayment. 9/ Back on PO1, receive the products. Create a bill (BILL2). => The account suggested for the downpayment line in BILL2 will use the default expense account instead of ACC1. After this commit, the account suggested will be the one used in BILL1 for the downpayment line. opw-5253877 Forward-Port-Of: odoo/odoo#245518
This update fixes an issue where PEPPOL self-billing invoices weren't correctly including the delivery address and GLN number. The change ensures that the delivery address from the company partner is used in the generated XML, improving data accuracy for PEPPOL transactions. This ensures compliance and accurate invoice delivery.
Original PR description
**PROBLEM** When selfbilling with peppol, we have no way of providing a GLN number, or modifying the delivery address. Even if we create a delivery address partner on the current company partner, it's not taken into account. **STEP TO REPRODUCE** 1. Create a delivery address on the current company, set up a GLN number. 2. Configure the purchase journal to do selfbilling. 3. Create a vendor bill with this journal and send it using peppol. 4. Download the xml, and look for the Delivery tag, and notice it doesn't have the GLN number. **FIX** We search for a delivery address on the current company. If there is one, we use it for the Delivery tag. opw-6014374 Forward-Port-Of: odoo/odoo#257414 Forward-Port-Of: odoo/odoo#252970
This update automatically renews the KSeF token for our Polish users every 6 days. Previously, expired tokens caused disruptions in bill and invoice synchronization. This change ensures seamless and uninterrupted data exchange with the Polish tax authority, avoiding manual intervention.
Original PR description
The KSeF refresh token issued by the Polish Ministry of Finance expires after a week. Once it expires, the automatic fetching of incoming bills and sending of invoices will fail until the user manually re-authenticates in the settings. To ensure uninterrupted synchronization with the KSeF API, this commit adds a new scheduled action that runs every 6 days to automatically renew the tokens. task-6041758 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 Forward-Port-Of: odoo/odoo#256700
This update corrects a previous issue where the Amazon fulfillment channel in the sales module was incorrectly displayed as read-only. The change ensures users can now modify this channel setting, allowing for greater flexibility in managing Amazon sales operations. This resolves a reported usability problem.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended. Forward-Port-Of: odoo/enterprise#113196 Forward-Port-Of: odoo/enterprise#112866
This update corrects a display issue in Danish balance sheet and profit & loss reports. It simplifies the report format using account sublines and ensures accurate Danish translations for improved accounting accuracy. This resolves a bug where amounts weren't shown when certain report settings were active.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113101 Forward-Port-Of: odoo/enterprise#112430
This update fixes a bug in the website builder where options would unexpectedly fold closed after being expanded. Now, users can reliably keep groups of options unfolded, regardless of target changes, improving the user experience when customizing website elements. This ensures consistent and predictable behavior for website design.
Original PR description
Commit 64d35ccd6fade9e0473686b8484f561b5f4215ce added folding of groups of options. On every target change, all groups were folded, except the last one. But this leads to friction in some cases where the user wants another groups than the last one to stay unfolded. With this commit, a group that stays in the sidebar stays unfolded if the user clicked to unfold it, or if they used an option that changed the target to a descendant. Steps to reproduce: - Open website builder - Drag and drop a banner snippet - Click "add elements/text" - Bug: Banner options folds for no reason #### - Open website builder - Click on a column in the footer - Unfold the options of the footer - Click on another column of the footer - Bug: the options of the footer closes task-5999383
This update ensures the Danish version of Odoo's accounting system aligns with the latest tax regulations from Denmark. It includes updated account details, translations, and migration scripts to maintain accurate financial reporting for Danish businesses. This improves compliance and data integrity.
Original PR description
We updated the following in the Danish localization: - Updated the accounts to match the latest version provided by the Danish tax authorities. - Made sure we use the official Danish translations for the accounts and updated all of the English reference translations. - Removed outdated accounts and tags and have a migration script archive them for existing users. - Updated the account groups to match the CoA structure and use the correct Danish and proper English translations. - Adapted the account tags to match the updated accounts/numbers and replaced the outdated ones with their new version on existing accounts. - Removed unused account tags. - Updated some of the default accounts and prefixes on the chart template. task-5929517 Related: https://github.com/odoo/enterprise/pull/112430 Forward-Port-Of: odoo/odoo#257789 Forward-Port-Of: odoo/odoo#256541
This update fixes an issue where marketing emails sent in RTL languages (like Arabic) were incorrectly displayed in a left-to-right format. The fix ensures that RTL content is properly formatted by adding the 'direction' style to the allowed CSS, improving the user experience for international customers. This resolves a bug impacting campaign delivery and presentation.
Original PR description
**Steps to reproduce:** - Install Mail Marketing app - Change user language to a RTL language (such as Arabic) - Create a marketing campaign with RTL content - Send it (with the campaign, test mail works properly) - Mail received changes from RTL to LTR **Issue:** Table `direction` style is removed by the `_Cleaner` as it is not in its `_style_whitelist` during the composer creation. **Fix:** Add it to the valid styling to ensure rtl mails are properly formatted by the rtlcss library. related fix: https://github.com/odoo/odoo/commit/4ac3766fa5b458864c1728441cf4a157df943d39 sanitize on `mail.composer.mixin`: https://github.com/odoo/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208 opw-5982854 Forward-Port-Of: odoo/odoo#257886
This update fixes an issue where invoices were incorrectly using the previous day's currency rate instead of the selected date's rate. The change ensures that invoices accurately reflect the current exchange rate chosen by the user, improving financial reporting accuracy. This was caused by a recent code update and is now resolved.
Original PR description
Issue: When selecting a rate with the date picker, it applies the rate of the previous day Steps to reproduce: - Add a currency - On this currency, add a currency rate to today's date - Create en invoice in the added currency - On the currency rate picker take today's rate Current behavior: - take the first currency rate before selected date Expected behavior: - take the currency rate of the selected date Cause: Since 59f6a4848a160f99eb9f5c43755bb18f2f8b8a4b, account move take the currency rate of the date before the Bill/Invoice date. As the date picker uses the same methods, it returns the currency rate of the date before the selected date. opw-6046169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256041
This update fixes an issue where automatic invoicing caused guest contacts to be prematurely archived, preventing invoice emails from being sent. Now, archiving is tied to automatic invoicing and only happens after the invoice is successfully sent, ensuring reliable email delivery and proper contact management for invoices.
Original PR description
Before this fix, when automatic invoicing was disabled, manually sending an invoice by email resulted in an empty "Send To" field because the guest contact had already been archived. To prevent this issue, guest archiving is now triggered only when automatic invoicing is enabled. Additionally, to avoid problems with email delivery, the guest is archived only after the invoice has been sent. This ensures that the email generation process sees the guest as active. If the guest were archived immediately after the Sales Order confirmation, the email generation logic in `mail_thread.py` would skip the archived partner (`pdata['active'] is False`), preventing the invoice email from being sent. Forward-Port-Of: odoo/odoo#253674
This update ensures that company-paid expenses using SEPA credit transfers correctly require a vendor to be specified. Previously, the system would post these expenses without a vendor, leading to SEPA XML generation failures. The fix adds a validation step to enforce vendor selection before posting, ensuring accurate financial reporting.
Original PR description
**Steps to reproduce:** * Install `account_iso20022` and `hr_expense` module. * Create an expense with `Paid by Company` and `SEPA credit transfer` as the payment method. * Leave the `Vendor` field…
**Steps to reproduce:** * Install `account_iso20022` and `hr_expense` module. * Create an expense with `Paid by Company` and `SEPA credit transfer` as the payment method. * Leave the `Vendor` field empty. * Submit, approve, and post the expense. **Observed behavior:** * The expense is posted successfully without a vendor, creating a payment with `partner_id = False`. * The payment cannot be reset to draft due to the missing vendor, and SEPA XML generation fails because the creditor name (`<Cdtr><Nm>`) requires a partner. **Cause:** * The `hr_expense` module overrides `_compute_show_require_partner_bank`. to set `require_partner_bank_account = False` for expense payments, bypassing the partner bank validation in `account.payment.action_post`. * `_prepare_payments_vals` uses `self.vendor_id.id` for `partner_id`, which evaluates to `False` when no vendor is set. * The `_post` method on `account.move` only validates partner presence for invoices (sale/purchase documents), not for `entry` type moves, which payments use. **Fix:** * Add a validation in `hr.expense.action_post` that checks whether the payment method is `sepa_ct`. If so, `vendor_id` must be set before posting. * This catches the issue early in the expense flow, before the payment and journal entry are created. opw-5930687 Forward-Port-Of: odoo/odoo#252384