Tuesday, January 13, 2026
18 changes · saas-18.3
Enhancements to existing features
This update modifies the Brazilian tax code list to comply with the latest regulatory requirements. Specifically, it adds a 'DEPRECATED' marker to expiring codes and introduces new tax codes for Brazil. This ensures continued compliance and accurate tax reporting.
Original PR description
This **PR** updates the NCM code list as per latest requirement. It appends `DEPRECATED` at the end of expires codes. Also it introduces a few new codes. **task**-5381617 Forward-Port-Of: odoo/enterprise#102009
This update improves the process of managing sender relationships within our PEPPOL integration. Instead of requiring a complete unlink, users can now automatically unregister the sender, streamlining the configuration and reducing potential data inconsistencies. This change simplifies the process for users and ensures data accuracy within the PEPPOL system.
Original PR description
Allow unregistering to sender instead of unlinking directly. task-5395262 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243125 Forward-Port-Of: odoo/odoo#239822
Resolved issues and error corrections
This update fixes an issue where tax invoices generated in Thai were incorrectly displaying the branch name in English. The change ensures the branch name is translated based on the language setting of the customer's account, improving accuracy and compliance with Thai tax regulations. This improves the user experience for Thai customers.
Original PR description
Currently, l10n_th_branch_name is not translatable. Regardless of the language setting, it is printed in English on the tax invoice. This PR addresses that. Task-5438534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242484
This update resolves a technical error that occurred when a specific customer type ('Consumidor Final') was selected in the Ecuadorian Point of Sale (POS) system. The fix ensures that a customer is always identified, which is a requirement for accurate reporting and compliance in Ecuador. This prevents tracebacks and improves system stability.
Original PR description
Step to reproduce: - install `l10n_ec_edi_pos` - open pos - ensure "Consumidor Final" is selected as partner - open partner list and deselect the partner Observation: - we get a traceback Cause: - we try to set a partner, without proper checks - Also, in the Ecuadorian localization there should always be a customer selected Fix: - rewrote `selectPartner` function to allow following things for EC localization 1. ensure a customer is always selected, a specific one or "consumidor final" 2. when refunding with "consumidor final" customer, changing partner is allowed opw-5350570 Forward-Port-Of: odoo/enterprise#103868 Forward-Port-Of: odoo/enterprise#102221
This update fixes a confusing issue where eTIMS configuration warnings were displayed for companies outside of Kenya. Now, the warnings are only shown for Kenyan businesses, ensuring accurate validation and a better user experience. This improves the relevance of the eTIMS checks.
Original PR description
Before: In multi-company setups, the eTIMS configuration warning was shown even when working in companies that are not based in Kenya. This resulted in confusing and irrelevant warnings for users using other localizations. After: The eTIMS configuration warning is now limited to Kenyan companies only. Non-Kenyan companies are no longer impacted, keeping the validation relevant while preserving the intended eTIMS behavior. task-5462334 Forward-Port-Of: odoo/enterprise#103291
This update corrects a visual issue where the 'Update Prices' button appeared on sales orders even when no pricelist was configured. The fix ensures the button is only displayed when a pricelist is active, preventing confusion and ensuring accurate pricing calculations. This improves the user experience for sales order creation.
Original PR description
**Steps to produce:** - Install the `Sales` module. - Enable `Pricelists` in settings and set the `default quotation template`. - Create a new Sales Order. **Issue:** - The `Update Prices` button is…
**Steps to produce:** - Install the `Sales` module. - Enable `Pricelists` in settings and set the `default quotation template`. - Create a new Sales Order. **Issue:** - The `Update Prices` button is visible even when no pricelist is set on the sales order. **Root cause:** - In the onchange logic (see [1]), show_update_pricelist is set to True based solely on the presence of order lines, without checking whether a pricelist is defined. **Solution**: - Update the condition so that button is shown only when sale order line is present and the current pricelist value is not the previous one. [1]: https://github.com/odoo/odoo/blob/849ec71acbaea0061fd4b13888a486e4aebb6463/addons/sale/models/sale_order.py#L801-L803 Before: <img width="1215" height="466" alt="image" src="https://github.com/user-attachments/assets/f29b1ccf-eec8-4114-b4c9-a8083947ad28" /> After: <img width="1207" height="428" alt="image" src="https://github.com/user-attachments/assets/e358b633-d11b-413d-94c4-3837c430eac4" /> opw-5414897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241812
This update fixes a potential issue with how Odoo tours mock the Clipboard API, particularly in headless environments. By delaying cleanup until the action's listener has finished, the system avoids delays and errors related to browser permissions or waiting for user input. This ensures tours function reliably across different browsers and configurations.
Original PR description
Reliably mocking Clipboard API calls in tours should be done in two steps: - the step that will actually do the call should do the patching, followed by the actual action. - the cleanup should only be done in the following step to ensure the action's listener has actually finished. This commit applies this principle to avoid the "cleanup" to be executed before the action's listener has actually reached the call to the Clipboard API (because of slower processing, slower network...), which would defeat the mocking purpose (and either get the browser to indefinitely wait for the user's clipboard usage approval or a permission error depending on the browser's default behavior). Note: this was mainly brought to light by the new Chrome 143+ default policy which revoke all permissions in headless mode. Forward-Port-Of: odoo/odoo#243280
This update fixes a potential issue with how Odoo tours mock the Clipboard API, particularly in headless environments like Chrome. The change ensures the API call is properly mocked in two steps, preventing delays and errors caused by slower processing or network connections. This improves tour reliability and avoids browser permission prompts.
Original PR description
Reliably mocking Clipboard API calls in tours should be done in two steps: - the step that will actually do the call should do the patching, followed by the actual action. - the cleanup should only be done in the following step to ensure the action's listener has actually finished. This commit applies this principle to avoid the "cleanup" to be executed before the action's listener has actually reached the call to the Clipboard API (because of slower processing, slower network...), which would defeat the mocking purpose (and either get the browser to indefinitely wait for the user's clipboard usage approval or a permission error depending on the browser's default behavior). Note: this was mainly brought to light by the new Chrome 143+ default policy which revoke all permissions in headless mode. Forward-Port-Of: odoo/enterprise#103971
This update ensures that thumbnails are correctly updated on document shortcuts, even when accessed by public users. Previously, public users lacked thumbnail updates due to a system limitation. This change resolves a discrepancy where access to the document shortcut was lost, regardless of ownership.
Original PR description
Bug === 1. Create a request 2. Create a shortcut to that request 3. Share it to public 4. Public upload => The thumbnail is updated on the document, but not on the request. The reason is that the public user has `user_permission = none`, because he has only access with the token, and so we skip the thumbnail propagation. This has no sense, because if we don't have access on the document, we loose the access on the shortcut (even if we are the owner). Task-5485511 Forward-Port-Of: odoo/enterprise#102888
This update removes a previous permission that allowed inventory users to modify locations. This change was deemed too risky and outside the scope of their responsibilities. Testing confirms this restriction doesn't impact core inventory functionality.
Original PR description
During the development of the task of the PR https://github.com/odoo/odoo/pull/149149, this permission was added as a possible way to fix some found problems, but that's not the way to fix them, as allowing inventory users to modify locations is something very dangerous and out of scope of what an inventory user should do. Reverting the permission, and doing manual tests with an inventory user for doing a "update quantity" or a "inventory adjustment", there's no problem, so maybe that permission was needed in a past codebase. @Tecnativa Forward-Port-Of: odoo/odoo#243085
This update ensures that when importing electronic invoices, Odoo correctly identifies and uses existing bank accounts linked to the same supplier, regardless of the company where the invoice is being created. Previously, the system would incorrectly flag duplicate accounts, causing import failures. This change improves the efficiency of invoice processing.
Original PR description
Description of the issue/feature this PR addresses: Imagine a situation where a vendor is defined on a parent company and its bank account already exists. When importing an electronic invoice for…
Description of the issue/feature this PR addresses: Imagine a situation where a vendor is defined on a parent company and its bank account already exists. When importing an electronic invoice for that vendor on a child company, the search for a bank account linked to the same company would not find that pre-existing bank account on the parent company. When later trying to create it, the unicity constraint on (sanitized_acc_number, partner_id) would trigger, failing the import. Current behavior before PR: The electronic invoice cannot be imported if the same IBAN account already exists on the partner but on another company than the invoice being created, even though we are going to create the invoice for a partner linked to that other company. Desired behavior after PR is merged: Banks account already linked to the partner are found irrespective of the company, provided the partner (account holder) is the same. This should be correct since the res.partner.bank company_id is a related on res.partner. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242365
This update resolves a technical issue causing duplicate error messages in the Accounts Coverage Report. The fix ensures that identical report lines with the same name and code are no longer flagged as duplicates, improving report accuracy and user experience. This change impacts the reporting functionality within the Enterprise module.
Original PR description
Reproduce the bug: -Install Ireland(ie) reports -Enable debug mode -Go to Reporting>Balance Sheet>Accounts Coverage Report -The generated sheet should have false positive duplicates error Fix: Ignore the report lines that has the same name and the same code task: 5373732 Forward-Port-Of: odoo/enterprise#101311
This update resolves a validation error in Odoo Studio when users attempt to add help tooltips to fields in the Contacts list view. The issue stemmed from a missing 'help' attribute in the field definition, preventing proper validation. This change ensures that users can now customize field tooltips without triggering errors.
Original PR description
Steps to reproduce ================== - Install web_studio,contacts - Go to Contacts - Open the list view - Click on a field - Set a "Help tooltip" => Validation Error Invalid view Odoo Studio: res.partner.tree customization Cause of the issue ================== The help attribute is missing from the field definition opw-5379357 Forward-Port-Of: odoo/odoo#240261
This update resolves an issue where filtering work entries by country was not functioning correctly, leading to errors. The fix ensures country-based searches and filters work as expected, preventing module loading problems and improving data accuracy.
Original PR description
Issue: The country_id related field on work entries was not stored, causing domain filters and search on this field to fail and triggering client-side errors. Fix: Use search parameter on field to write function so field can be used safely in search domains and filters. Impact: Country-based filtering now works correctly without triggering module loader errors. Task: 5406904 Forward-Port-Of: odoo/odoo#239573
This update resolves an issue where the year field in certain reports was incorrectly formatted with a comma. The change removes this comma, ensuring accurate reporting data and consistent output for Belgian payroll calculations. This fix improves the reliability of financial reports.
Original PR description
. Remove the comma on the year filed on the crossponding reports task-5417861 Forward-Port-Of: odoo/enterprise#102143
This update fixes an issue where employee names were being incorrectly formatted in the payroll system. The change ensures that employee first and last names are consistently and correctly assigned, aligning with Swiss legal name requirements. This improves data accuracy for payroll reporting and compliance.
Original PR description
* Fix _compute_l10n_ch_legal_name method to correctly assign first_name and last_name from employee name (was previously reversed) * Update all SwissDEC test data to use correct "FirstName LastName" format instead of "LastName FirstName" to match the corrected computation logic task-5102851 Forward-Port-Of: odoo/enterprise#95252
This update resolves an issue that prevented users from creating payslips for contracts without a defined working schedule in the Belgian payroll module. The fix ensures that the system defaults to the company's standard calendar when a contract lacks a specific schedule, preventing a traceback error. This improves the reliability of payslip generation for all Belgian companies.
Original PR description
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll…
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 2) Create an employee with no working hours. 3) Create a contract for that employee with: - Work entry source as Attendance - No Working Schedule - State should be open/running 4) Click the Payslip smart button to create a new payslip for that contract. 5) A traceback occurs **Error:** ``` ValueError: Expected singleton: resource.calendar() ``` **Cause:** When creating a payslip for a contract with no resource_calendar_id, the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` through self.resource_calendar_id. Since the contract's calendar lacks a resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472 **Solution:** If the contract or employee does not have a resource_calendar_id, use the default resource_calendar_id from the company instead. opw-5237559 Forward-Port-Of: odoo/enterprise#99217
This update corrects small errors in the balance sheet and profit & loss reports for Danish accounting (l10n_dk_reports). The changes involve fixing incorrect formulas and text labels, representing a logical improvement to report accuracy. This ensures the reports align with Danish accounting standards.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/0d431fe2cc6556a040888ecc5d6a71be4a435447 we introduce a new balance sheet report for 2026 but there was a mistake in the sign of a formula and in the text of a line. Same for the profit and loss, some errors in sign of accounts and naming. The errors don't come from a ticket but more of a logical fix, those errors were probably an oversight during development. no task id Forward-Port-Of: odoo/enterprise#103830