Daily updates from Odoo
Friday, January 23, 2026
18 changes · 17.0
Resolved issues and error corrections
This update fixes a potential issue in the Point of Sale reporting system where rounding errors could incorrectly identify small cash differences as non-zero. This meant the system might remove legitimate cash transactions, leading to inaccurate reporting. The change ensures accurate cash difference calculations by accounting for rounding, improving the reliability of financial reports.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 resolves an issue where using certain reserved words (like 'constructor') as customer names caused errors in reporting. The change prevents the system from incorrectly interpreting these names, ensuring customer data can be accurately displayed and processed. This improves the reliability of customer reporting.
Original PR description
Steps:
- Have a customer named "constructor" (or any valid json prototype key value)
- Install `sale_management`
- Create a sale order with "constructor"
- Open Reporting -> Customers
- Traceback `Caused by: TypeError: groupedDataPoints[key].push is not a function`
This problem occurs because we use the client name directly in an object, and “constructor” already exists in all objects but is not initialized correctly, which raises a traceback.
One solution is to use `let object = Object.create(null)` instead of `let object = {}`, which prevents inheritance of `Object.prototype` properties.
https://github.com/odoo/odoo/blob/5e74f04ff35ed3efa25be295567be41f42024692/addons/web/static/src/views/graph/graph_model.js#L451-L457
opw-5474691This 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
This update resolves an issue where customer invoices sent via Peppol were generating duplicate attachments, leading to a cluttered user experience. The change ensures that attachments are updated instead of created anew, preventing this duplication and streamlining the invoice process. This improves the clarity and efficiency of invoice management.
Original PR description
When sending a customer invoice via Peppol, the system creates duplicate attachments (4 instead of 2 expected), cluttering the chatter and the attachment sidebar. This commit: - Implements a search-and-update logic for attachments to ensure idempotency (updates existing instead of creating duplicates). task-5438951 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#241130
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 a customer complaint regarding test data using the name "Deco Addict". The system has been updated to consistently use "Acme Corporation" in all demo and test data, preventing user confusion. This ensures a cleaner and more accurate demonstration experience.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/odoo#245205
This pull request resolves a customer complaint regarding demo data. The name "Deco Addict" was replaced with "Acme Corporation" to prevent users from mistakenly associating test data with actual business transactions. This ensures a cleaner and more accurate demo experience.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105151
This update fixes an issue where the 19%I tax code (9) was missing from Datev exports for expense journal entries. The problem occurred due to how payment amounts were aggregated, leading to inaccurate data transfer. This ensures consistent and compliant tax reporting for 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
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 fixes an error in the FAIA report that incorrectly classified partners as suppliers. The change allows partners to be recognized as both customers and suppliers, resolving an issue caused by credit notes. This ensures accurate reporting of financial transactions within the SAFT report.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924
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
This update resolves a technical issue that was causing crashes during the import of accounting data. The fix prevents a specific error related to incorrect data handling, ensuring that import processes run smoothly and reliably. This improves the stability of our accounting reports and reduces the risk of data loss.
Original PR description
Fixes crash caused by #97263