Daily updates from Odoo
Thursday, February 26, 2026
14 changes · 19.0
Enhancements to existing features
This update ensures that when creating invoices through the Point of Sale QR or URL in Mexico, the VAT (Value Added Tax) field is now required. This aligns with Mexican tax regulations and ensures accurate invoice generation for businesses operating in Mexico, improving compliance.
Original PR description
Made vat required if the selected country is Mexico at invoice address form when requesting an invoice through the point of sale qr or url. task-5392922
Resolved issues and error corrections
This update resolves a technical issue where the Odoo Enterprise system would crash if Avatax company credentials were not found. The fix ensures stability by handling the missing credentials gracefully within the system's code, preventing unexpected errors. This improves the reliability of Avatax integration.
Original PR description
When `_find_avatax_credentials_company` returns `None`, `_get_avatax_service_params` crashes accessing `.avalara_commit` on it. `_find_avatax_credentials_company` should probably return an empty `res.company` recordset when it cannot find a company, but for stability reasons we won't change the return value and instead fix it locally in `_get_avatax_service_params`. opw-5939708 Forward-Port-Of: odoo/enterprise#108192
This update streamlines the process of finding and creating bank accounts within Odoo Enterprise. The changes consolidate how bank accounts are handled across multiple modules, improving efficiency and reducing potential errors. This enhancement ensures consistent and reliable bank account management for financial transactions.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update resolves a bug where the 'Publish & Send' button was hidden in the 'Schedule by Resource' view. The previous fix incorrectly added a context variable, causing this issue. This change removes the problematic condition, restoring the button's visibility and functionality.
Original PR description
## Issue Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button. ## Cause The…
## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.
## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].
## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.
runbot-241028
Forward-Port-Of: odoo/enterprise#108333This update resolves an issue where a 100% discount on German POS Cert orders would cause an error. The change ensures the system handles this scenario correctly, preventing disruptions to order processing. This improves the reliability of the German POS Cert module.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/98869 opw-5240429 Forward-Port-Of: odoo/enterprise#108561
This update resolves a bug where the booking management page wouldn't refresh correctly. The fix ensures the booking view renders properly after a page refresh, improving the user experience for managing appointments within the POS system. This prevents disruptions and ensures accurate booking data is displayed.
Original PR description
Steps: ----- - Install pos_appointment and pos_urban_piper modules. - Open a session for an UrbanPiper-configured POS. - Open the Manage Booking page. - Refresh the page. Issue: ----- - The booking view is not rendered after a page refresh. Cause: ----- - An awaited request in the posStore setup caused the `ActionComponent` not to be rendered yet when the `doAction` was called. Fix: ----- - First render the `ActionComponent`, then fetch the action data, and finally call `doAction`, so the action is executed seamlessly without interruption. Task-5713125 Forward-Port-Of: odoo/enterprise#105629
This update resolves a technical issue preventing the scale certification module from correctly processing data sent by the new event manager. Previously, readings were reported as 'results' instead of actual values, causing scale readings to sometimes display as zero. This fix ensures accurate scale data reporting.
Original PR description
This PR fixes the lack of compatibility with the new event manager code sending result instead of value, fixing the weighing stuck at 0 in some situations Forward-Port-Of: odoo/enterprise#108583 Forward-Port-Of: odoo/enterprise#107974
This update resolves an issue where the tax report export button failed when companies had different VAT numbers and branches. The fix ensures the button correctly validates the company and branch selection, allowing users to export reports with multiple branches. This improves the reliability of tax reporting.
Original PR description
To reproduce the issue: - Create a company with a branch - Give the company and its branch different VAT numbers - Make both companies active in the company selector - Open the tax report - Click on gear icon - Click on the XML(l10n_lu_reports)/Export SAWT & QAP(l10n_ph_reports) button ===> The following error is raised: "Please select the main company and its branches in the company selector to proceed." This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierarchy are in the options => they're not => error. We can fix this by simply making the buttons branch_allowed. Followup on: https://github.com/odoo/enterprise/commit/34ba0609e984496f0dcc862f0d7a46c6721beab9 task-5416330
This update fixes an error in how holiday pay recovery is calculated for employees in Belgium with non-standard working schedules. Previously, the calculation used a default 38-hour week, leading to inaccurate deductions. Now, the system correctly uses the employee's actual weekly hours to ensure accurate holiday pay recovery amounts.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied. Forward-Port-Of: odoo/enterprise#108104 Forward-Port-Of: odoo/enterprise#106205
This update resolves a critical error that prevented users from submitting UK tax reports when the company's VAT value was left blank. The fix ensures that VAT is automatically set on the company record, allowing reports to be generated and sent to HMRC successfully. This resolves a blocking issue impacting UK tax compliance.
Original PR description
Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5 - Install l10n_uk_reports module - Keep the VAT value empty for the UK Company - On the Tax…
Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5
- Install l10n_uk_reports module
- Keep the VAT value empty for the UK Company
- On the Tax Report (GB), click Connect to HMRC
- Establish connection with HMRC
- After a successful connection, try to send the tax report to HMRC
- Traceback will appear
<details><summary>Exact Traceback</summary>
<p>
```
RPC_ERROR
Odoo Server Error
Occured on 100710704-master-all.runbot216.odoo.com on model account.report on 2026-02-11 12:50:03 GMT
Traceback (most recent call last):
File "/data/build/odoo/odoo/http/requestlib.py", line 632, in _serve_db
return retrying(serve_func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/retrying.py", line 52, in retrying
result = func()
^^^^^^
File "/data/build/odoo/odoo/http/requestlib.py", line 687, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/dispatcher.py", line 308, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 374, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/service/model.py", line 57, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2825, in dispatch_report_action
return report_to_call.dispatch_report_action(options, action, action_param=action_param, on_sections_source=False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2836, in dispatch_report_action
return report_method(model, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_uk_reports/models/account_financial_report.py", line 30, in send_hmrc
self.env['l10n_uk.vat.obligation'].import_vat_obligations(self.env.context['client_data'])
File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 124, in import_vat_obligations
self._get_vat(),
^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 111, in _get_vat
if vat.startswith(('GB', 'XI')):
^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'startswith'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3225:165)
at XMLHttpRequest.<anonymous> (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3231:13)
```
</p>
</details>
Reason:
- No VAT set on the current company.
Solution:
- Blocking level error for the user to set VAT on the current company.
Task-5929908
Forward-Port-Of: odoo/enterprise#107150This update fixes a technical issue where certain Intrastat codes (99450000, 99500000, 99600000 & 99700000) were incorrectly marked as expired. The update ensures these codes remain active, aligning with official Belgian regulations outlined in the Intrastat manual. This ensures accurate reporting for international trade data.
Original PR description
99450000, 99500000, 99600000 & 99700000 were erroneously expired. They are still active : https://www.nbb.be/doc/dd/onegate/data/intrastat_manual_basis_en.pdf page 13 Forward-Port-Of: odoo/enterprise#108451
This update fixes an issue where VAT amounts were incorrectly displayed as zero in XML reports generated from manual journal entries. The fix removed a filtering condition that was incorrectly excluding standard journal entry lines from VAT calculations, ensuring accurate VAT reporting for MA Company users.
Original PR description
## Issue: When creating a manual journal entry with a deductible tax, the entry was included in the XML export, but the VAT amounts were all set to 0 ## Cause: The SQL query used to compute VAT amounts included an extra condition on display_type to be 'tax' However, journal entry lines are standard product lines and should not be excluded by this condition As a result, the amounts (MHT, TVA, TTC) were incorrectly computed as 0 in the XML ## Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA Company - Create a Journal Entry (Any account, Debit: 100, Taxes: 10% 150) - Open the Tax Report for the current month - Export the XML using the gear icon Before the fix, the value for mht, tva and ttc where all 0 opw-5226529 Forward-Port-Of: odoo/enterprise#108644
This update fixes a build error in the Odoo Enterprise payroll module related to warning data. The previous test incorrectly counted employees, failing when multiple employees triggered the same warning. The fix now accurately checks for the number of times an employee's ID appears in the warning data, ensuring correct build stability.
Original PR description
> To be FW'ed till `saas~19.1` only. issue: - the test written in commit 0653104 checks the employees' count in warning from `warning_data` dictionary - which will not work in case of multiple employees fulfilling that warning as the warning searches models' data, instead of just test data. fix: - instead of relying on `warning_data['count']` for invalid employee, checked how many times does the invalid employee's ID appear in the `warning_data`. runbot-240910 task-5958862
This update prevents incorrect data from being written to applicant records when OCR processes CVs. Specifically, it stops the OCR email address from overwriting existing business or user contacts, which could have led to inaccurate applicant information. This ensures data integrity within the recruitment process.
Original PR description
When OCR processes a CV, it writes extracted name/email/phone onto the applicant, which then propagates to the linked res.partner via the email_from inverse. This causes data corruption in two cases: - The CV was forwarded: the OCR email belongs to the candidate but email_from is the forwarder's address. Writing OCR data would overwrite the forwarder's partner with the candidate's details. - The existing partner is a company contact (parent_id set) or is linked to a user account (user_ids set). Writing OCR data would overwrite user/business partner with the candidate's details. Both guards are applied and added tests that check the flows. task-5949635