Daily updates from Odoo
Sunday, February 22, 2026
20 changes
1 change
Resolved issues and error corrections
This update resolves a technical issue within the Odoo Enterprise tax reporting module (l10n_co_dian) that could cause data to be reset. The fix ensures that key data elements are properly maintained, preventing disruptions to tax reporting processes. This improves the reliability of tax calculations and reporting.
Original PR description
task-5500236 Forward-Port-Of: odoo/enterprise#108227
3 changes
Resolved issues and error corrections
This update resolves issues preventing early bill printing with the Italian fiscal printer. The fix addresses a traceback caused by incorrect data handling and syncing, ensuring the printer correctly generates and prints receipts when the 'early print' option is enabled. This improves the restaurant's operational efficiency by allowing for immediate receipt generation.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#108161
Forward-Port-Of: odoo/enterprise#105511This update resolves an issue where the RO and HR EDI modules incorrectly relied on Peppol BIS3 constraints. Previously, an empty EndpointID was causing problems with sending invoices, but this has now been corrected based on prior work. This ensures proper invoice processing for these regions.
Original PR description
The CIUS RO and CIUS HR depends on the BIS3 which is fundamentally incorrect. This was probably made out of lazyness to redefine things that are almost the same in both these CIUS and the BIS3. Now, in previous PR [1], we added contraints for the Peppol BIS 3 that are impacting those formats. Indeed, the EndpointID can be empty in the context of CIUS RO and CIUS HR. In particular, it's breaking the sending to physical person at the moment. [1]: https://github.com/odoo/odoo/pull/246961 opw-5943698 Forward-Port-Of: odoo/odoo#249970 Forward-Port-Of: odoo/odoo#249089
This update fixes a bug that caused duplicate invoices to be created when an error occurred during the import process. The system now correctly handles errors by acknowledging existing invoices before attempting to re-import, ensuring data integrity and preventing redundant records. This improves the reliability of our PEPPOL invoice processing.
Original PR description
When importing invoices, if an error occurs in `_peppol_import_invoice`, Odoo crashes before acknowledging the already created bills. But, since `rollbackable_transaction` is used in `_extend_with_attachments`, the invoice is already committed. Since the acknowledgement is not sent while the invoice is committed, the next `_peppol_get_new_documents` attempt duplicates the invoice. opw-5937044 Forward-Port-Of: odoo/odoo#249842 Forward-Port-Of: odoo/odoo#249521
5 changes
Resolved issues and error corrections
This update corrects a potential issue in the Odoo Enterprise accounting for Colombia (l10n_co_dian) module. Specifically, it ensures that certain data related to Dian's tax requirements (cufe/cude) is properly handled, preventing unexpected resets and maintaining accurate financial reporting. This resolves a technical problem that could have impacted data integrity.
Original PR description
task-5500236 Forward-Port-Of: odoo/enterprise#108228
This update fixes a compatibility issue with the Dutch tax (OB) and ICP report templates. It switches to the final 20251210 NT20 taxonomy, ensuring these reports process correctly through Digipoort, a key system for tax reporting. This ensures accurate and compliant reporting for our Dutch customers.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
This update fixes a critical issue in Australian payroll calculations by ensuring tax and deduction figures accurately reflect the pay period's historical settings. Previously, the system used current employee data, leading to incorrect calculations when employee details changed. Now, payrolls use the correct historical data for accurate tax and deduction processing.
Original PR description
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields…
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values. This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state). This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period. The following rules/fields are updated to use the version object: - Tax Treatment Category - Additional Withholding Amount - Extra Pay - TFN Declaration - Medicare (Reduction, Exemption, and Levy) - Training Loans - NAT 3093 Amount (Tax Offset) - Child Support (Garnishee and Deduction) A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates. Task-5002697 Forward-Port-Of: odoo/enterprise#108063 Forward-Port-Of: odoo/enterprise#106550
This update resolves a technical issue that prevented emails from being sent correctly when processing multiple equity transactions. The fix corrects a configuration error in the email template, ensuring accurate record matching and preventing errors during email generation. This improves the reliability of equity transaction email notifications.
Original PR description
## Issue Before This Commit A missing record error occurred during email generation when the number of `equity.transaction` records exceeded the `res.partner` records. ## Cause of the Issue The issue was caused by an incorrect `model_id` configuration in the `equity_shareholder_email_template`. This created a mismatch between the template model and the record context passed to the mail compose wizard, leading to a missing record error during template rendering. ## With This Commit The template `model_id` has been corrected `equity.transaction`. This ensures that the mail compose wizard receives the correct model context and prevents missing record errors during email generation. Steps to reproduce : [Video](https://drive.google.com/file/d/19WXbjmYPKh0IjQHcEGU4FdUbGSF4GGlx/view?usp=drive_link) opw-5899070 Forward-Port-Of: odoo/enterprise#107891
This update corrects a rounding issue in the calculation of the private car daily allowance within the Odoo Enterprise payroll system. The change ensures that all figures are displayed with two decimal places, improving the accuracy and reliability of reported payroll data. This update primarily affects the Belgian payroll module.
3 changes
Resolved issues and error corrections
This update resolves an issue preventing early bill printing with the Italian fiscal printer, which was causing errors and preventing the receipt from printing correctly. The fix focuses on streamlining the printing process and avoiding unnecessary data synchronization, ensuring the receipt is printed reliably.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#107925
Forward-Port-Of: odoo/enterprise#105511This update improves the speed of changing order stages within the Point of Sale (POS) system. By separating customer display calculations and triggering them only when needed, the system responds more quickly to user actions. This enhances the overall user experience and efficiency.
Original PR description
Before this commit when a lot of orders were in the preparation display and when clicking on an order to change its stage, it was very slow because we were doing the customer display computation directly. Now we compute customer display data in a separate RPC call, and we only call it when the customer display receives a notification of new orders, which makes the stage change much faster. The `_get_pos_orders` is updated to avoid an O(n²) loop; The `_get_open_orderlines_in_display` is updated to avoid deep joins.
This update resolves an issue where data in the Co-Dian accounting module was being unintentionally reset. The change ensures that key data elements are properly flushed, preventing data loss and maintaining accurate financial records. This improves the stability and reliability of the Co-Dian accounting functionality.
Original PR description
task-5500236 Forward-Port-Of: odoo/enterprise#108225
3 changes
Resolved issues and error corrections
This update resolves an issue where helpdesk users with limited access were unable to view tickets due to a restriction in accessing related stock records. The fix adds a security group to the ticket field, allowing users to correctly read the necessary information and access tickets without errors.
Original PR description
To reproduce: ============= - install helpdesk_stock - with user having only User rights on helpdesk and nothing on other modules - try to access a ticket -> AccessError Problem: ======== when reading the ticket, the field `suitable_product_ids` is computed, and it requires read access to records the user doesn't have access to, which raises an AccessError. Solution: ========= Add the group `stock.group_stock_user` to the field, so that only users having access can read it. backport of https://github.com/odoo/enterprise/pull/59605 opw-5907657 Forward-Port-Of: odoo/enterprise#107291
This update fixes a visual issue where empty group headers were appearing in grouped reports, creating a cluttered and confusing user experience. The change ensures that group headers are only displayed when a group name is actually present, resulting in a cleaner and more professional report layout.
Original PR description
Reason: The grouped_view_widget renders a header row even when group_name is empty, creating unnecessary empty header rows in the UI. Fix: Add t-if condition to only render the header row when group_name exists. 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 corrects a bug where changing a lead's customer would retain outdated information from the previous customer, especially if the new customer had empty fields. Now, lead data always reflects the currently selected customer, ensuring accurate and up-to-date information is displayed and used.
Original PR description
When changing the customer (partner_id) on a CRM lead, contact and address fields (phone, email, street, city, etc.) may retain values from the previously selected partner if the newly selected…
When changing the customer (partner_id) on a CRM lead, contact and address fields (phone, email, street, city, etc.) may retain values from the previously selected partner if the newly selected partner has empty fields. This leads to stale and incorrect information being displayed and potentially propagated to the new partner. Current behavior before PR: Create a lead and select Partner A (with phone/email/address). Lead fields are populated correctly. Change the customer to Partner B with empty contact/address fields. Lead keeps old values from Partner A instead of clearing them. Saving the lead may propagate these outdated values to Partner B. Result: outdated data leaks between partners. Desired behavior after PR is merged: When changing the customer, lead fields must always reflect the selected partner. If the new partner has empty values, corresponding lead fields should be cleared. No previous partner data should remain or be propagated. This ensures the partner is always the single source of truth and prevents stale data. Task : https://github.com/odoo/odoo/issues/245215 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
5 changes
Resolved issues and error corrections
This update corrects a bug where invoice payment terms were being created in the wrong order. Specifically, the last payment term line was appearing first, causing incorrect calculations. This fix ensures payment terms are correctly associated with invoices, improving financial accuracy.
Original PR description
1. Create Payment terms with line 1: after 15 days, line 2: after 45 day 1. Create invoice and save. 2. Assign payment term Move line payment term wrong Reason: The last line of the needed terms data goes first. Video Issue: https://github.com/user-attachments/assets/9cfa352f-da9e-4dc9-b861-7e12edd377e4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents user-modified invoice data from being overwritten when account moves are posted. Previously, automatic synchronization processes reset user changes, causing frustration. This change ensures user-entered data is respected during the posting process, improving data accuracy and user experience.
Original PR description
When posting account moves, user-modified data gets overwritten due to automatic synchronization between account.move and account.move.line models. This happens because the _post() method triggers…
When posting account moves, user-modified data gets overwritten due to automatic synchronization between account.move and account.move.line models. This happens because the _post() method triggers _sync_dynamic_lines() and _sync_invoice() without protecting intentionally modified data. The synchronization mechanism is designed to maintain data consistency across related models, but it doesn't distinguish between system-generated changes and user modifications. This causes frustration when users carefully adjust invoice data only to see it reset during posting. This commit adds context flags when writing the 'posted' state to prevent unwanted data synchronization. The technical choice to use existing context flags rather than implementing a new mechanism ensures consistency with the current architecture and avoids introducing breaking changes. The posting process should respect user intent and preserve deliberately modified data. https://github.com/user-attachments/assets/ebde6bbc-c88f-4351-913a-5da85c53b95b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a layout issue on the MRP production form that caused the quantity field to overlap on smaller screens, making it difficult to read on mobile devices. The changes implement responsive design principles to ensure quantity information remains clear and accessible across all screen sizes. This improves the user experience for all users.
Original PR description
Responsive layout prevent product_qty field overlap on small screens The quantity section in MRP production form view has responsive layout issues where product_qty field gets overlapped by product_uom_id field when the screen is resized to smaller widths. This makes quantity information unreadable on mobile devices and narrow browser windows. Video: https://github.com/user-attachments/assets/5448c65e-c744-47f5-8760-0da4c6d149ea --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a calculation error in manufacturing order finish dates. Previously, the system didn't account for the ratio of actual production quantity to the standard BOM quantity, leading to inaccurate dates. Now, the system accurately calculates finish dates based on production volume, ensuring more reliable scheduling and reporting.
Original PR description
The date_finished calculation in manufacturing orders was not considering the ratio between production quantity and BOM quantity, leading to incorrect finish dates when producing quantities different…
The date_finished calculation in manufacturing orders was not considering the ratio between production quantity and BOM quantity, leading to incorrect finish dates when producing quantities different from the standard BOM quantity. Previously, the system only used the BOM's produce_delay without accounting for the actual production quantity. This caused issues when: - Producing 4 tables (BOM: 1 table) - finish date was too early - Producing 0.5 tables (BOM: 1 table) - finish date was too late - Using different UoMs between production and BOM The fix introduces a factor calculation: factor = production_qty / bom_qty final_delay = factor * bom_produce_delay This ensures that the finish date accurately reflects the actual production time based on the quantity being produced relative to the standard BOM quantity. The change maintains backward compatibility and only affects the date_finished computation when a BOM is present and the production quantity differs from the BOM quantity. https://github.com/user-attachments/assets/1c63a3ad-8859-4cd6-8605-812165ebbda1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where automatic entries weren't correctly linked to the branch journal. Previously, the system defaulted to the root company, preventing users from managing entries by branch. This change ensures automatic entries are accurately recorded in the correct branch journal, improving branch-level financial reporting.
Original PR description
**Steps to Reproduce** 1. Create a journal in the branch company. 2. Create Automatic Entries for transactions originating from the branch. 3. In the wizard, the branch's journal cannot be selected. **Cause**: The company field in the wizard is always changed to the root company, making it impossible to select the branch's journal. **Solution**: The goal was to enable the management of automatic entries for multiple entries coming from different branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr