Daily updates from Odoo
Wednesday, October 22, 2025
12 changes · saas-18.2
Resolved issues and error corrections
Shopee orders marked as delivered but awaiting buyer confirmation will no longer be treated as delivery errors in Odoo. This prevents unnecessary error states and gives users a more accurate view of shipment progress.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
This fix updates French VAT report submissions so the address information sent to ASPOne follows the required format. It helps prevent rejected filings caused by postal codes or city names that exceed ASPOne's accepted limits.
Original PR description
This commit check that all the information that we send to aspone follow the constraint. By checking the xsd file, here what has been modified: - AdresseType is depreciated so we add AdresseRepetabilite - Adding a comment to remove a template not used in master - postal_code needs to have maximum 17 character - city needs to have maximum 35 character task-5169258 Forward-Port-Of: odoo/enterprise#97346
Delivery label printing now includes every label attached to the delivery record, instead of printing only one when multiple files are present. This helps warehouse and shipping teams avoid missing labels and reduces manual reprints or shipping delays.
Original PR description
Before this commit, only 1 label get printed even if multiple files are in the chatter After this commit we handle the cases with multiple files + revert suppression of public method for API opw-5181209 Forward-Port-Of: odoo/enterprise#97805
Fixes an issue where creating multiple payslips for the same employee in one batch could duplicate the full expense amount on each payslip. This helps ensure payroll expenses are assigned to the correct payslip and prevents overstatement of employee payments.
Original PR description
since 9435b76 an issue arise when an employee gets two payslip generated for them in the same batch as both would get the full expense input line amount whereas only one gets the expenses linked to it. This adds a context key to bypass the computation when the payslips are created from a batch and trusting the create of the payslip to handle the proper assignation of expenses and computation of the lines Forward-Port-Of: odoo/enterprise#81987
Budget line reports now show committed amounts only for the selected budget line instead of counting matching amounts from the whole budget. This prevents overstated commitments when a bill is split across multiple analytic plans, helping users trust budget reporting figures.
Original PR description
Steps to reproduce: - Create analytic plan A and B - Create new budget with 2 lines: 1. Plan A: Analytic account A, Budget: Any 2. Plan B: Analytic account B, Budget: Any - Create bill with line having: - Unit price: 100 - Analytic distribution: planA -> account A, planB -> account B - Open the Budget Issue: While the committed amount in each budget line is correct (100), when opening the line budget report, the committed amount is doubled (200 instead of 100). This occurs because the system matches the whole budget instead of the specific budget line. opw-5039677 Forward-Port-Of: odoo/enterprise#97514
Fixed an issue where checkout could load indefinitely when external tax calculation failed for Brazilian sales, such as missing product tax data or invalid addresses. Customers can now continue through checkout and see the relevant error message instead of getting stuck.
Original PR description
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with…
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with infinite loading. Examples include missing NCM codes or IAP service failures due to invalid addresses. **Steps to Reproduce** 1. Install Brazilian localizations (l10n_br, l10n_br_avatax, l10n_br_edi). 2. Configure Avatax Transfer API credentials (API ID and Key). 3. Create a website with a Brazilian company. 4. Add a product to the cart and proceed to checkout. 5. Choose a delivery method and observe that the UI gets stuck loading. **Root Cause** The `_order_summary_values` method in `website_sale_external_tax` called `_get_and_set_external_taxes_on_eligible_records()`, which could raise exceptions (e.g., IAPServerError). These exceptions were not handled, so they propagated to the frontend as generic RPC errors. The frontend has no built-in mechanism to display these exceptions as user-friendly messages, resulting in infinite loading. **Fix** Wrap the external tax calculation in `_order_summary_values` and catch `UserError`. Instead of letting the exception propagate as a generic RPC error, attach the error message to the result dictionary under `external_tax_error`. This prevents the frontend from hanging while still making the underlying problem visible in the next checkout step, where validation errors are properly handled and shown to the user. Opw-5052078 Forward-Port-Of: odoo/enterprise#95045
Bill and sales receipts now keep their deferred dates and generate deferral entries using the correct accounts. This prevents accounting errors when teams use receipt document types for deferred expenses or revenue.
Original PR description
## Steps to reproduce ### Bug 1 1. Create a bill receipt 2. Add deferred dates 3. They're reset to False ### Bug 2 1. Create a bill 2. Set the deferred dates 3. Switch to receipt type 4. Confirm 5. The account of the generated deferral entries is incorrect ## Fix While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value. In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates. In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator. For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account. opw-5129561 Forward-Port-Of: odoo/enterprise#97653
Signature request and other inbox messages that are not tied to a specific record now show directly in the top messaging menu. This prevents users from seeing a notification count but finding no visible message when opening the menu, reducing confusion and missed requests.
Original PR description
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of…
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of the signature request, as the counter badge is updated. - When clicking on the badge, no new message is shown. **Issue:** Inbox messages are not considered in the `MessagingMenu` when they are not linked to any record. It's the case when a signature request is sent and while the notification counter is updated, the message can't be seen in the top bar menu, it's only visible in the `Discuss` app > Inbox which is quite confusing for the users. In previous versions the behavior was different as the signature request was either considered as an activity or no notification was sent. Also if the inbox message is linked to a record, it only appears in the `all` filter of the menu. **Fix:** Added the inbox explicitly to the top `MessagingMenu` to be able to read the corresponding messages. We could also link the signature to its record when sending the message instead of `self.env['sign.request']._message_send_mail()` but it might cause access rights issues. Also ensured that a category `others` was used for such messages, and prevented an error caused by clicking on the conversation when the `Discuss` app was opened. Unfortunatly doing this will show duplicates in the notifications of the menu for messages which are in the inbox but which have a record set. (e.g. when such message appears, it will have one line in the inbox and one for the record itself) So we need to filter out the messages which have a thread from their record in the views to avoid it. related: https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda opw-4969005
A point-of-sale restaurant preparation display test was corrected to match the latest behavior for empty preparation tickets. This helps keep automated quality checks reliable and reduces the risk of false test results during updates.
Original PR description
pos_* = post_restaurant_preparation_display Before this PR (https://github.com/odoo/odoo/pull/231733), the checkPreparationTicketData method returned True if the preparation ticket was empty. This is no longer the case, so the test has been updated to work correctly now. Related Community PR: https://github.com/odoo/odoo/pull/231733
A spelling mistake in Odoo Studio’s field options was corrected from “Multine” to “Multiline.” This helps users see the intended field name clearly when configuring views.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97713
This fix prevents an error when users post WIP accounting entries while a manufacturing work order is still running. The system now handles active work orders without an end time, allowing the WIP wizard to open as expected and keeping costing workflows uninterrupted.
Original PR description
Issue: - Traceback when calculating the cost of a workorder Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post WIP Accounting entry" Current Behavior: - get a traceback Expected behaviour - open the WIP wizard Cause of the issue: - to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'. Solution: - check if the end date of the WO is defined Test: - in module mrp_workorder an override of button_start change how work order are launched. Therefore, the test should be launched on an Enterprise run. opw-4961873 Forward-Port-Of: odoo/enterprise#93812
Sales users planning service work from a sales order can now see and enter allocated hours when creating a planning slot. This restores an important scheduling field in the specific flow where the combined date-and-hours widget is hidden, helping avoid incomplete shift planning.
Original PR description
Steps to reproduce: - Create a Sales order with planning services. - Click on To Plan stat button. - Click on empty cell Issue: - Plan dialog is opened but has missing allocated_hours field. Reason: - In this commit https://github.com/odoo/enterprise/commit/d21bd4b694ec63ba83bea077714a8fe928d6e014 allocated hours was merged with start_datetime using a widget and thus removed from view. - But in planning list view we hide start_datetime when we schedule shifts from sales order. Fix: - Add back allocated_hours conditionally to be visible when we schedule shifts as in other cases start_datetime is present. task-5117776