Tuesday, January 20, 2026
22 changes · saas-18.3
Enhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, only 12-digit numbers were accepted, but now 8-digit numbers – including those prefixed with 'UA' for European companies – are supported. This ensures accurate data entry for Ukrainian businesses and avoids errors.
Original PR description
with this commit:- - We are adding support for Ukrainian Tax ID numbers of 8 digits, which was 12 previously. - The following formats are now accepted: - National company numbers: 8 digits (e.g., 12345678) - European company numbers: 8 digits prefixed with 'UA' (e.g., UA12345678) - Individual numbers: 12 or 10 digits (e.g., 123456789012) - This change allows users to enter Ukrainian TINs that were previously incorrectly rejected due to length restrictions. task-5414806 opw-5373469 Forward-Port-Of: odoo/odoo#243258
This update streamlines the accounting process for Ecuadorian businesses within Odoo. It simplifies expense categorization by consolidating accounts and adds a new account for direct employee benefits, improving organization and accuracy. Additionally, it prevents unnecessary reconciliation for income-related expense accounts.
Original PR description
Improve the distribution of expense and cost of revenue accounts in Ecuadorian localization We avoided not creating subcategories of expenses by eliminating the group called "Other employee benefit plan expense", which generated duplicity in the accounts. We fixed this by merging the accounts into the main "Employee benefit plan expense" group. Additionally, the account "Other employee benefits' was added to record any other benefits granted directly by the Ecuadorian companies. This ensures a better organization of the accounting setup. Mark as non-reconcilable the expense accounts (salaries and wages, travel expenses, contributions, etc) to avoid unnecessary reconciliation processes, these accounts are income statements and they are not accounts payable/receivable, therefore, they are closed at the end of the accounting period ### opw-4846355 Forward-Port-Of: odoo/odoo#208047
This update enhances the testing process for paying invoices using bank statement data. A new test helper has been introduced to streamline and standardize these tests, ensuring more reliable invoice payment processing within the Odoo system. This improves the overall stability and accuracy of invoice payments.
Original PR description
Forward-Port-Of: odoo/odoo#244281
Resolved issues and error corrections
This update resolves an issue that occurred when users attempted to 'Show', 'Force CFDI', or 'Retry' operations on MX electronic invoices. The problem stemmed from a system error when payments were cancelled or deleted, leading to incorrect invoice data. This fix ensures a smoother process for generating and submitting CFDI invoices.
Original PR description
When user is clicking any of the `Show`, `Force CFDI`, or `Retry` buttons in l10n_mx_edi.document error occurs. Steps to reproduce: - Install `l10n_mx_edi` module > Switch to `MX Company` - Setup `MX Electronic invoicing` in settings - Create a New Invoice > Send > Select `CFDI` > `Pay` > `Update Payments` - Payment > Cancel that Payment > Back to Invoice > CFDI(Notebook page) > Click on `Show` or `Force CFDI` or `Retry` Traceback: `ValueError: Expected singleton: account.move()` This error occurs when a payment is created and later deleted or cancelled, which results in an empty `move_id` in l10n_mx_edi.document. sentry-7113267386 Forward-Port-Of: odoo/enterprise#102248
Code cleanup and technical improvements
This update enhances the testing process for Odoo's Arabic accounting modules (l10n_ar). Specifically, a new testing method and refactoring of the test suite ensures more reliable and accurate verification of these modules, improving overall system stability and compliance.
Original PR description
- Implemented a working `assert_json` method on `AccountTestInvoicingCommon`, that also supports the ignore_schema system and quick save using the `SAVE_JSON` test tag. - Refactors the whole test suite of `l10n_ar*` modules to use the new accounting test helpers properly. task-4891206 Forward-Port-Of: odoo/odoo#244466 Forward-Port-Of: odoo/odoo#242309
This update fixes a technical issue that caused errors when Odoo servers were stopped. Specifically, the server shutdown process was incorrectly closing database connections before the system was fully ready, leading to errors. This change ensures a smoother and more reliable server shutdown process.
Original PR description
When the server stops, pool errors can occur. It's due to the server stop function calling `sql_db.py@close_all()`. If this occurs before the dispatcher loop wakes up, the `__exit__` function of the cursor context manager will raise an error, because the connection has already been popped from the pool. As for interface errors in [1], pool errors should be ignored during server shutodwn. runbot-229800 [1]: https://github.com/odoo/odoo/pull/99849 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#244481
This update corrects a technical issue related to canned response testing in the live chat feature. Previously, outdated tests were causing problems. This PR removes these unnecessary tests, ensuring the live chat functionality operates smoothly and reliably.
Original PR description
In [1], auto focus was removed for canned responses in the navigable list. The intent was to avoid conflicts with emojis. In [2], the shortcut for canned response was changed to `::` and the auto focus behavior was restored. However, tests added in [1] were not removed. Since they were fragile (negative assertion), they are passing most of the time. This PR removes the tests that are now outdated. runbot-233358 [1]: https://github.com/odoo/odoo/pull/170900 [2]: https://github.com/odoo/odoo/pull/192953 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#244472
This update corrects a technical issue related to how Odoo processes multiple payment moves during payroll registration. The fix ensures that payments are handled efficiently, improving the reliability of payroll calculations. This change impacts the HR Payroll module.
Original PR description
There was an error where we weren't batching when we were selecting several moves at the same time when registering a payment. We fixed that and this test needs to be adapted.
This update corrects a technical issue where Saudi partner address data was being unintentionally cleared when related contacts were created or updated. The fix prevents data loss by stopping the propagation of incorrect values from related contacts to the main partner record. This ensures accurate address information for all Saudi partners.
Original PR description
All Saudi partners use the saudi_o_address_format. As a result, contacts created from a company partner also inherit this address format, which includes fields such as street, city, zip, and state. These fields are set as read-only by the address format. When child_ids are written on the parent partner, those read-only fields are written with False values. Due to the address field synchronization between parent and related contacts, these False values are then propagated back to the parent partner, causing its address data to be cleared. This fix prevents address fields from being unintentionally reset when related contacts are created or updated. task-5349050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents errors when creating inter-company invoices by ensuring payment terms are compatible with the receiving company. Previously, invoices automatically used the payment term of the originating company, causing posting failures. Now, the system correctly applies company-specific payment terms.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both…
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both companies. * Create a **payment term** assigned to **Company A**. * Create a **sale order** from Company A to Company B using that payment term. * Confirm the sale order and create the **invoice**. * Post the invoice to trigger the inter-company vendor bill. **Observed behavior:** * The generated **vendor bill** for Company B uses **Company A’s payment term**. * Posting fails because the payment term is incompatible with Company B. **Cause:** * Inter-company document creation reuses payment terms without checking whether they belong to the **target company**. * Payment terms from the source company can be propagated to the destination document. **Fix:** * Ensure only **company-compatible** payment terms are applied when creating inter-company sale orders, purchase orders, and invoices. * Payment terms belonging to a different company are now ignored. **NOTE**: test is not implemented due to technical limitations. Inter-company invoice synchronization relies on UI context propagation that cannot be replicated in unit tests. The payment term validation logic depends on web client context flags that are only set during real UI interactions, not programmatic execution. opw-5392745 Forward-Port-Of: odoo/enterprise#102986
This update resolves an issue that prevented users from exporting SAFT reports for Austrian companies without defined contacts. The fix eliminates a redundant check, ensuring the system correctly validates contact information before generating the SAFT file. This improves the reliability of the SAFT export process for Austrian businesses.
Original PR description
[FIX] l10n_at_saft: saft export traceback When no contacts is defined on the company and the user tries to download the SAFT to XML, a traceback is shown Steps to reproduce the traceback: - Install l10n_at_saft module and create an Austrian company with no contacts - Create a few invoices for this company - Open the General Ledger report and export SAFT to XML, the traceback should appear no-task Forward-Port-Of: odoo/enterprise#104633 Forward-Port-Of: odoo/enterprise#104144
This update resolves an issue where the Amazon connector wasn't correctly identifying key delivery modules for UPS, FedEx, USPS, and DHL. By mapping these modules, the connector now functions properly with these major shipping carriers, ensuring accurate order processing and fulfillment within the Amazon integration.
Original PR description
Amazon connector did not recognize the _rest delivery modules (ups_rest, fedex_rest, usps_rest, dhl_rest). This maps them to the correct carrier names, consistent with existing mappings. Forward-Port-Of: odoo/enterprise#102606
This update resolves an issue where embedded buttons in the Odoo Control Panel were getting cropped due to incorrect height calculations during dragging. The fix ensures that the buttons display their actual size, preventing visual distortion and improving the user experience. This change improves the overall usability of the Control Panel.
Original PR description
The `o_embedded_actions` buttons are getting cropped when they are long enough. This is due to the `overflow-hidden` property which is now applied when no element are actively dragged. When an element is dragged after a css transformation, eg. the `o_dragged_embedded_action`, `getBoundingClientRect()` is returning the element height with the transformation. This creates an excess height on the `o_embedded_actions` due to the placeholder button having it's transformed height instead of the button height. Using offsetHeight returns the element size without the transform. Note this is not done on the width, because the width without the transform can lead to text-truncation. task-5225696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234120
This update fixes a test that was intermittently failing due to inconsistencies in how inbox messages are marked as read. The change ensures the test waits for the initial message fetch, preventing a common failure scenario and improving the reliability of inbox read marking. This enhances the overall stability of the Odoo messaging system.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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
This update ensures that optional product images are only shown when the system is configured to display them. Previously, images were always shown, even when disabled, leading to a cluttered user experience. Now, a placeholder is used when no image is available, aligning the display with the 'Show product images' setting.
Original PR description
Before this commit: =================== - When the `Show product images` setting was disabled, the optional products UI still displayed product images. - If an optional product did not have an image, the UI displayed the image's alt text - Also when the product don't have image, the combo popup and product card just display the product name. After this commit: ================== - Optional product images are displayed only when the `Show product images` configuration is enabled. - If the optional product doesn't have an image, we will display an image placeholder instead of alt text. - If there is no product image, the combo popup and product card will display the image placeholder. Task: 5480181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue with Turkish invoice documents (l10n_tr_nilvera) by correcting the default journal type. Previously, the default was set incorrectly, which could have led to improper accounting. Now, the default is set to 'purchase' to ensure accurate and compliant document handling.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding was mistakenly carried over from annual reports due to a previous split in the codebase. This ensures accurate VAT reporting for Italian businesses.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104228 Forward-Port-Of: odoo/enterprise#103852
This update fixes a potential issue where users could create duplicate tax names in different branches of Odoo. Previously, the system only checked for duplicates within the branches a user could access. Now, Odoo checks all branches to guarantee unique tax names, preventing conflicts and ensuring data accuracy across the entire organization.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243185
This update resolves an issue where GS1 barcodes triggered a validation error, preventing users from scanning products correctly. The fix allows the system to gracefully handle GS1 barcodes that are misinterpreted as dates, ensuring consistent product scanning functionality within the Odoo Enterprise system.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in main_menu and explicitly reset parsed_results to False, allowing the normal main menu resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product, picking, or location detection still works as expected. opw-5357611 Forward-Port-Of: odoo/enterprise#104641
This update fixes a bug that occurred when users tried to change a tax lock date to a past date. The change prevents the system from generating incorrect default values for reports, ensuring accurate financial reporting. This resolves a potential error that could have impacted data accuracy.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable output. The change replaces newlines with spaces, ensuring names and descriptions remain clear and adhere to API specifications, improving the accuracy of VAT processing for Vietnamese businesses.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
This update streamlines the testing process for the Ar-EDI module by automatically verifying request data against JSON files. This change allows tests to run without external dependencies and simplifies updates to test data by using the `SAVE_JSON` tag.
Original PR description
This commit refactors the whole `l10n_ar_edi` test suite to use the new helpers, and made it possible for the test to (finally) be run without external mode. Now, when running these new tests, the test framework will by default assert the request data with their associated JSON file. When a change is made, new overwrites for the test files can be easily changed by just adding the `SAVE_JSON` test tag on the command to run the tests. task-4891206 Forward-Port-Of: odoo/enterprise#104742 Forward-Port-Of: odoo/enterprise#103370