Friday, January 23, 2026
9 changes · 17.0
Enhancements to existing features
This update streamlines CRM email templates by removing unnecessary fields. This change ensures more data is captured in chatter, particularly without requiring a system upgrade, and prevents duplicate information from being sent. It’s a small improvement to data accuracy and efficiency.
Original PR description
- Remove newly added fields that can be replaced by existing keys present in `iap_mail.enrich_company` template to ensure we get more data in chatter without upgrade and avoid duplicate entries IAP PR: https://github.com/odoo/iap-apps/pull/1390
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 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 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
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 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 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