Friday, February 27, 2026
11 changes · 17.0
New functionality added to Odoo
This update adds the ability to automatically process and export Peppol self-billing invoices, streamlining invoice handling for vendors. It allows for the creation of self-billed invoices based on specific journal settings, improving efficiency in international transactions. This enhancement supports compliance with Peppol standards.
Original PR description
Backport of 8c590efd369b to 17.0. In existing modules, added ability to receive via Peppol and decode BIS3 self-billing invoices as sale invoices. In new module account_peppol_selfbilling, added ability to export self-billed invoices and send them via Peppol. Vendor bills are considered to be self-billed invoices if they are created in a journal where the `is_self_billing` field is True. task-5865317
Enhancements to existing features
This update enhances the 'Unpaid' bill filter in the accounting module to now include draft vendor bills, providing a more complete view of outstanding payments. Additionally, the system now correctly filters out journal entries from the 'Unpaid' filter, ensuring accurate reporting. This improves financial visibility and reporting accuracy.
Original PR description
In this commit: - Updated the `Unpaid` filter to show draft bills in addition to posted bills. The filter now includes all non-cancelled bills with payment status `Not Paid` or `Partially Paid`. - Backported the logic from 18.0 to ensure journal entries are filtered out by checking that type is not equal to `journal_entry`. task-5900283
Resolved issues and error corrections
This update corrects a problem with how leave periods are calculated, specifically related to time zone differences. By using `request_date_from` and `request_date_to`, the system now accurately reflects leave interruptions, ensuring correct payroll processing for employees in Switzerland. This resolves potential discrepancies and improves data accuracy.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences. task-5966780
This update resolves an issue where importing data files with incorrect field definitions would cause a system error. The fix ensures that the system gracefully handles invalid field data during the import process, preventing crashes and improving data import reliability.
Original PR description
This traceback arises when the user imports a file with invalid fields on a model. To reproduce this issue: 1) Import a file with an invalid field ex:-(`in_group_44`) for a model (`Users`) Error:-…
This traceback arises when the user imports a file with invalid fields on a model.
To reproduce this issue:
1) Import a file with an invalid field ex:-(`in_group_44`) for a model (`Users`)
Error:-
```
KeyError: 'in_group_44'
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/base_import/models/base_import.py", line 1378, in execute_import
import_result = model.load(import_fields, merged_data)
File "odoo/models.py", line 1220, in load
if isinstance(model_fields[field_name], odoo.fields.One2many):
```
when the user tries to import a file with an invalid filed it leads to a traceback from here
https://github.com/odoo/odoo/blob/be611deca82c0f0e9c110d2ff35f3e081e94b3be/odoo/models.py#L1192
After applying this commit will resolve this issue by raising an exception
sentry-5093791365This update changes how payment errors are displayed to users. Instead of showing a technical exception, the system now presents a standard validation error, making it easier for users to understand and correct issues. This improves the overall user experience and reduces confusion.
Original PR description
Currently, we are showing an exception to the end user when the transaction operation fails from the below line https://github.com/odoo/odoo/blob/8b035af881a72048027072743f7ba80accd73109/addons/payment/controllers/post_processing.py#L57 Error: ``` Exception: retry ``` Which is not a valid case to show traceback to the end user, Instead of a traceback, it's better to raise a validation error. After applying this commit, the message should be shown as ValidationError sentry-5512362745
This update resolves an issue that occurred when a user deleted a warehouse and then attempted to create a new scrap. The fix prevents a traceback by ensuring a valid warehouse is selected during scrap creation, improving data integrity and preventing errors.
Original PR description
Currently, a traceback occurs when the user deletes a warehouse and tries to create a new scrap. To reproduce this issue: 1) Install `stock` without demo data 2) Archive the `warehouse` from the…
Currently, a traceback occurs when the user deletes a warehouse and tries to create a new scrap.
To reproduce this issue:
1) Install `stock` without demo data
2) Archive the `warehouse` from the stock configuration
3) Now create a new `Scrap` from `Inventory/Operations`
Error:-
```
KeyError: False
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1006, in onchange
todo = [
File "addons/web/models/models.py", line 1009, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1122, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6610, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 2954, in __get__
return super().__get__(records, owner)
File "odoo/fields.py", line 1206, in __get__
self.recompute(record)
File "odoo/fields.py", line 1421, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1394, in apply_except_missing
func(records)
File "odoo/fields.py", line 1443, in compute_value
records._compute_field_value(self)
File "addons/mail/models/mail_thread.py", line 416, in _compute_field_value
return super()._compute_field_value(field)
File "odoo/models.py", line 4936, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 100, in determine
return needle(*args)
File "addons/mrp/models/stock_scrap.py", line 38, in _compute_location_id
res = super(StockScrap, remaining_scrap)._compute_location_id()
File "addons/stock/models/stock_scrap.py", line 74, in _compute_location_id
scrap.location_id = locations_per_company[scrap.company_id.id]
```
When the user tries to create a new scrap without a warehouse a traceback occurs, because in the below lines `locations_per_company` is getting through the warehouse.
If there is no warehouse for that company the `locations_per_company` will be empty.
which leads to the above traceback when fetching a value from `locations_per_company`.
https://github.com/odoo/odoo/blob/0ac43fa3cffce83e88accda435f3315600af558a/addons/stock/models/stock_scrap.py#L64-L74
After applying this commit, it will resolve this issue by raising an usererror when there is no `locations_per_company`
sentry-5631303884This update resolves an issue where users experienced a type error when creating payroll pay slips with contracts that lacked an end date. The fix adds a necessary check to ensure the correct data types are used, preventing the error and allowing users to successfully generate pay slips. This improves the reliability of the payroll process.
Original PR description
Currently, a traceback occurs when the user tries to create a pay slip with a contract and without an end date. To reproduce this issue: 1) Install `hr_payroll` without demo data 2) Create a new record for `payroll/payslip/to pay` 3) Create a new contract then remove the `start date` and change the `end date` in the period. 4) An error will occur Error: - ``` TypeError: '<' not supported between instances of 'bool' and 'datetime.date' ``` Here in the below line, you can see that when the user only gives an end date and have a contract it leads to a type error. https://github.com/odoo/enterprise/blob/3f1c5535235646c0444acffe0bf4ecf756b6b73c/hr_payroll/models/hr_payslip.py#L1002-L1003 Note:- If the contract has an end date and the user gives the end date in the period, it also leads to Typeerror from different lines. After applying this commit, it will resolve this issue by doing an additional check. sentry-5635149758, 5405887212
This update fixes an error in the Timesheet/Planning Analysis report that incorrectly calculated hours for shifts starting or ending outside of regular workday times. The system now accurately determines the actual overlap between shifts and work schedules, ensuring more precise time tracking and reporting. This improves the reliability of time data used for payroll and analysis.
Original PR description
When a multi-day planning shift starts later than the workday start time or ends earlier than the workday end time, the Timesheet/Planning Analysis report was incorrectly calculating hours for those partial days. Before: - V17: Showed full working day hours (8h) for all days, resulting in incorrect totals - The system divided allocated_hours evenly across working_days_count, ignoring actual shift start/end times After: The report now calculates the actual time overlap between the shift and the working schedule for each specific day by: - Finding the intersection of shift times with work attendance periods - Excluding lunch breaks (day_period != 'lunch') - Computing actual hours worked per day instead of dividing evenly - Applied same logic to planned_hours, planned_costs, and difference fields - Added COALESCE to handle NULL values safely opw-5126359
This update resolves a performance issue that caused the editor to slow down or freeze when editing large documents. The fix eliminates a redundant check, significantly reducing the time it takes for editor interactions and improving the overall user experience. This change enhances the usability of the editor for users working with complex content.
Original PR description
Problem: When editing heavy content, each interaction can take up to 600 ms, sometimes freezing the editor completely. Cause: The `_isDirty` check is computationally expensive and is executed on…
Problem: When editing heavy content, each interaction can take up to 600 ms, sometimes freezing the editor completely. Cause: The `_isDirty` check is computationally expensive and is executed on every history step. This is unnecessary and leads to poor performance when handling large documents. Solution: Instead of recomputing `_isDirty` on each history step, directly mark the field as dirty whenever a history step is triggered. This provides a simpler and more efficient approach. Before fix: Each keyboard interaction to next paint takes around 200ms. <img width="582" height="306" alt="image" src="https://github.com/user-attachments/assets/bb215a97-f651-4e39-8419-06953aba2b8d" /> After fix: Each keyboard interaction to next paint takes around 40ms. <img width="610" height="178" alt="image" src="https://github.com/user-attachments/assets/1ff9ca36-457b-4015-9f30-4fed990c2ba3" /> opw-5892291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug in the Hungarian tax audit export process. Previously, changes to invoice data were unintentionally saved to the database, causing potential data inconsistencies. By ensuring data is flushed to the database before and after savepoints, this fix prevents these errors and maintains data accuracy.
Original PR description
At the moment, the Hungarian tax audit export wizard's `action_export` creates a savepoint with `flush=False`. The intention of this savepoint is to roll back the changes to `l10n_hu_edi_invoice_chain` once the savepoint exits. But because the changes to `l10n_hu_edi_invoice_chain` stay in cache, and the cache is not flushed before the savepoint is created nor cleared afterwards, those changes end up being committed to DB. Which is precisely what the savepoint was there to prevent. Solution: we use `flush=True` to make sure the cache is flushed before and cleared after the savepoint. task-none
This update resolves an issue where invoices sent to accounting partners (APs) were being rejected due to incorrect Electronic Address System (EAS) and Endpoint data. The fix prevents automatic recalculation of these values when VAT information is updated, ensuring invoices are correctly formatted and accepted by AP systems. This improves invoice processing and avoids the need for users to un-register and re-register their companies.
Original PR description
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice…
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice will be refused by the AP. The issue is that the EAS and Endpoint are automatically re-computed when you write on the VAT. It causes issues as the UBL will be filled with the values on the partner, resulting in a non-synchronised SBD and UBL, which will result in all new invoices to be in error. Their only solution would be to revert back the EAS/Endpoint on the partner, which will sometimes be blocked meaning they have to un-register->re-register Also adapt the query count, as we need to do a search in each compute. opw-5923552 opw-5924552 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249017