Daily updates from Odoo
Wednesday, January 7, 2026
9 changes · 19.0
Resolved issues and error corrections
This update fixes an issue where payroll payments were incorrectly linked to the employee's bank account instead of the correct vendor account (like the IRS). The changes ensure payments are accurately assigned to the appropriate bank account, resolving a payment processing error and improving financial accuracy. Automated tests have been added to verify this fix.
Original PR description
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying…
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted") 3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050) 4. Create a new Off-Cycle Payslip : a. Payroll -> Payslips -> Payslips -> New Off-Cycle button b. Set Mitchell Admin as the employee of the payslip c. Change the Structure to "United States: Regular Pay" d. Compute Sheets 5. Create payments : a. Go to the Journal Entries linked to the payslip, and Post them b. Go back to the payslip and 'Pay' c. In the new wizard: Click on 'Create Payments' 6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!) 7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously) ## Purpose Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`. Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. ## Tests Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment). Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error. This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment. [community#235475](https://github.com/odoo/odoo/pull/235475) [task-4979220](https://www.odoo.com/odoo/action-4043/4979220) Forward-Port-Of: odoo/enterprise#101866 Forward-Port-Of: odoo/enterprise#99373
This update resolves an issue where dragging a CSV or Excel bank statement file to the dashboard resulted in an empty screen. Now, imported records are displayed, and details like the bank account and statement are logged in the system's chat interface for tracking.
Original PR description
Before this commit: - If we drag and drop a CSV/Excel file to import a bank statement from the dashboard, we have an empty screen instead of imported records. After this commit: - Now we get all those newly imported records after dragging and dropping a CSV/Excel file of bank statement from the dashboard. - If the record is imported, then we add this information into the chatter: bank account, statement, reference, end-to-end_id, notes. task-5212807
This update resolves an issue where modifying an employee's gross salary with a mobility budget in place didn't accurately update related calculations. The change implements an 'inverse function' to ensure correct recomputation of values, improving data accuracy for payroll processing.
Original PR description
When you have the mobility budget on an employee, you are unable to modify the gross of the employee and get other value correctly recomputed. So we add the inverse function to correctly set it.
This update fixes a previous issue where payments made on the website weren't properly reflected in the POS. Now, the POS automatically recognizes and accounts for payments made through ecommerce, creating down payment lines for existing orders. Additionally, fully paid orders without invoices won't appear in the POS, streamlining the payment process and preventing duplicate payments.
Original PR description
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the…
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5187602 Community PR-[#232841](https://github.com/odoo/odoo/pull/232841) Backport-[#96876](#https://github.com/odoo/enterprise/pull/96876) Original Task-5138081 Forward-Port-Of: odoo/enterprise#103350 Forward-Port-Of: odoo/enterprise#98029
This update resolves an issue where the bank reconciliation process would crash when multiple reconciliation models were applied to a single statement line. The fix combines the names of these models, ensuring the system can correctly handle complex reconciliation scenarios and maintain stability. This improves the reliability of bank statement matching.
Original PR description
Steps to reproduce: - Configure several reconciliation models matching the same statement line. - Reconcile the line and validate When reconciling a bank statement line, multiple reconciliation models can be applied (e.g. fees + write-off). The matching confirmation message assumed a single record and crashed when accessing `reconcile_model.name`. Fix by joining the names of the applied reconciliation models. OPW-5416031
This update fixes an issue where the 'Out of Contract' duration was incorrectly calculated, leading to inaccurate reporting of employee time. The change ensures that contract overlap dates are limited to the payslip period, providing more reliable payroll data and reducing potential discrepancies. This improves the accuracy of employee compensation calculations.
Original PR description
Steps to Reproduce: 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). Reason: - If a contract ends before the payslip period, it adds all days from the end of the contract until the end of the payslip period as "Out of Contract", ignoring the payslip start date. - If a contract starts after the payslip period, it adds all days from the payslip start date until the contract start date, ignoring the payslip end date. Solution: Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5350519
This update resolves an issue where changes to spreadsheets were lost when users disconnected during message sending. The fix ensures that messages are automatically retried until successfully sent, preventing data loss and improving the reliability of collaborative spreadsheet editing. This enhances the overall user experience and data integrity.
Original PR description
If, for any reason, the sending of a revision creates an error b.e. when the user is disconnected, we never reset the "waitingForAck" flag, and all future messages will be queued but never send. The result of this behavior was that any user action during any disconnection will set the spreadsheet in a state where all changes from that point are lost. This fix handles the error while sending a message and always reset the flag, so that at next change, we will try to re-send the same message until it works. Task: 5469116
This update resolves a previous issue where tests for the account_reports_cash_basis module were not running, leading to undetected errors. By adding a test execution step, we now ensure that all changes to this module are thoroughly tested before being released, preventing future problems and maintaining report accuracy.
Original PR description
The account_reports_cash_basis module was previously blacklisted on Runbot, causing its test suite to be bypassed during CI. Consequently, several regressions remained undetected (notably Runbot error 234873). This commit adds the `post_install_l10n` tag to ensure tests are executed prior to merging, preventing future regressions in this module. -------------------------------------------------------------- A previous change (see https://github.com/odoo/enterprise/commit/eba96e1f976b953fb8056249ea494e8f06e3c668) modified the reporting logic for Unaffected Earnings. Some cash basis test scenarios were not updated in the initial PR, leading to assertion failures. This commit updates the expected test values to match the current reporting format. runbot-234873
This update fixes a bug that caused data loss when the spreadsheet system encountered errors during message sending, particularly during user disconnections. The fix ensures messages are retried until successfully sent, preventing lost changes and improving overall spreadsheet stability. This enhances the user experience and data integrity.
Original PR description
If, for any reason, the sending of a revision creates an error b.e. when the user is disconnected, we never reset the "waitingForAck" flag, and all future messages will be queued but never send. The result of this behavior was that any user action during any disconnection will set the spreadsheet in a state where all changes from that point are lost. This fix handles the error while sending a message and always reset the flag, so that at next change, we will try to re-send the same message until it works. Task: 5469116