Daily updates from Odoo
Thursday, August 7, 2025
22 changes · 18.0
Enhancements to existing features
This update adds shared automated checks for point-of-sale localization modules across multiple countries. It helps ensure country-specific POS requirements keep working consistently, reducing the risk of regressions in localized sales flows.
Original PR description
Thi commit add a generic tour that can be run in all pos l10n_modules. In some cases it requires some extra steps, this can be done with hooks. The hooks will execute different steps depending on the country the tour is run in. opw-4606788
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
This update adds automated testing support for Point of Sale setups that use the Belgian blackbox. It helps ensure the POS works correctly in this compliance-specific environment, reducing the risk of issues during validation or use.
Original PR description
This commit introduces the possibility to add tours to test the POS when using a Belgian blackbox. This is useful to verify the functionality of the POS system in a blackbox environment.
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
This update fixes the layout of work address fields on the employee form so state, city, and ZIP appear neatly on the same line. It improves readability and data entry consistency for users managing employee work addresses.
Original PR description
Task ID: 5002920 Description of the issue/feature this PR addresses: Align state, city, and zip fields horizontally on employee form Current behavior before PR: Not alignment in tab Employee > Work address as per fields state, city, and zip Desired behavior after PR is merged: Fields aligned
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
Creating or confirming a payment no longer fails when a payment method has no name. The system now safely treats the missing name as blank, allowing payment processing to continue without disrupting users.
Original PR description
Currently, a traceback occurs when the user tries to create a payment with a payment method line having no name. To reproduce this issue: 1) Install `Invoicing` 2) Open the `Bank` journal outgoing…
Currently, a traceback occurs when the user tries to create a payment with a payment method line having no name. To reproduce this issue: 1) Install `Invoicing` 2) Open the `Bank` journal outgoing payments from `configuration/journals` 3) Remove the `name` of the first payment method 4) Now create a new payment with type as `send` and journals as `Bank` from `Customers/ Payments` 5) Confirm it Error:- ``` TypeError: sequence item 0: expected str instance, bool found ``` This issue arises because we get the `paymnet_method_line_id.name` value as False. When the user removes the name of that `payment_method_line_id`. https://github.com/odoo/odoo/blob/3485abaa313263ea1946b9bdbffec5928d31fd72/addons/account/models/account_payment.py#L279 This leads to a traceback when `join()` is used between an empty string and a bool value. https://github.com/odoo/odoo/blob/3485abaa313263ea1946b9bdbffec5928d31fd72/addons/account/models/account_payment.py#L337 To resolve this issue, we can give a fallback value of an empty string. sentry-6067383068
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
When customer invoice numbers are resequenced, the related payment reference is now refreshed to match the updated invoice name. This prevents mismatched details when invoices are sent to customers and helps avoid payment confusion.
Original PR description
<b>Steps to reproduce:</b> 1. Go to Invoicing > Turn on debug mode. 2. Select a customer invoice and click on Actions > Resequence. 3. After resequencing, observe the "Other Info" tab — the payment reference remains unchanged. 4. Click "Send" on the invoice — the displayed invoice name differs from the payment reference. <b>Issue:</b> - The `payment_reference` field is not updated after the invoice `name` is resequenced. <b>Cause:</b> - The existing logic does not computes for `payment_reference`. Since resequencing updates the `name` without updating `payment_reference`, it remains outdated. <b>Solution:</b> - Manually compute the `payment_reference` for posted customer invoices after resequencing, using `_get_invoice_computed_reference()`. <b>opw-4903455</b>
Fixes an issue where quickly adding and removing carousel slides in the website editor could cause an error. This makes editing carousel content more reliable and prevents interruptions for website editors.
Original PR description
Previously, when rapidly adding and removing slides in the Carousel snippet (s_carousel), a JavaScript traceback would occur under certain conditions. Step to reproduce: 1. Drag and Drop a Carousel Snippet (s_carousel) on the page. 2. Rapidly `add -> remove -> add` slides button in editor. 3. Traceback occurs. Cause: - The issue occurred because the currently active slide was passed as the target to activate a snippet. During rapid DOM changes, the active slide could be destroyed or not yet rendered, resulting in a race condition and JavaScript error. Solution: - Additional guards have been added in the `_activateSnippet` function to ensure the `editorToEnable` target is still present in the DOM. task-4270369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214721
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 change prevents an access error that could occur when an employee without Time Off permissions changed a leave request from paid time off to sick leave. It helps ensure regular users can submit and adjust time off requests without being blocked by an internal overtime field.
Original PR description
Steps: ([demo](https://drive.google.com/file/d/1nphgXlAc_w3z0oE7ickuTaGhl5khLhxo/view?usp=drive_link)) - Remove Time Off access to "Demo" user - Login as demo - Request a "Paid Time Off" - Change the Request time off type to "Sick" Actual result: - overtime_id field access error Expected result: - no error Caused by: https://github.com/odoo/odoo/pull/207780 opw-4929659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218095
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
The system now keeps the standard expiration message when an account is expiring for upsell-related reasons. This avoids showing renewal-specific wording in cases where it does not apply, making the message clearer for users.
Original PR description
Upsell expiration are not handled the same way as renewal expiration, so we can keep the default expiration message for any expiration reasons other than a renewal Forward-Port-Of: odoo/enterprise#91795 Forward-Port-Of: odoo/enterprise#91730
When warehouse staff split a reserved package during barcode processing, the new line now correctly keeps the original source package. This prevents missing package information and helps ensure partial deliveries are tracked accurately.
Original PR description
### Before this PR: - Put a package in WH/Stock with quantity 100 - Create delivery for partial quantity for example 50 - Go to app barcode - Try to split the package into two different packages scanning another destination Package - The splitted line will be created with empty package instead of the package already reserved before ### After this PR: Scanning another destination package , the new line created splitting the old one will have the package_id
The VoIP call timer now uses consistent device-side timing so it does not show a negative duration when server and user device clocks differ. This avoids confusing call displays and makes call duration tracking more reliable for users.
Original PR description
It was reported that the timer for the call would sometimes start as a negative number. Examining the code that computes it suggests that the timestamp sent by the server was a few seconds in the future compared to luxon.DateTime.now() (client time). This discrepancy is most likely due to the clock skew between the client and the server. This commit adapts the code so that it only computes time based on client-side values, effectively preventing clock skew issues. Task-4930666 Forward-Port-Of: odoo/enterprise#91738
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
Hong Kong payroll payslips now use the employee's regular name when surname and first name are not provided. This prevents payslips from showing an empty or incorrect legal name value, improving clarity for payroll users.
Original PR description
Explanation: In hong kong payroll, the legal name is joined by surname and first name. However both fields are not madatory therefore it will display False on Payslip. After this commit, it will display the name field when both surname and first name are not used. opw-4944968
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