Thursday, February 5, 2026
8 changes · 18.0
Resolved issues and error corrections
This update fixes an error in the calculation of VAT payable or refundable on Welsh tax returns. The formula has been corrected to accurately reflect the difference between output and input VAT, ensuring accurate reporting for businesses using the `l10n_cy` module. This ensures compliance with Welsh tax regulations.
Original PR description
**Steps to produce:** - Install the l10n_cy and accountant modules - Switch to `CY Company`. - Go to accounting > reports > Tax return. **Issue:** - The formula for VAT payable or refundable (difference between box 4 and 3) is incorrect. - box 3 refers to `Total output VAT` and box 4 refers to `Input VAT`. - Current formula: `cy_4.balance - cy_3.balance` **Fix:** - Formula for VAT payable or refundable should be output VAT - input VAT. - Update the formula to: `cy_3.balance - cy_4.balance` <img width="769" height="86" alt="image" src="https://github.com/user-attachments/assets/923a92f9-fc57-465a-9592-771730ee6870" /> opw-5751369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246273
This update fixes an issue where purchase order line descriptions weren't correctly reflecting the vendor's name or code, particularly when using dropshipping. The change synchronizes how descriptions are generated during PO creation and modification, ensuring accurate vendor information is displayed. This improves the clarity and accuracy of purchase order details.
Original PR description
How to reproduce : - Create a product - Create an attribute with a value set to "free text" - Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name…
How to reproduce : - Create a product - Create an attribute with a value set to "free text" - Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name - Put Dropship as the route for the product to create a PO on a SO confirmation - Create a SO with that product - Confirm the SO and go to the PO - Change the vendor in the SO The problem : The Vendor Code and/or Vendor Name does not change correctly in the product description Why : The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user. The problem was that the generation of the description for the creation of the PO and for the modification of the PO were different. The later did not take into account the attributes with free text values. This, in turn, made it so the current description was never in the collection of default descriptions and so the description was never changed. The change: This commit aims to resynchronize the generation of the description on the creation and on the modification. Both now uses the product_description_variants field. Note: The function that generates the description on PO creation is "_prepare_purchase_order_line_from_procurement" in purchase_order_line.py in purchase_stock Note 2: The purchased_product_matrix module partly fixed this issue by adding attributes with Variant Creation set to "never" to the description. I have removed this logic as the above fix also includes these attributes. opw-5888233 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 resolves an issue where loyalty coupon discounts weren't consistently applied during PoS settlement, particularly when using quotations. The fix ensures that discounts are accurately calculated and applied to all items, preventing double-counting of discounts and maintaining accurate pricing. This improves the reliability of PoS transactions.
Original PR description
**Steps to reproduce:** - Make a loyalty coupon program, like 10% on all products - Make a quotation in Sales, enter the coupon code - Go to PoS and click on settle this quotation - Add another product - The coupon discount is not applied on the new product - Enter the coupon code in the PoS - The coupon discount is applied on everthing including the already discounted items we are settling **Why the fix:** When settling a quotation, we should not count what has already been included in the discount in the Sales app. Instead we now update the discount line instead of importing the one from the quotation, then making a new one. This way, the discounts stay on one single line per program. opw-5171060
This update corrects and enhances the tax descriptions and names used in the Belgian localization for Odoo. The changes include accurate translations, German translations, and a fix to ensure the 21% S.INC tax is correctly applied as an included tax. This ensures accurate financial reporting and compliance for Belgian users.
Original PR description
In this commit[^1] the tax descriptions and names for the Belgian localization were added/updated. However, some names or descriptions were either not fully correct, poorly translated, or not translated at all. In this commit, we revised them all and added German translations for everything as well. [^1]: https://github.com/odoo/odoo/commit/c7b39c5ad4afba7e61265773b87f500469ace91b
This update resolves a problem in the HTML editor within Odoo's collaboration feature, specifically when using Safari. The issue occurred due to incorrect document selections, often triggered by Chrome users' undo history. The fix ensures the HTML editor correctly handles selections from Safari, preventing errors and improving the user experience.
Original PR description
Before this commit: safari returns invalid document in collaboration, typically when a chrome user is sending history steps with undo. Reproduction steps: 1. In chrome, use an existing task with…
Before this commit: safari returns invalid document in collaboration, typically when a chrome user is sending history steps with undo. Reproduction steps: 1. In chrome, use an existing task with empty description or create a task in the project (first create the task title in the kanban view, then click edit), enter 4 lines of text 2. In one of the middle lines, delete one character --> undo --> add a new character 3. Save the task, open the task in Safari incognito, log in as demo (not admin), go to the task and click the description field 4. TraceBack: IndexSizeError: The index is not in the allowed range. After this commit: we use the range of the DOM selection to set the offsets of activeSelection. If the DOM selection is too wrong to be corrected, e.g. the selection's anchor node isn't the same with range's start container (or end container if direction is right to left), we do not set new activeSelection but just return the previous activeSelection task-5428788 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invoices created in one company could incorrectly use accounts from a different company. The change adds a validation check to ensure invoice line accounts always belong to the invoice's company, preventing data inconsistencies and ensuring accurate financial reporting. This improves data integrity and reduces potential errors.
Original PR description
### Issue: When an invoice is created for a company and then its company and journal are changed to another company valid combination, the accounts on the invoice lines are not updated automatically This leads to inconsistencies where move lines use accounts that do not belong to the move’s company ### Cause: A validation check ensuring that move line accounts belong to `move.company_id` or parents was missing in `_post()` for account moves ### Steps to reproduce: - Create Company A and Company B - Create an invoice on Company A with one line having an account in Company A - Change the invoice company to Company B and set a journal belonging to Company B - Save and confirm the invoice opw-5167958
This update enhances the account_edi_ubl_cii module by incorporating commodity codes from standard systems like Intrastat, UNSPSC, and CPV. These codes are now included in export invoices, improving data accuracy and compliance for international trade reporting. This ensures Odoo can properly handle and process export transactions.
Original PR description
task-5890887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a traceback issue and ensures the early bill printing option functions correctly for Italian fiscal printers. The fix addresses data synchronization problems that occurred when attempting to print receipts early, ultimately enabling reliable early printing functionality.
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" />