Daily updates from Odoo
Tuesday, February 24, 2026
22 changes · 17.0
Enhancements to existing features
- CFE series now support numbers. Document numbers could have a sequence of 1 alphanumeric character + 7 digits or 2 alphanumeric + 7 digits. Users will now be expected to input a valid document number. With the new alphanumeric series, it will be difficult to support a reformatting of document number. task-5419331 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
- CFE series now support numbers. Document numbers could have a sequence of 1 alphanumeric character + 7 digits or 2 alphanumeric + 7 digits. Users will now be expected to input a valid document number. With the new alphanumeric series, it will be difficult to support a reformatting of document number. task-5419331 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 corrects a visual imbalance in the layout of Knowledge articles, specifically addressing an uneven gutter size in the editor. The change ensures a more balanced and professional appearance for all Knowledge articles, improving user experience. This fix addresses a minor aesthetic issue and enhances overall consistency.
Original PR description
There is a visual imbalance in the Knowledge article layout where horizontal padding is asymmetric in the editor content. How to reproduce: Open any Knowledge article and observe the horizontal spacing. The right gutter appears larger than the left one. Issue: The layout applies padding-left: var(--editor-gutter-size) and padding-right: calc(var(--editor-gutter-size) + 2rem), which creates a larger right gutter and makes the article content appear visually unbalanced. Resolution: Make the horizontal padding symmetric by applying the same offset on both sides using a logical property.This preserves sufficient spacing for floating UI elements while improving visual balance and ensuring consistency. Task-5222643
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 fixes an issue where the X/Z report incorrectly identified refund lines based on negative quantity. Now, refund lines are correctly selected based on negative amounts, ensuring accurate reporting of returned items. This improves the reliability of sales data analysis.
Original PR description
Previously, on the X/Z report, the refund lines were the lines with a negative quantity. Now they are chosen if they have a negative amount. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that free products offered through loyalty programs are correctly applied as 100% discounts within the Point of Sale (POS) system. Previously, this behavior wasn't consistently replicated, and this fix corrects that to align with existing loyalty reward logic. This ensures accurate and consistent reward application for customers.
Original PR description
In the module sale_loyalty, a free product is handled as the reward_product from the loyalty reward with a 100% discount. We copy this behavior in the POS module. opw-4397720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This 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 fixes an issue within the departure wizard by switching to a more reliable method for archiving employees. Previously, using 'toggle_active' caused problems; now, 'action_archive' ensures employees are properly removed from the system. This change aligns with a related enterprise issue and improves data integrity.
Original PR description
When archiving an employee from the departure wizard, use the action_archive method instead of toggle_active. Related to odoo/enterprise#100437 task: 5354002
This update fixes a problem where employees marked as archived would still have incorrect appraisal dates, causing conflicts when managing appraisal plans. The change ensures that archived employee appraisal dates are cleared, preventing these errors and improving the accuracy of appraisal settings.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002
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 a labeling error in Odoo invoices for Qatar. Previously, the invoice amount description used "Rial" instead of the correct "Riyal". This change ensures accurate currency representation for Qatar-based accounting, improving data clarity and compliance.
Original PR description
Steps to reproduce: 1- Install Accounting and 'l10n_qa' modules 2- Switch to Qatar company and enable "Total amount of invoice in letters" under accounting settings 3. Issue an invoice and preview it The issue: The description of the amount uses "Rial" Expected behavior: The amount should use "Riyal" opw-5919587
This update fixes an issue where sales order statuses were displayed in an incorrect alphabetical order within the sales Kanban view. The change ensures that statuses appear in the correct, logical order (Cancelled, Quotation, Sale Order, Quotation Sent), improving the user experience and data clarity. This was a minor visual inconsistency.
Original PR description
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as…
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as Cancelled, Quatation, Sale order, Quatation sent. Root cause: --- - When we perform Group By > Status, the method `web_read_group()` is executed. then in chain `_web_read_group()` calls `read_group()` without providing any explicit `orderby`. Inside `read_group()`, if orderby is not provided, it sets the order to the grouped field itself. - Inside `_read_group()`, the SQL query constructed with an order by clause on the grouped field (state). Therefore, the values are retrieved in alphabetical order as `cancel, draft, sale, sent`. Solution: --- - Define `group_expand` on the `state` field. During `read_group()`, `_read_group_fill_results()` calls this method and reorders the groups accordingly. - This overrides the alphabetical SQL order returned by `_read_group()` and ensures the correct logical status order in Kanban view. opw-5497664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a problem with how leave periods are tracked, specifically related to time zone differences. By updating the system to use 'request_date_from' and 'request_date_to' instead of 'date_from' and 'date_to', the system now accurately reflects leave interruptions, ensuring correct payroll calculations.
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`, resolving any inconsistencies that may arise due to time zone differences. task-5966780
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
A test was failing due to access restrictions when dealing with archived company subscriptions. This update uses `sudo` to ensure the test user has the necessary permissions, resolving the error and maintaining proper subscription functionality. This ensures the subscription test suite continues to run reliably.
Original PR description
Following https://github.com/odoo/odoo/commit/6b7b83449739932aa8420ef8fcd888116e3c0f8a, the test was failing because of an access error
` AccessError(_("Access to unauthorized or invalid companies."))`
Fix: use `sudo` to avoid access errors due to the user no longer
having access to the archived company after its archival.
runbot-238373This update fixes an error in the Spanish Profit & Loss reports where specific accounts (7950 and 7957) were incorrectly placed. The change aligns with official Spanish tax documentation, ensuring accurate reporting for Spanish fiscal localization packages. This ensures compliance with Spanish tax regulations.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664
This update addresses a critical maintenance task, updating tax codes within the Avatax module after a 4-year period. This ensures continued accurate tax calculations for our business operations. A future enhancement will allow users to initiate this update automatically, but a manual update is required now.
Original PR description
It's been 4 years since the last update [1]. No codes were removed. At some point it would be nice to add this to the avatax_sync_company_params() method so it can be initiated by the user. But we need to update this file regardless, and the mechanism would need to be smart enough to not cause duplicates when e.g. the user has synced it themselves, we then update the csv and they then update the module. [1] https://github.com/odoo/enterprise/pull/30220 opw-5928245
This update fixes an issue where SII invoices were not correctly formatted, preventing successful confirmation. The update replaces specific XML tags in the DTE template to align with SII's invoice requirements, ensuring invoices meet regulatory standards and avoid processing errors.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484
Code cleanup and technical improvements
This pull request streamlines the management of our internationalization (I18n) files by re-exporting the ‘base.pot’ file. Previously, this file was not readily accessible for translation updates, leading to potential delays. Now, it’s more easily available for translators to contribute to our global support for different languages.
Original PR description
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