Daily updates from Odoo
Sunday, February 22, 2026
4 changes · saas-19.1
Enhancements to existing features
This update optimizes the process of assigning tax tags to invoices in the Indian localization (l10n_in) module. By restricting processing to Indian invoices and using faster XMLID resolution, the system now performs more efficiently, reducing unnecessary load and improving response times. This results in a smoother user experience for our Indian customers.
Original PR description
Before this commit: - `_get_l10n_in_tax_tag_ids()` was executed for moves unrelated to Indian localization, causing unnecessary processing. - Profiling showed repeated `env.ref` lookups (>≈1.6% transactions each) even for a simple invoice flow (create → add products → post). After this commit: - Restrict execution to Indian-specific moves only. - Replace `env.ref` with `_xmlid_to_res_id` for faster XMLID resolution. task-5935607 Forward-Port-Of: odoo/odoo#248960
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