Tuesday, February 24, 2026
8 changes · 17.0
Enhancements to existing features
This update ensures Odoo complies with recent changes from the Uruguayan tax authority (DGI) regarding Electronic Sales Reports (CFE). Specifically, a new option is added for exporting goods under a mandate, and the reporting of reference documents (credit/debit notes) now includes currency and exchange rate information when needed.
Original PR description
Purpose: The DGI introduced changes in CFE version 25. The following changes below needs to be implemented for legal compliance.
Required Changes:
- Introduce a new selection value,("91", "Export under Mandate")for field, l10n_uy_edi_cfe_sale_mode. This option is required when documenting export operation performed as a mandating entity, where the definitive export will be carried out by a third party.
- The reference document(credit note or debit note) of an existing account move will need to send:
- Amount (MntCFEref)
- Currency (TpoMonedaRef)
- Exchange Rate (TpoCambioRef) if the currency is not Uruguayan Pesos
task-5419331
task-5419331This update adds tests to ensure accurate calculation of Swiss payroll payslips. Specifically, it verifies the correct handling of different wage types and monthly wage types defined for employees, alongside multiple leave requests across various months. This improves the reliability of payroll reporting in the Odoo Enterprise system.
Original PR description
This commit adds tests to the `_compute_l10n_ch_swiss_wage_ids` function to verify **Wage Types** in payslips across multiple months and with different **Monthly Wage Types** defined in an employee’s contract, as well as multiple leave requests occurring in different months. task-5906677
Resolved issues and error corrections
This update resolves an issue where bill creation from email users resulted in an error due to company mismatches. The fix forces the correct company association when a bill is created from an alias, ensuring compatibility and preventing the 'Incompatible companies' error. This ensures bills are created correctly when initiated via email.
Original PR description
Issue can be reproduced on a trial/SaaS db: - Have an alias [alias] set up for vendor bills journal - Create another company [company2] - Add user [user] that can only access [company2] - Add email…
Issue can be reproduced on a trial/SaaS db:
- Have an alias [alias] set up for vendor bills journal
- Create another company [company2]
- Add user [user] that can only access [company2]
- Add email [mail] as login/mail of that user
- Now from [mail] send a message, with pdf attachment, to [alias]
Issue: Mail will bounce back with an error
```
odoo.exceptions.UserError: Incompatible companies on records:
- “Draft Bill ” belongs to company “False” and “Journal” (journal_id: \'Vendor Bills\') belongs to another company.
```
This does not occur if [MAIL] is not associated with an user of company2
When the email is processed, the system recognizes the user email and
we have a minimal context.
Then, during move creation, `_compute_company_id` is called to assign
the company to the first accessible company.
However no accessible company is found because:
- current company would be the vendor bill journal's company ([company1])
https://github.com/odoo/odoo/blame/0aa729fd6492139869bab299d1091a54fd443c54/odoo/addons/base/models/res_company.py#L390
- because of the lack of `accessible_companies` in environment,
accessible companies is [user]'s company, [company2]
https://github.com/odoo/odoo/blame/0aa729fd6492139869bab299d1091a54fd443c54/odoo/api.py#L682
As result, no company is assigned to the newly created move and it
raises an error when inconsistencies are checked
A solution is to force the company whenever we detect the move is
created from an alias
[1] Full traceback
```
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 1389, in message_process
thread_id = self._message_route_process(message, msg_dict, routes)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 1282, in _message_route_process
thread = ModelCtx.message_new(message_dict, custom_values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/addons/account/models/account_move.py", line 5894, in message_new
move = super(AccountMove, move_ctx).message_new(msg_dict, custom_values=values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 1424, in message_new
return self.create(data)
^^^^^^^^^^^^^^^^^
File "<decorator-gen-67>", line 2, in create
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 479, in _model_create_multi
return create(self, [arg])
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/addons/account/models/account_move.py", line 3125, in create
moves = super().create(vals_list)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "<decorator-gen-40>", line 2, in create
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 480, in _model_create_multi
return create(self, arg)
^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 267, in create
threads = super(MailThread, self).create(vals_list)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<decorator-gen-0>", line 2, in create
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 480, in _model_create_multi
return create(self, arg)
^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5018, in create
records._check_company()
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4368, in _check_company
raise UserError("\
".join(lines))
odoo.exceptions.UserError: Incompatible companies on records:
- “Draft Bill ” belongs to company “False” and “Journal” (journal_id: \'Vendor Bills\') belongs to another company.
```
opw-4232030This update resolves an issue where the point-of-sale blackbox couldn't process products with negative prices, preventing easy refunds for deposit products. Now, the blackbox correctly handles both positive and negative prices within the same order, enabling seamless refund processing.
Original PR description
Previously, the blackbox did not accept the products to have a negative price. This was not allowing easy deposit products to be refunded. We now allow negative price product and mix of lines of positive and negative quantities as long as all the lines have the same price sign.
This update fixes a critical issue in the invoice processing cron job for Brazil (l10n_br_edi_services). Previously, the cron job was inefficient and prone to failure, rolling back progress and consuming IAP credits. The fix now processes invoices in smaller batches, committing progress after each, ensuring reliable and accurate invoice handling.
Original PR description
The cron searched with limit=batch_size and only retriggered when >batch_size records were found which never happens. It also ran all invoices in a single transaction so one failure rolled back all progress while IAP credits were already consumed. Search batch_size + 1 so remaining invoices are detected, and commit after each invoice to preserve progress. opw-5954211
This update resolves an issue where manufacturing orders created with complex BoMs would fail due to mismatched UoM settings. The fix ensures that stock movements accurately reflect the BoM's UoM specifications, preventing errors and improving the reliability of barcode-based manufacturing processes. This change corrects a previous bug related to BoM and product UoM discrepancies.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196)
This update corrects a bug where invoices created by users in timezones before Saudi Arabia could be incorrectly dated in the future, leading to rejection by ZATCA. The change ensures invoice dates are properly aligned with Saudi Arabian time, preventing future invoicing issues and maintaining compliance.
Original PR description
In odoo/odoo#236865 we decided to allow clients to backdate invoices by letting them use the `invoice_date` field for the invoice date and use the current time as the issue time because we are not supposed to use a dummy value for time. This created an issue where if a user in a timezone before SA tries to invoice a document around midnight using the current date in SA the datetime created will be in the future which will lead to the invoice being rejected by ZATCA. This commit makes sure we normalize the selected date wrt to the current datetime in saudi arabia so that we never accidentally invoice into the future. task-5890423 opw-5373067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error in how project budget spending was calculated, leading to incorrect percentage displays. The fix ensures that negative expense budgets are handled properly, accurately reflecting spent amounts and remaining balances. This improves the accuracy of project cost tracking.
Original PR description
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings…
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings page 3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates. 4. Click Add Budget button and open the budget wizard. 5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000). 6. Create a Vendor Bill using the same analytic account with an amount of 1000. 5. Confirm the bill. 6. Go back to Project's Updates and click New button to view the budget summary. Observation: --------------------------- The budget summary displays incorrect signs and percentages in Activities summary, for example: ``` -10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining. ``` This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000). Issue: --------------------------- The project cost (already negative) was negated again when computing the spent amount in https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs. Solution: --------------------------- For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly. After the fix: ``` 10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining. ``` opw-5357854