Thursday, May 7, 2026
18 changes · saas-19.3
New functionality added to Odoo
This update backports the PL Bank Account Verification feature, which allows businesses to securely verify bank accounts against Polish government APIs. This improves compliance with local regulations and streamlines the process of connecting bank accounts within the Odoo system. It builds upon previous work tracked in odoo/odoo#250400.
Original PR description
[ADD] l10n_pl_bank_verification: Backport bank account verification Backport of the feature that implements PL Bank Account Verification against the government API See odoo/odoo#250400 task-4637086 Forward-Port-Of: odoo/odoo#262518
Resolved issues and error corrections
This update resolves a bug in the generation of Spanish BOE reports (mod347) for businesses. Previously, invoices under €3,005.06 caused incorrect partner data to be included in the export. This fix ensures that only relevant partners are listed, improving data accuracy and compliance for Spanish tax reporting.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#116387 Forward-Port-Of: odoo/enterprise#110947
This update fixes an issue where manually specified lot quantities in manufacturing orders weren't being applied correctly. Previously, the system was incorrectly calculating quantities based on available lot stock, leading to inaccurate consumption. This change ensures that manually set lot quantities are accurately reflected during the production process.
Original PR description
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for…
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for product P with 2 units each - Create a MO for a product consuming two units P and confirm it - On the raw move, manually set 1 unit for each lot - Click on "Produce All" - Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each **Cause** While producing: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line: - Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297 - Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity **Solution** Assume that raw move lines being created in mrp without changing the producing quantity are manually created opw-5946439 Forward-Port-Of: odoo/odoo#260518 Forward-Port-Of: odoo/odoo#257258
This update fixes an issue where bank statement imports were failing due to the system not using the correct partner name. The change ensures that when a CAMT file contains both 'Dbtr' and 'UltmtDbtr' information, the 'UltmtDbtr' name is used for reconciliation matching, preventing errors and improving data accuracy.
Original PR description
Steps to reproduce: 1- Create a Swiss company and switch to it 2- Go to [Accounting -> Configuration -> Journals] and create a Bank journal 3- Go to the Accounting dashboard, click on the three dots on the Bank journal and click import records 4- Upload a CAMT file with a record that has both a value for "Dbtr" and "UltmtDbtr" (file can be found in the ticket chatter) Issue: The added record uses the "Dbtr" `name` value for the partner name. As a result, reconcilation matching fails Expected behavior: If exists, should use the "UltmtDbtr" `name` value opw-6024860 Forward-Port-Of: odoo/enterprise#113560
This update significantly improves the speed of importing large XML bills, particularly those received via Peppol or manual upload. By optimizing the system's database queries and update processes, the upload time for bills with 30,000+ lines has been reduced from failing to completing in just 11 minutes. This enhances efficiency for our accounting operations.
Original PR description
### Description: The upload and import process for large XML bills via Peppol or manual upload was inefficient due to two primary bottlenecks. First, the system performed individual queries per line to match products, taxes, and accounts, leading to an N+1 query issue. Second, multiple write operations were executed on each line to update various fields. This commit introduces batching and improve caching for these operations to reduce database call. ### Benchmark: | N° of lines | Before | After | |-------------|---------|-------| | 30264 | Timeout | 11min | ### Reference: opw-5416612 Forward-Port-Of: odoo/odoo#262882 Forward-Port-Of: odoo/odoo#248680
This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices. Specifically, a problem with how the system handled multiple currency lines led to incorrect balance calculations and hidden values. The fix ensures accurate balance display during reconciliation, improving the user experience.
Original PR description
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366 Forward-Port-Of: odoo/enterprise#115101
This update fixes an issue where invoices for recurring subscriptions weren't accurately reflecting the billing period. The change ensures invoices align correctly with the subscription's billing period value, regardless of the billing period length (e.g., 6 months, 3 months). This prevents invoices from only covering a single month's worth of service.
Original PR description
## Issue When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit…
## Issue
When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit of time (week/month/year).
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Recurring Plan RP:
- *Billing Period*: 6 Months
- *Align to Period Start*: Checked
3. Create a Subscription Product P
4. Create a Subscription SO:
- Any Customer
- Recurring Plan RP
- Product P (any quantity/price)
5. Confirm the SO and create the invoice
6. **In the line of the SO, only one month is covered by the invoice. If we generate the next invoice, only one month will be covered as well.**
## Cause
Since https://github.com/odoo/enterprise/commit/45f28f6c288f5213a4e29c816ec68d2c3966b55f, the `next_date_1st` is evaluated by taking the last day of the month/year and incrementing it by one day, to reach the first day of the next month/year.
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/sale_subscription/models/sale_order_line.py#L377-L382
This is inaccurate when working with recurring plan which are not monthly/yearly, as it will always set the `next_date_1st` to the next month/year, without taking in account the `billing_period_value`.
## Fix
There are two ways to align dates to the period start. Given a subscription starting on January 15, with a billing period of 3 months, we could:
1. Invoice from January 15 to January 31, then from February 1 to April 30. This aligns the invoice to the closest month, then apply the 3 months period for the next invoices.
2. Invoice from January 15 to March 31, then from April 1 to June 30. This applies most of the billing period for the first invoice, while still aligning it to the start of the month, then apply the 3 months period normally for the next invoices.
**Here, we chose the second option** to avoid making the code more complex and keep the diff minimal.
opw-6151530
Forward-Port-Of: odoo/enterprise#115830This update resolves an issue preventing mobile users from uploading documents through the portal. The fix adjusts how the file upload button interacts with the mobile interface, ensuring the file picker remains active and uploads complete. This improves the user experience for mobile portal users.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Create a portal user and share a document folder with edit access 3. Log in as the portal user on a mobile device 4. Try to upload a document inside the…
Steps to reproduce:
1. Install `documents`
2. Create a portal user and share a document folder with edit access
3. Log in as the portal user on a mobile device
4. Try to upload a document inside the shared folder
Issue:
- After selecting a file from the file picker, the document is not uploaded.
Cause:
- On mobile in the portal flow, Upload is triggered from a nested dropdown (inside New) inside the adaptive control-panel dropdown (bottom sheet). By default, DropdownItem uses closingMode="all", so tapping Upload closes parent dropdowns immediately. That unmounts the hidden <input type="file"> before the OS file picker returns. When the user comes back, the input no longer exists, so change never fires and upload does not start.
- Admin/internal users do not hit the same nested adaptive-dropdown path in this view
Solution:
- Set closingMode="'none'" on the Upload DropdownItem so the menu stays mounted while the native picker is open. After a file is selected and onFileInputChange starts upload, close the bottom sheet programmatically with: `window.dispatchEvent(new Event("popstate"))`
opw-5937105
Forward-Port-Of: odoo/enterprise#108486This update resolves an issue where custom snippets weren't correctly reflecting translated content due to a conflict with the delayed translation feature. The change ensures that translated values are properly applied when using custom snippets, improving the website localization experience for users. This fix allows for accurate multi-language content display.
Original PR description
The feature "delayed translation" and "copy translation in custom snippet" have been worked on in parallel, but had buggy interactions. This commit changes the way translations terms are copied in custom snippets to read and write the translated values as expected with delayed translations. Steps to reproduce: - With a page with some content on a website in 2 languages - Open the website builder in the main language - Drop a custom snippet - Save - Bug: The change is immediate on the version in the second language (instead of being only available after user translated it) Delayed translations: 2d08f97c0778469b409fca23f2be5f5a98ce3df8 Copy translation in custom snippet: d3426b7714012e833caae10281cfb8433223299a Re-enabling delayed translations: 03a85b13b2c46ef7174123d902e95d5103031c6c task-5474184 Forward-Port-Of: odoo/odoo#263032 Forward-Port-Of: odoo/odoo#245850
This update fixes an issue where payment reminders weren't being sent to newly duplicated subscriptions. The root cause was a shared 'last_reminder_date' field preventing new reminders from triggering. The fix sets this field to 'false' for copied subscriptions, ensuring reminders are sent as expected.
Original PR description
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new…
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago 3. Confirm the subscription 4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token" 5. Go back to the previously created subscription (see that a reminder email has been added in the chatter) 6. Duplicate the subscription and confirm the duplicate 7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again 8. There are no reminder for the duplicate subscription Issue: The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120 Solution: Set `copy=False` on the field `last_reminder_date` opw-6167356 Forward-Port-Of: odoo/enterprise#116335 Forward-Port-Of: odoo/enterprise#115509
This update corrects a previous issue where reminder attachments were incorrectly set to lower follow-up levels for invoices. The change ensures that invoices are always linked to the correct follow-up level, improving the accuracy of reminder workflows and preventing mismatched alerts. This enhances the reliability of our accounting processes.
Original PR description
Previously(https://github.com/odoo/enterprise/commit/105d3bff49d486b8ecd943e77d635fe011b5e361), `_update_followup_line_on_move_lines` could downgrade AMLs when executed with a lower follow-up level, as all lines were recomputed without considering their current level. Additionally, invoices with a higher follow-up level were also included in lower level reminder attachments. With this commit, `unreconciled_aml_ids` are filtered to exclude lines that already have a higher follow-up level, preventing downgrade and aligning the attachments with the triggered follow-up level.
This update fixes an issue where the cost of kits was incorrectly calculated in sales orders. Specifically, when a kit BoM had multiple components, the system was multiplying the cost by the batch size instead of the correct component quantity. This change ensures accurate cost calculations for kits, preventing overcharging on sales.
Original PR description
### Issue: When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360…
### Issue: When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30. ### Cause: The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`. ### Steps to Reproduce: - Costing Method = AVCO, Inventory Valuation = Automated - Comp A (cost 10), Comp B (cost 20), Kit X (cost 0) - Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B - Create and confirm a SO for 1 x Kit X - Expected SO line cost: 30 - Actual SO line cost: 360 Solution: This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs. opw-5969310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259005 Forward-Port-Of: odoo/odoo#253406
This update prevents unauthorized users from viewing or modifying assets linked to invoices. Previously, users without the correct access groups could cause errors when interacting with invoices containing assets. This change ensures only authorized users can access asset information, improving data security and preventing potential misuse.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#115053 Forward-Port-Of: odoo/enterprise#112890
This update fixes an error in the manufacturing report that incorrectly calculated quantities and costs when products were produced in different units of measure (e.g., Kg vs. Ton). The fix ensures accurate reporting of production quantities and costs, providing more reliable data for financial analysis.
Original PR description
Steps to reproduce:
- Create a product W1 with UoM = Kg with the following BoM:
- Component C1: 1 unit, cost = $1
- Create and confirm MO1:
- Produce 1 Kg of W1 → total cost = $1
- Create and confirm MO2:
- Produce 1 Ton of W1 → total cost = $1000
- Open the Manufacturing Report and group results
Problem:
- qty_produced ≈ 1.001 instead of 1001
- unit_cost average ≈ 1000 instead of 1
Expected behavior:
- qty_produced = 1001
- unit_cost average = 1 (consistent across MOs)
The manufacturing report (`mrp.report`) incorrectly converts quantities from move UoM to product UoM, leading to wrong `qty_produced` and `qty_demanded` values when different units of measure are used
The current implementation uses:
sm.quantity / uom.factor * uom_prod.factor
This inverts the conversion ratio. As a result:
- 1 Ton is converted to 0.001 Kg instead of 1000 Kg
opw-6097098
Forward-Port-Of: odoo/enterprise#116322
Forward-Port-Of: odoo/enterprise#113979This update corrects a problem that prevented Odoo from properly submitting Dutch VAT returns (SBR) when dealing with multiple companies within a single VAT unit. The fix ensures the correct closing entry is used, resolving a technical error that caused submission failures. This improves the reliability of the Dutch VAT reporting process.
Original PR description
In a multi-company/multi-branch setup where multiple entities form a single VAT unit, Odoo generates a closing entry for each branch/company during the tax closing process. When attempting to submit the Dutch VAT return via Digipoort (SBR), the wizard gathers these entries via `closing_move_ids`. However, the code subsequently tries to set the resulting recordset as `closing_entry_id` on `l10n_nl_reports.sbr.status.service`, which results in a traceback: `ValueError: Expected singleton: account.move(id1, id2, ...)` This occurs because `closing_entry_id` is a `Many2one` which requires a single record (singleton), but the system provides all closing moves from the tax group. This commit fixes the issue by filtering the closing moves to only target the one associated with the return company, ensuring a singleton is passed to the message posting logic. Issue introduced by: 647699eeb4b8a1cc37ca074fa57844871c5086c1 opw-6106081 Forward-Port-Of: odoo/enterprise#116237
This update resolves an error that was preventing the generation of the Swiss Master Data report. The issue stemmed from a formatting error in the report's template, which has now been corrected. This ensures accurate reporting for Swiss payroll data.
Original PR description
Currently, generating the Swiss Master Data report raises an error ### **Steps to reproduce:** 1) Install `l10n_ch_hr_payroll` with demo data. 2) Switch to a Swiss company. 3) Navigate to `Payroll >…
Currently, generating the Swiss Master Data report raises an error ### **Steps to reproduce:** 1) Install `l10n_ch_hr_payroll` with demo data. 2) Switch to a Swiss company. 3) Navigate to `Payroll > Reporting > Master Data`. 4) Create a new report and click Generate Data. ### **Error:** IndentationError: expected an indented block after 'else' statement on line 116 ### **Root Cause:** The QWeb template had a conditional block using `t-elif` followed by an empty `t-else` at [1]. During template compilation, this generated a Python `else` statement without a body, leading to an IndentationError. [1]- https://github.com/odoo/enterprise/blob/b77984b3a9fb1b35c07e152a0f86aaf4d430e2c0/l10n_ch_hr_payroll/report/l10n_ch_wage_type_report.xml#L44 ### **Fix:** This commit prevents the error by removing the empty `t-else` block and ensuring `category_ids` are properly evaluated by computing their codes and checking if they include `BASIC`, `ALW`, or `DED`. **opw-6107565** Forward-Port-Of: odoo/enterprise#113808
This pull request contains several fixes and improvements to the o_spreadsheet module, primarily focused on enhancing chart rendering and stability. These changes address issues like clipping, error messages, layout problems, and data handling, resulting in a more reliable and user-friendly spreadsheet experience. The updates improve chart visibility and prevent common errors.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d13c0d7cf6 [FIX] chart: ensure chart values remain visible (remove clipping) [Task:…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d13c0d7cf6 [FIX] chart: ensure chart values remain visible (remove clipping) [Task: 5993132](https://www.odoo.com/odoo/2328/tasks/5993132) https://github.com/odoo/o-spreadsheet/commit/59869606fd [FIX] Gauge chart: error message in the side panel [Task: 6179300](https://www.odoo.com/odoo/2328/tasks/6179300) https://github.com/odoo/o-spreadsheet/commit/64089ca63b [FIX] pivot: fix design panel layout [Task: 6148708](https://www.odoo.com/odoo/2328/tasks/6148708) https://github.com/odoo/o-spreadsheet/commit/2c7a21e5a1 [FIX] grid overlay: unhide buttons visibility [Task: 6127335](https://www.odoo.com/odoo/2328/tasks/6127335) https://github.com/odoo/o-spreadsheet/commit/ada24eeeb1 [FIX] Charts: Do not cast dates x-values as numbers [Task: 6146610](https://www.odoo.com/odoo/2328/tasks/6146610) https://github.com/odoo/o-spreadsheet/commit/af21534b71 [FIX] charts: Do not cast empty values as 'count' [Task: 6146610](https://www.odoo.com/odoo/2328/tasks/6146610) https://github.com/odoo/o-spreadsheet/commit/168e9b0bae [FIX] package: add missing types dependency [Task: 6140820](https://www.odoo.com/odoo/2328/tasks/6140820) https://github.com/odoo/o-spreadsheet/commit/a00c3c07d5 [FIX] pivot: `getPivotCellFromPosition` will throw on invalid formula [Task: 6109696](https://www.odoo.com/odoo/2328/tasks/6109696) https://github.com/odoo/o-spreadsheet/commit/f47a77b7f0 [FIX] zoom: scorecard chart rendering with zoom [Task: 6072348](https://www.odoo.com/odoo/2328/tasks/6072348) https://github.com/odoo/o-spreadsheet/commit/f031b4bd17 [FIX] format: don't humanize scientific format [Task: 6068353](https://www.odoo.com/odoo/2328/tasks/6068353) https://github.com/odoo/o-spreadsheet/commit/9c1ffd5e50 [FIX] Data filter : clear/select all button [Task: 6075166](https://www.odoo.com/odoo/2328/tasks/6075166) https://github.com/odoo/o-spreadsheet/commit/231c82e9f5 [FIX] chart: figure sometime still exist after chart deletion [Task: 6107235](https://www.odoo.com/odoo/2328/tasks/6107235) https://github.com/odoo/o-spreadsheet/commit/3fbd43465d [FIX] side_panel: preserve spaces in DV values and fix color mapping [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) https://github.com/odoo/o-spreadsheet/commit/8ae166d5d8 [FIX] side_panel: stabilize list criterion color sync [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a crash that occurred when preparing future online food delivery orders. The issue stemmed from an incorrect date format, which has now been corrected to ensure smooth preparation display functionality. This improves the reliability of order preparation workflows.
Original PR description
### In this commit: Fixes a crash in the preparation display when handling future online food delivery orders. The issue was caused by an invalid delivery time format. This is resolved by properly passing the delivery time as a Number in the utils. Task-[5960176](https://www.odoo.com/odoo/project/1737/tasks/5960176) Forward-Port-Of: odoo/enterprise#116517 Forward-Port-Of: odoo/enterprise#108298