Daily updates from Odoo
Thursday, August 7, 2025
11 changes · 18.0
Enhancements to existing features
Bulgarian invoices will automatically use the invoice date as the delivery date when no delivery date is entered. This helps businesses meet local invoicing requirements and reduces the risk of missing mandatory information on printed invoices.
Original PR description
Description of the issue/feature this PR addresses: Delivery dates on invoices are a legal requirement on Bulgaria. It needs to be displayed on the header of the form view and will be displayed on the printed invoices. Current behavior before PR: Delivery date is not required and it is possible to not have value. Desired behavior after PR is merged: If delivery date is empty it copy the value of invoice date field in delivery date field --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale users in Brazil can now download NFC-e XML files for multiple orders at once from the order list. This saves time and reduces manual work when collecting fiscal documents for reporting or compliance.
Original PR description
- Before this PR: No available action to download NFC-e XML files in batch. User has to download each xml file one by one. - After this PR: An action to download multiple NFC-e XMLs for multiple orders is added in the PoS orders list view. Task Id: 4934938
Resolved issues and error corrections
Users can now add images by URL even when the source website has certificate issues that previously blocked the upload. This reduces failed image insertions in the HTML editor and helps users reuse externally hosted images more reliably.
Original PR description
Currently, an error is generated when the user uploads an image with a URL like https://hcmute.edu.vn/Resources/Images/SubDomain/HomePage/tin%20tuc/B%C3%A1o%20ch%C3%AD%20n%C3%B3i%20g%C3%AC%20v%E1%BB%81%20HCMUTE/Nen/Nen%20phu%20nu.jpg error: `SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)` This is because `requests.head()` is trying to verify the user-provided URL server has a valid TLS certificate, but it is not found with the above url. This commit will fix the above issue by disabling SSL verification on the user provided image URL. sentry-5998939121 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could block users from registering payments when an invoice and its payment use different currencies. Businesses using multi-currency accounting can now process these payments more reliably without hitting an unexpected system error.
Original PR description
Currently, an error occurs when register a payment for an invoice in a different currency. Step to produce: - Install the ```account``` module. - Activate multicurrency - Create a new invoice(in USD), add an invoice line and customer, and confirm it. - Change the currency to EUR when making an invoice payment. ```IndexError: tuple index out of range``` An error occurs when the system tries to get a move line at [1], 'move_id' for a payment is not available Link [1]: https://github.com/odoo/odoo/blob/8e95527210a40f354ffb3c57e49f6580252edbfa/addons/account/wizard/account_payment_register.py#L1110 To handle this issue, add a condition to retrieve the move line value if an invoice is available for payment. Sentry-5989418366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures withholding taxes on refund payments are recorded using the proper refund treatment, so tax reports reflect the amounts correctly. It also prevents an issue that could stop users from editing payments when certain default company accounts were used.
Original PR description
Currently, there is an issue with how the repartition line is selected when registering payment for a refund for withholding taxes. It would select the invoice repartition line, causing the tax amounts to affect the tax report in the wrong way. - It is not setting the is_refund param on the base line, leading to incorrect lines on the payment's entry. - Detecting if we are a refund is tricky with the current system, which is based on the wizard payment_type. It requires some changes in order to be able to have withholding lines with a type_tax_use which doesn't match the payment wizard. Also fixes an issue where a payment could not be edited after creation if the withholding tax line is using the company's default transfer account. In this case, the lines would be counted as counterparts and cause issues. As the account on the base line does not matter that much, we decided to use the simple solution of blocking its usage.
This fix ensures Malaysian e-Invoices use the right state information for foreign customers and consolidated invoices. It helps businesses avoid submission errors and stay aligned with Malaysian e-Invoicing requirements.
Original PR description
## Before this commit: The `CountrySubentityCode` was computed by simply using the `state code` of the partner, without handling the following cases: - Non-Malaysian Partners: For partners located outside Malaysia, the format requires the `state name` to be passed instead of the `state code`. - Consolidation Entries: For consolidation invoices, a fixed value `17` should be passed as the `CountrySubentityCode`, regardless of the partner’s state. ## After this commit: The computation of `CountrySubentityCode` has been updated to handle both cases correctly: - For non-Malaysian partners, the `state name` is used. - For consolidation entries, the fixed value `17` is used. - For regular Malaysian partners, the `state code` continues to be used as before. This ensures compliance with Malaysian e-Invoicing specifications and prevents errors. > Task-4938198 Forward-Port-Of: odoo/odoo#219201
The Luxembourg tax report XML export now follows updated legal rules for special scheme fields, only including certain fields for periods that touch 2025 or later. Annual VAT reports also ensure required fields are present when related fields are included, reducing rejection risk during filing.
Original PR description
As per legal requirements, the 491, 492 and 493 fields of the xml export of the tax return only need to be included if at least one day of the period includes dates in 2025 or later. As per legal requirements too, the 192 and 193 fields are mandatory in the annual report if some other fields are present. Among those are 361 and 362 which are mandatory even if null so if 192 and 193 are not there yet, we set them to 362 and 363 values (0.0 in most cases). --- from feedback on task-4587067 opw-4757770 Forward-Port-Of: odoo/enterprise#91648 Forward-Port-Of: odoo/enterprise#89437
Winbooks imports now continue when the source chart of accounts uses tax accounts differently from Odoo's default setup. This prevents import failures and lets users review and adjust the imported draft data inside Odoo afterward.
Original PR description
When importing Winbooks data, if the CoA configuration in Winbooks is different from Odoo's default, users will experience a failure with a message similar to ``` Validation Error Tax Receivable Account (411000 VAT Recoverable) should be an account of type "Receivable" or "Payable" with both options "Allow Reconciliation" and "Non Trade" enabled. ``` This occurs because the account 411000, meant to store the tax provisions, in Winbooks was used as tax receivable. In similar cases we should not raise any error and should let the import go through: the data is imported in draft and the user has the possibility to bring the modifications in Odoo opw-4850314
This update resolves several operational issues across accounting localization, bank statement imports, IoT device handling, and point of sale compliance. It helps prevent errors during e-invoicing, financial report exports, dry-run imports, and device subscription reporting.
Original PR description
Revert odoo/enterprise/pull/81587 because errors are triggered on dry-run. closes odoo/enterprise#83391 Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Fixes an error that could block customers from paying a renewed subscription after using the preview and payment flow more than once. Missing invoice amounts are now treated as zero, allowing the payment process to continue reliably.
Original PR description
Currently, an error occurs when the user again pays for sale subscriptions. Step to produce: - Install the ```sale_subscription``` module. - Create a new sale order, add a customer name, add a…
Currently, an error occurs when the user again pays for sale subscriptions. Step to produce: - Install the ```sale_subscription``` module. - Create a new sale order, add a customer name, add a product in the order line that has 'Subscriptions', and add a 'Recurring Plan' with date and confirm the sale order. - Create an invoice for this sale order and confirm it. - Back to the sale order, click on 'Renew' button. - Open a preview of the sale order, and click on 'Sign & pay', and come back to the edit mode of the sale order. - Again open a preview of the sale order. - Again click on 'Pay' for this sale order subscription. ```TypeError: unsupported operand type(s) for *: 'NoneType' and 'float'``` An error occurs when the system attempts to compare invoice amounts with the recurring amount at [1], but value of an invoice amount is 'None'. Link [1]: https://github.com/odoo/enterprise/blob/df2735cdd067df9ec88cad8202da2314ffd9d65a/sale_subscription/controllers/portal.py#L396 To handle this issue, provide a default amount for an invoice as zero. Sentry-6014356823
The Czech VIES summary report now uses the correct invoice count, transaction terminology, grouping, and whole-crown totals. This helps businesses submit more accurate VAT reporting in line with Czech tax authority requirements.
Original PR description
There are some errors in the VIES summary report fixed here:
1. The supply number is not the quantity invoiced, it is the
number of invoices
2. There was some confusion between the terms "supply transaction"
and "supply code", with "supply code" not being used
in this report (but still in Python code to avoid breaking stable versions)
3. We were considering journal items, whereas it is preferable
to group them by journal entry
4. The total value is rounded up to the nearest whole crown (Czech currency)
Here is a link to the documentation:
adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV
where pln_hodnota is the total value; pln_pocet is the supply number; and k_pln_eu is the supply transaction.
opw-4688616