Daily updates from Odoo
Friday, January 16, 2026
6 changes · 17.0
Enhancements to existing features
This change updates the source of lead mining data within Odoo from Clearbit to Dun & Bradstreet. This aligns with existing data usage for partner autocomplete and ensures we're leveraging a reliable provider for improved lead insights. This update is part of a larger IAP migration.
Original PR description
Before this commit: - Lead mining data was fetched from `clearbit` provider on IAP which is now going to be removed for discovery service After this Commit: - Data will now be fetched from `dun_and_bradstreet` provider on IAP which we are already using for the `partner_autocomplete` IAP PR: https://github.com/odoo/iap-apps/pull/1274 task-4873238
Resolved issues and error corrections
This update fixes an issue where the company tolerance time wasn't being calculated accurately when employees had multiple attendance entries for the same day. Previously, overtime was incorrectly computed, leading to inaccurate extra time calculations. This change ensures that the tolerance time is applied correctly, preventing unnecessary overtime charges.
Original PR description
_ ## Short functional explanation of the error When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly. ## Reproduction Steps 1. Go to…
_ ## Short functional explanation of the error When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly. ## Reproduction Steps 1. Go to attendances. 2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes. 3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12. ### Expected behavior As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed. ### Unexpected behavior 12 minutes of overtime are computed. ## Origin of the issue Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code: https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time. Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code. note: the same bug exists for the employee tolerance time, which is corrected in this commit. __ opw-5136861 ---
This update resolves an issue where predictions were incorrectly enabled during the Peppol retrieve (BIS3) process, potentially leading to data changes. By correctly passing the necessary context and adding preventative tests, this fix ensures the stability and reliability of this critical functionality within version 17.0.
Original PR description
Before this commit, the Peppol retrieve (BIS3) had the possibility of being changed because predictions were not disabled correctly due to the context not being passed properly. To avoid this issue, we now pass the context correctly and added tests to prevent future errors. This commit is specific to version 17.0, as this version requires different changes compared to upper versions. Ticket [link](https://www.odoo.com/odoo/project.task/5441710) opw-5441710
This update corrects a problem where predictions were incorrectly enabled during the Peppol retrieve (BIS3) process, potentially leading to data changes. By ensuring the correct context is passed and adding preventative tests, this fix enhances the stability and reliability of this critical business function. This change is specific to version 17.0.
Original PR description
Before this commit, the Peppol retrieve (BIS3) had the possibility of being changed because predictions were not disabled correctly due to the context not being passed properly. To avoid this issue, we now pass the context correctly and added tests to prevent future errors. This commit is specific to version 17.0, as this version requires different changes compared to upper versions. Ticket [link](https://www.odoo.com/odoo/project.task/5441710) opw-5441710
This update resolves a crash that occurred when users attempted to confirm invoices with a specific journal configuration. The fix prevents an error when Electronic Invoicing is enabled without associated documents, ensuring smoother invoice processing.
Original PR description
Currently, an error occurs when the user tries to confirm an invoice using a misconfigured journal. **Steps to produce:-** - Install the **Accounting** module and switch to the "EC company" with demo…
Currently, an error occurs when the user tries to confirm an invoice using a misconfigured journal. **Steps to produce:-** - Install the **Accounting** module and switch to the "EC company" with demo data. - Navigate to `Accounting > Journals, open the journal named "001-001 Facturas de cliente", and duplicate it`. - In the duplicated journal: - `Uncheck` the `Use Documents` option. - Under Advanced Settings, `enable` the `Electronic Invoicing` option and save. - Create a new invoice using the `001-001 Facturas de cliente (Copy)` journal. - Change the invoice name to `test`. - Attempt to `confirm` the invoice. **Error:-** `IndexError: list index out of range` **Cause:-** - When the user disables "Use Documents" and enables EDI, the journal saves with EDI active but without showing the related configuration. **Solution:-** - Updated the `invisible` attribute for the EDI config group in the journal form view to prevent evaluation errors when "Use Documents" is not enabled. **sentry-6785644675**
This update resolves an issue where the payer company was incorrectly identified in the 1099 report CSV file when multiple companies were involved. The fix ensures that each 1099 vendor is accurately assigned to the correct company, improving the accuracy of tax reporting. This resolves a previous error impacting multi-company reporting.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190