Daily updates from Odoo
Monday, January 26, 2026
8 changes · saas-18.2
Resolved issues and error corrections
This update corrects a discrepancy in a sales subscription test. The test previously incorrectly prioritized pricelists based on a default partner setting. The fix ensures consistent pricelist ordering, resolving a minor test issue and maintaining accurate subscription pricing calculations.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit a840e4250666 changed a `sale_subscription` test as pricelist ordering was changed. Before, it was `sequence asc, id desc`, now it is `sequence asc, id asc`. However, in the updated tests, it expects the first pricelist created with sequence 4 to be before the second pricelist with sequence 2. This was only happening due to default pricelists getting set as the `specific_property_product_pricelist` if the partner has no country assigned to them. Solution -------- As the behavior is now identical for partners with or without a country assigned to them, we can resolved the test setup by giving both pricelists an identical sequence, making the ordering fall back on `id` like a840e4250666 intended. opw-5385213 Related: https://github.com/odoo/odoo/pull/241736 Forward-Port-Of: odoo/enterprise#103116
This update fixes an issue where the 19%I tax code (9) was missing from Datev exports for expense journal entries. The problem stemmed from how payment amounts were aggregated during the export process, leading to data loss. This ensures accurate tax reporting in Datev.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791 Forward-Port-Of: odoo/enterprise#105379 Forward-Port-Of: odoo/enterprise#102548
This update resolves a test failure in Odoo's web_studio module caused by a missing dependency. The fix ensures that tests accurately check for the presence of required modules, preventing false failures when related modules like 'account_edi' are not included in the test setup. This improves test reliability and stability.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list. Forward-Port-Of: odoo/enterprise#104879
This update fixes an issue where the FedEx rate selection process was failing when the requested currency didn't match the Fedex account settings. The team has implemented a change to consistently use 'PREFERRED' as the rate type, ensuring accurate rate calculations and preventing errors.
Original PR description
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the…
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means `d['rateType'] == rating_result['actualRateType']` is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`. Solution ----- In the request we send, we hardcode `'rateRequestType': ['PREFERRED']` so we can look for a match using 'PREFERRED' as a prefix of `rateType`. The Fedex API lists all possible values of the enum `rateType` https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html <details> <summary>Enum values as per the API</summary> "enum": [ "INCENTIVE", "NEGOTIATED", "PAYOR_ACCOUNT_PACKAGE", "PAYOR_ACCOUNT_SHIPMENT", "PAYOR_CUSTOM_PACKAGE", "PAYOR_CUSTOM_SHIPMENT", "PAYOR_LIST_PACKAGE", "PAYOR_LIST_SHIPMENT", "PAYOR_RETAIL_PACKAGE", "PAYOR_RETAIL_SHIPMENT", "PREFERRED_ACCOUNT_PACKAGE", "PREFERRED_ACCOUNT_SHIPMENT", "PREFERRED_CUSTOM_PACKAGE", "PREFERRED_CUSTOM_SHIPMENT", "PREFERRED_INCENTIVE", "PREFERRED_LIST_PACKAGE", "PREFERRED_LIST_SHIPMENT", "PREFERRED_NEGOTIATED", "PREFERRED_RETAIL_PACKAGE", "PREFERRED_RETAIL_SHIPMENT", "RATED_ACCOUNT_PACKAGE", "RATED_ACCOUNT_SHIPMENT", "RATED_CUSTOM_PACKAGE", "RATED_CUSTOM_SHIPMENT", "RATED_LIST_PACKAGE", "RATED_LIST_SHIPMENT", "RATED_RETAIL_PACKAGE", "RATED_RETAIL_SHIPMENT", "UNKNOWN" ], </details> There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe. ----- Ticket: opw-5482949 Forward-Port-Of: odoo/enterprise#105156
This update resolves a bug where the serial number assigned to products in delivery pickings was incorrectly updated, leading to inaccurate inventory tracking. The fix prevents changes to serial numbers when a delivery is in the 'ready' state, ensuring correct inventory management and reporting. This improves data accuracy for stock levels.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993 Forward-Port-Of: odoo/enterprise#105338
This update fixes an issue where the TPAR report incorrectly calculated gross paid amounts for certain vendors, leading to export failures. By including asset_cash accounts in the report calculation, the system now accurately reflects payment amounts and prevents errors, ensuring reliable financial reporting.
Original PR description
Behavior before: Exporting the TPAR report could fail with an error indicating that the GST amount exceeded the gross paid for certain vendors. Some payment lines were excluded from the SQL query,…
Behavior before: Exporting the TPAR report could fail with an error indicating that the GST amount exceeded the gross paid for certain vendors. Some payment lines were excluded from the SQL query, leading to discrepancies in the report. Behavior after: The SQL query has been updated to include all relevant payment lines, including those in asset_cash accounts. This ensures that the gross paid is calculated correctly, allowing the TPAR report to be exported without errors. Root Cause: The previous query only considered asset_current and liability_current accounts, ignoring asset_cash accounts. This omission caused the gross paid amount to be understated relative to the total GST paid. Steps to Reproduce: 1. Create a vendor bill. 2. Navigate to the Bank Reconciliation page (Accounting → Dashboard → Bank Journal). 3. Create a bank statement line for the bill amount. 4. Validate the statement line with the corresponding invoice line. 5. Generate the TPAR report — the payment amount should now be correctly included. OPW: 5148697 Forward-Port-Of: odoo/enterprise#102700 Forward-Port-Of: odoo/enterprise#99874
This update addresses a limitation in the account online synchronization process. Previously, a consent link expired after 30 minutes, preventing users from managing their data permissions. We've implemented a new consent token system, linked to the user, to ensure ongoing control over data synchronization.
Original PR description
In this commit:bf5b7d0 we introduce a message on the account_online_link to be able to manage the consent. (one needed fix in this commit:https://github.com/odoo/enterprise/commit/1c84804fd3f0c0d1d23916b9f6a388616f66ac7e) This commit will change the way we manage the consent since the access token is in fact available only for 30 min, so the link in the chatter would not work. We decided to have a consent token which is a uuid4 encoded in base64 (url safe) and link it to the odoofin user. task-5187621 Forward-Port-Of: odoo/enterprise#105254 Forward-Port-Of: odoo/enterprise#105202
This update removes outdated test code related to exchange rate precision in the l10n_mx_edi module. A previous fix inadvertently left this code in place, and this PR ensures a cleaner and more streamlined testing environment. This resolves a minor technical issue.
Original PR description
The PR #102557 fixed an issue with exchange rate precision for Solution Factible. However, its forward ports for 18 (PR #104195) and saas-18.2 (PR #104673) did not properly delete some of the old test code. This PR deletes that code. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) Forward-Port-Of: odoo/enterprise#105339