Wednesday, February 11, 2026
5 changes · master
Resolved issues and error corrections
This update resolves an issue where payment reports were sometimes generated with inconsistent formats, leading to potential errors. The fix ensures all localized payment reports (across various countries) now use a standardized export format, improving reliability and accuracy. This change has been backported to version 18.0.
Original PR description
\* = l10n_{ae, au, ch, in, sa, us}_hr_payroll + hr_payroll_account_iso20022
Issue:
The current behavior looks deterministic: when clicking on "Create Payment Report" it -sometimes- shows the current company's export format by default, other times it shows the "NACHA" type. Or it could be the last installed module's export format value for the other companies.
Solution:
I fixed it in this PR: https://github.com/odoo/enterprise/pull/93683 and now backporting the changes to version 18.0
task-5189295
Forward-Port-Of: odoo/enterprise#105645
Forward-Port-Of: odoo/enterprise#100126Users were experiencing blocks in the Point of Sale UI due to printers failing to receive print job requests. This change reverts a recent update that introduced this issue, allowing users to successfully print from the POS system. It's a quick fix to restore normal POS functionality.
Original PR description
Since preparation printers are ignoring the print job requests sent a lot of users are being blocked in pos UI. This reverts commit 5e290c264f14108e036344663fc459bf77da265e. This unblocks the user's UI in case of a duplicate print Forward-Port-Of: odoo/enterprise#104421
This update fixes an issue where invoices for Point of Sale orders paid with customer accounts wouldn't correctly reflect payments made through settle due orders. The fix ensures that all payments, including those from settle due orders, are accounted for when generating invoices, preventing unpaid invoice statuses.
Original PR description
If you made a PoS order paid with the customer account payment method, and then you created a settle due order to settle the previous one. If you then create the invoice for the original order, the invoice would appear as unpaid, because the payments of the settle due order were not taken into account. Steps to reproduce: ------------------- * Create a PoS order and pay with the customer account payment method * Settle the order that you just created with a settle due order * Close the session * Go on the original order and create the invoice > Observation: The invoice appears as unpaid when it should be paid. Why the fix: ------------ When creating the invoice we gather all the payments of the order to create the corresponding journal entries. But the payment of the settle due order were not included. So the order was considered as unpaid. opw-5268042 Forward-Port-Of: odoo/enterprise#105564
This update fixes inaccuracies in the Mod349 report for Spanish EC Sales Lists, specifically addressing issues with refund calculations and currency handling. It now correctly accounts for refunds and multi-currency transactions, improving the report's accuracy and reliability for tax reporting.
Original PR description
[IMP] l10n_es_reports: mod349 uses tax_tags Fix modelo 349 computation, allow for mixed operations The mod349 is the Spanish EC Sales List report. In this PR, we: - Fix some of the report computation (see for instance how refunds not in the same period displayed incorrectly the value invoice-refund when the refund should be displayed) - Allowed for the use of taxes with related tax_tags rather than using a field for the whole account.move. This implied modifying the custom engine to fetch move lines rather than moves and to adapt its sorting and computing. See also https://github.com/odoo/odoo/pull/237142
This update addresses an issue where some automated tour processes were failing intermittently. The team temporarily added a delay to these tours to ensure they completed successfully. This commit restores the original behavior by re-enabling the necessary delay, allowing these tours to run as intended. It's a follow-up to previous work aimed at removing this delay.
Original PR description
*account_reports,hr_contract_salary,hr_payroll_attendance, pos_enterprise,test_l10n_be_hr_payroll_account This commit is a followup of [1] which attempted to remove the 50ms delay between each step in tours. This allowed to highlight non deterministic tours that only passed thanks to that delay. A temporary flag was added to indicate to the tour system that a tour must be run with the 50ms delay (otherwise it fails). However, it seems that some tours have been forgotten in the process. This commit flags them, so they run as before. We'll now try to understand why they (sometimes) fail without a delay, and progressively remove the added flags. [1] odoo/odoo#237531 runbot error-238493 runbot error-238498 runbot error-238490 runbot error-238496 runbot error-238491 runbot error-238513 runbot error-238494 runbot error-238517 runbot error-238500 runbot error-238533