Thursday, March 5, 2026
9 changes · 19.0
New functionality added to Odoo
This update adds the ability to integrate with popular food delivery platforms like GoFood and GrabFood, enabling restaurants to accept orders directly through Odoo. This provides a streamlined ordering process and expands sales channels.
Original PR description
task-3726822
This update introduces a dedicated wizard in Odoo for Romania to streamline VAT return preparation. Users can now generate and download VAT returns in XML format directly through this new wizard, replacing the previous submission process which triggered report submissions instead.
Original PR description
Before this commit: - Romania had no VAT submission wizard. When user clicked the submit button, the report will be submitted instead. After this commit: - The VAT submission wizard will open. Users can download VAT returns in XML format through a submission wizard. cmt PR: https://github.com/odoo/enterprise/pull/104906 task-5423935
This update introduces support for online food delivery platforms like GrabFood and GoFood within Odoo Enterprise. The changes include a foundational code structure for future platform integrations and initial connections to these popular delivery services, streamlining order fulfillment for restaurants.
Original PR description
Introduction: This commit integrate with multiple platform order platform in SEA. This commit also implement a skeleton code base for future adding additional platform order provider. As of now, we included GoFood and GrabFood to begin with. Features list: - Skeleton code for platform order - GrabFood integration - GoFood integration task-4215826 task-3726824
Resolved issues and error corrections
This update corrects a bug that caused duplicate Dimona activities to be created in the payroll system. Specifically, when updating employee versions or running automated tasks, the system was incorrectly generating multiple activities for the same employee. This fix ensures that only one Dimona activity is created, streamlining payroll processing and preventing data inconsistencies.
Original PR description
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on…
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium employee > new > payroll > contract > start_date: any date (this should create a first dimona activity) settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually `_trigger_l10n_be_next_activities` in `hr.version` of `l10n_be_hr_payroll` is duplicating Dimona activities on records that already have one. We check if a dimona activity already exists for a given `hr.employee` before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it. [tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380) Forward-Port-Of: odoo/enterprise#96423
This update corrects inaccuracies in the XML files used for processing Swedish payments (SEPA). Specifically, it ensures the correct BIC number is used, removes a misleading placeholder value, and allows users to select the appropriate payment version for 'iso_se' even without a SEPA payment method configured. This improves the accuracy and reliability of Swedish payment processing.
Original PR description
We currently have customizations for the iso20022 xml file for payments in Sweden. But those customizations aren't correct. This commit fix multiples issues: 1) In DbtrAgt, we sometimes have bankgiro information. But this node should always contain the BIC number for Swedish payments. 2) The _get_cleaned_bic_code method was replacing the real bic code with a fake value like 'SE:Bankgiro', but this seems to be wrong. None of the SE banks ask for this BIC, so we remove it. 3) The sepa_pain_version field is supposed to tell Odoo which pain version to use. But the problem is this field is computed, and only editable once the user set the SEPA payment method, but for iso_se, we want to let the user choose as well, even if he didn't add SEPA as payment method. This commit change the invisible on the field, so it can be edited as soon as iso_se is in the journal payment methods. task-5427570 Forward-Port-Of: odoo/enterprise#105536
This update resolves a crash occurring when posting expense entries with the Avalara Avatax integration. The change adjusts how Avatax handles expense move types, specifically addressing a 'KeyError' related to 'in_receipt'. This ensures smoother expense processing for US-based employees using Avatax.
Original PR description
Currently, the expenses flow with Avatax integration crashes when posting the expense entry. Steps to reproduce: - Have an employee with an address in the US. - Enable 'Detect Automatically' in the Avalara fiscal position. - Create an expense for the employee, paid by Employee. - Submit > Post Journal entry > Post Expense. Action will be blocked by a traceback reporting error `KeyError: 'in_receipt'` Analysis: After [1] expense journal entries are now 'in_receipt'. The dictionary in account_avatax does not take into account this move type. This provides a fallback to 'Any' for any other move types [1] https://github.com/odoo/odoo/commit/f835ac0c8adb49d04bed746fd624b8976cc32991 opw-5872768
This update fixes an issue where flexible calendar employees were incorrectly displaying unavailable days in planning and related modules. The change ensures that only public holidays and leaves are reflected as unavailable, providing a more accurate representation of employee availability. This improves the planning process for teams using flexible work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
Forward-Port-Of: odoo/enterprise#109422
Forward-Port-Of: odoo/enterprise#105521A recent update caused a disruption in our SEPA direct debit payment processing. Customers were unable to complete payments using this method due to a technical error. This fix resolves the issue, restoring reliable SEPA direct debit functionality.
Original PR description
Issue: --- The SEPA direct debit is broken. Steps to reproduce: --- 1- Enable SEPA direct debit in payment providers. 2- Add something to cart and try paying using SEPA direct debit. You get the error: `payment.provider object has no attribute company.` Cause: --- This is introduced after #250326. opw-5993720 Forward-Port-Of: odoo/enterprise#109672
This update resolves an issue where by-products tracked by serial numbers were incorrectly showing extra lines in the shop floor manufacturing order view. The change ensures that by-products only display lines that have been manually added, aligning with the intended workflow. This improves the clarity and accuracy of shop floor data.
Original PR description
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in…
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views). Steps to reproduce: 1. Create a bill of materials for a final product 2. Add a consumable component 3. Create an operation without steps 4. Add a by-product tracked by serial number 5. Specify that the by-product is produced in the operation above 6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves" 7. Create a manufacturing order for the BOM and confirm it 8. Open the Shop Floor view from the MO 9. Observe the extra line for the by-product in both overview and work center views Root cause: The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button. Solution: Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled. Task-5431295 Forward-Port-Of: odoo/enterprise#109574 Forward-Port-Of: odoo/enterprise#103260