Thursday, February 19, 2026
8 changes · saas-18.4
Resolved issues and error corrections
This fixes grouped tax reports when cash-basis invoices include both negative and positive lines across different income accounts. The report now includes the relevant negative cash-basis lines, helping accounting teams see accurate tax totals grouped by tax.
Original PR description
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous…
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the base lines of type entry which have a balance of the same sign as the tax line. Yet in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error. So now, the logic is only considering lines with the same sign to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'. We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined. Steps to reproduce: - Activate Cash Basis in the Settings - Create a tax based on payment - Create an invoice with two lines: - One with a negative amount, an income account and the created tax - One with a positive amount big enough to compensate the previous line, a different income account and the same tax - Confirm - Click "Pay", validate the payment - In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice - Reconcile it with the invoice - Accounting > Reporting > Tax Return - Select "Group By: Account tax" Ticket [link](https://www.odoo.com/odoo/project.task/5089790) opw-5089790 Forward-Port-Of: odoo/odoo#249099 Forward-Port-Of: odoo/odoo#239081
Vendor bills imported from XML now handle small rounding differences correctly when charges or allowances are present on zero-priced lines. This prevents Odoo from doubling the imported total, helping accounting teams keep vendor bill amounts aligned with supplier documents.
Original PR description
Whenever a line with price `0.0` with `AllowanceCharge`s got imported, Odoo used to update the `price_unit` to the sum of price, allowance and charges, because of a wrong float comparison condition between this sum and the XML total. So the product price was increased, but the allowances were maintained. The total imported in Odoo became double the one in the XML. Step to reproduce: - Import vendor bill from XML with a product: - price: `0.00` - quantity: `1` - an AllowanceCharge, amount: `0.2` - an AllowanceCharge, amount: `0.1` - `0.0 + 0.2 + 0.1 (sum of price and allowances) != 0.3 (subtotal)` (but `float_compare(0.1 + 0.2, 0.3, precision_digits=4) == 0`) - `price_unit` is updated to `0.3` - Total in Odoo is `0.6` Ticket [link](https://www.odoo.com/odoo/project.task/5499525) opw-5499525 Forward-Port-Of: odoo/odoo#249199 Forward-Port-Of: odoo/odoo#248043
This fix ensures that removing an accidentally added online payment only deletes that online payment, not an existing terminal payment. It prevents mismatches between the point-of-sale screen and the server, helping orders sync correctly.
Original PR description
Before this commit, if an order had a terminal payment and an online payment was added accidentally, and then get removed, the terminal payment would get removed from server, while it won't be removed from the UI, resulting in a mismatch between the server and the UI, and the order would no be synced correctly. opw-5911699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248430
This update enhances the accuracy of payment reference checks by tailoring validation to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validations. Now, the system prioritizes country-specific formats, with a fallback to a standard check for unsupported countries, ensuring more reliable payment processing.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/enterprise#107589 Forward-Port-Of: odoo/enterprise#107116
This update resolves an issue where grouped tax reports were generating incorrect results when invoices included both positive and negative tax amounts. The fix ensures that all tax lines, including those with negative balances (CABA moves), are correctly processed, preventing report errors. This ensures accurate tax reporting.
Original PR description
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous…
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line. But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error. So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'. We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined. Steps to reproduce: - Activate Cash Basis in the Settings - Create a tax based on payment - Create an invoice with two lines: - One with a negative amount, an income account and the created tax - One with a positive amount big enough to compensate the previous line, a different income account and the same tax - Confirm - Click "Pay", validate the payment - In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice - Reconcile it with the invoice - Accounting > Reporting > Tax Return - Select "Group By: Account tax" Community PR: odoo/odoo#239081 Ticket [link](https://www.odoo.com/odoo/project.task/5089790) opw-5089790 Forward-Port-Of: odoo/enterprise#107707 Forward-Port-Of: odoo/enterprise#101601
This update resolves an issue where DHL shipping rate calculations failed when requested late in the day. Adding a 'next business day' flag ensures rates are accurately determined, preventing errors and ensuring reliable shipping calculations. This improves the overall shipping process for our customers.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684 Forward-Port-Of: odoo/enterprise#107153
This update resolves a potential issue where global invoices sent from the POS could fail due to timeouts when interacting with the SAT portal. Increasing the read timeout for these requests helps prevent duplicate invoice submissions and ensures accurate data transmission, improving the reliability of tax reporting for Mexican businesses.
Original PR description
**Fix:** Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again. opw-5347962 Forward-Port-Of: odoo/enterprise#107735
This update fixes a problem preventing wage statements in the Swiss HR Payroll module from being correctly sent. The issue has been resolved by correcting the process for generating and transmitting these important documents, ensuring accurate reporting for payroll and compliance. This ensures accurate and timely wage statement delivery.
Original PR description
Forward-Port-Of: odoo/enterprise#107827