Daily updates from Odoo
Friday, January 23, 2026
10 changes · 17.0
Resolved issues and error corrections
This update fixes an issue where zero-percent taxes (NT/EXEMPT) were incorrectly filtered during downpayment creation in the Arabic localization. Previously, these taxes weren't accurately reflected, leading to incorrect calculations. This change ensures that all taxes, including zero-percent NT/EXEMPT amounts, are properly accounted for in downpayment transactions.
Original PR description
Taxes 0% NT and 0% EXEMPT should not be fixed taxes. This is causing issue in some cases such as downpayments, where those taxes needs to be present, but fixed taxes are filtered at the creation of the downpayment. opw-5815953
This update fixes an issue where the account online synchronization link stopped working due to the short lifespan of access tokens. We've implemented a new consent token system – a unique, secure identifier linked to the user – to ensure reliable consent management and continued synchronization functionality.
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
A recent upgrade process experienced errors when using the l10n_id module, specifically during tax migration. This fix resolves a problem where the migration script incorrectly created multiple 'base' lines, leading to an error. This ensures smoother and more reliable upgrades for Odoo users with the Belarusian accounting module.
Original PR description
Encountered an issue during upgrade from v16 with existing l10n_id installed on the DB. The script will try to force create the tax and create extra `repartition_line_ids` which is causing multiple "base" line to be added and trigger the `ValidationError`. Upgrade request: [3442445](https://upgrade.odoo.com/odoo/request/3442445) Upgrade task: [5314508]( https://www.odoo.com/odoo/70/tasks/5314508) --- 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 failure location wasn't correctly populated when completing quality checks through the smart button. Previously, the system defaulted to a fixed location, regardless of the user's selection. This change ensures users can accurately specify the failure location during quality check completion, improving data accuracy and reporting.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”. - Create a quality point with the following configuration: Measure on: Quantity Product: P1 Operation Type: OP1 Failure Location: WH/Stock/Shelf 1 - Create a reception for one unit of P1. - Mark it as "To Do". Problem: When you click on the quality check and then fail it, a wizard opens allowing you to select the quantity to fail and the failure location: https://github.com/odoo/enterprise/blob/17.0/quality_control/wizard/quality_check_wizard.py#L78-L81 However, if you access the quality check from the smart button and complete the quality check, the wizard is not displayed, and the failure location is forced to WH/Stock. Opw-4350512
This update resolves an issue where planning work orders linked across different manufacturing order (MO) groups resulted in a validation error. The fix ensures that work orders are correctly planned even when blocked by work orders from other MOs, preventing a date calculation failure. This improves the reliability of production planning.
Original PR description
Steps to reproduce the issue: - Create a storable product “P1” with the following BoM: -Operation: OP1 - Create a MO to produce one unit of P1. - Duplicate this MO. - Confirm both MOs. - Plan both…
Steps to reproduce the issue:
- Create a storable product “P1” with the following BoM:
-Operation: OP1
- Create a MO to produce one unit of P1.
- Duplicate this MO.
- Confirm both MOs.
- Plan both MOs.
- Navigate to the Work Orders Planning page:
- Move the work order of the second MO to the next day.
- Block the work order of the first MO by the work order of the second MO.
- Go back to the MO list:
- Unplan both MOs.
- Attempt to replan the first MO.
Problem:
A validation error is triggered:
“The operation cannot be completed:
Create/update: a mandatory field is not set.
Model: Production Order (mrp.production)
Field: Start (date_start)"
When trying to plan the work order, we’ll checks if it is blocked by
another work order and skips planning if this is the case. Since the
work order is blocked by one from another MO, it remains unplanned:
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1510-L1512
As a result, the work order remains unplanned and does not have a
"leave_id" set. Consequently, the calculation for the "date_start" and
"date_finished" on the MO fails because the min function returns False.
This leads to an attempt to write a False value to the MO’s "date_start"
field:
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1518-L1521
opw-4393415This update corrects an inconsistency in stock level reports for subcontracting. Previously, only internal warehouse locations were considered when calculating available quantities. Now, the system will accurately reflect stock levels across all locations, including those used for subcontracting, leading to more reliable reporting and decision-making.
Original PR description
**Description of the issue/feature this PR addresses:** It is skipped because currently only internal location as part of a warehouse are being taken into consideration. **Current behavior before PR:** Inconsistent behavior when trying to retrieve stock levels in reports at a certain time (product views) **Desired behavior after PR is merged:** Now quantity available take these locations into consideration. Info: @wt-io-at --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing point of sale (punto de venta) functionality from being properly enabled within the l10n_ar_edi module for Arabic VAT reporting. The fix ensures accurate VAT calculations and reporting for sales transactions, addressing a previous limitation. This improves compliance and reporting accuracy for businesses using the Arabic VAT reporting features.
Original PR description
Tarea: 62909 Forward-Port-Of: odoo/enterprise#105104
This update resolves an issue where some accounts were missing from XLSX exports of the General Ledger due to a NULL value in the 'include_initial_balance' field. This change ensures all accounts are included in the batch export, addressing a reported problem impacting customer reporting.
Original PR description
…LSX export We recently added a batch export for the xlsx file for the General Ledger as the basic export was having a memory error. To handle it, we first determine which accounts are present in the report by running a custom query which uses the computed boolean field include_initial_balance. It appears with some customers' tickets that this field is set to NULL in their databases. This value might potentially come from a legacy artifact from an older Odoo version. I have not found a way to reproduce the issue without running a custom query. For customers having this field set to Null, it results in an incomplete export where these accounts are missing. opw-5787298 opw-5797979
This update fixes an issue where users could successfully make payments through expired Sales Orders. The system now automatically prevents payment attempts when a Sales Order's expiry date has passed, ensuring accurate financial records and preventing potential payment errors. This improves the reliability of the payment process.
Original PR description
## Issue: Payment link should expire if payment is expired. #### Steps to reproduce: 1- Create a new quotation. 2- Set the expiry date in the past. 3- Open the action menu and generate a payment link. 4- Open the payment link and pay. Expected result: The payment should fail if the so is expired. opw-5478691
This update resolves errors in the SAF-T export process for Romanian companies when partner information (country or name) is incomplete. Specifically, it corrects issues related to generating the RegistrationNumber and prevents errors during report generation, ensuring accurate financial reporting for Romanian businesses.
Original PR description
Fix SAF-T export errors when partners have no country or name. For Romanian companies, the RegistrationNumber should be generated as “04 + partner ID” for customers not subject to VAT and with unknown CNP, without including the country code. Steps to reproduce country issue: - Configure a Romanian company with l10n_ro_saft installed - Create a contact without a country - Create and validate an invoice for this contact - Export the SAF-T file from the General Ledger report You you will get a TypeError because you cant concatenate Bool and String. Steps to reproduce name issue: - Create a main contact - Add a child contact without a name - Change the child type to “Company” - Create and validate an invoice - Export the SAF-T file from the General Ledger report This prevents KeyError when printing the first 70 characters of the partner name in the report. opw-5499918