Daily updates from Odoo
Wednesday, April 29, 2026
16 changes · master
Resolved issues and error corrections
This update fixes an issue where the BIK (Business Income Key) calculation for company cars wasn't accurately reflecting changes throughout the month. The system now correctly updates the BIK monthly based on the employee's car usage, ensuring accurate payroll calculations and compliance. This impacts the 'l10n_be_hr_payroll_fleet' module.
Original PR description
**Description of the issue/feature this PR addresses:** When there is a change of car during a month, the employee will have 2 versions but all will be merged on the same payslips but currently only the BIK of one version is taken into account (or no BIK if the employee has no company car anymore) **Current behavior before PR:** . car_atn value equal the yearly_atn / 12 . ATN.CAR rule returns the car_atn value of the first version **Desired behavior after PR is merged:** . Update the car_atn value to be computed monthly, based on the number of calendar days in the current month . Update ATN.CAR payslip rule, it get the value of the car's atn on the current payslip month then prorated based on the versions periods within the payslip period . Modify the corresponding tests . Add corresponding tests task-6108696 Forward-Port-Of: odoo/enterprise#115022 Forward-Port-Of: odoo/enterprise#113484
This update fixes a critical issue where IoT events were missed due to a failure in the longpolling fallback mechanism. Now, if longpolling fails, the system automatically switches to using the more reliable WebSocket connection, preventing disruptions like failed Worldline payment confirmations. This ensures consistent event delivery.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/260931 Before this commit, if `onMessage` in `iot_http_service` was called directly, it would fail to fallback to websocket if the longpolling request failed, causing events to be missed. One symptom of this is Worldline payments failing to confirm when using websocket. After this commit, the `_longpolling` method will now throw an error in this case, causing the fallback mechanism to attempt websocket instead. Forward-Port-Of: odoo/enterprise#115277 Forward-Port-Of: odoo/enterprise#114779
This update resolves an issue where the vendor invoice fetching cron job in multi-company Odoo environments was failing due to incorrect company settings. The fix ensures invoices are retrieved from the correct company associated with each move, preventing errors and improving data accuracy.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115350 Forward-Port-Of: odoo/enterprise#113254
The Profit & Loss report for French associations was displaying incorrect financial figures due to an error in the report formulas. This update fixes the issue by correcting the formulas in the report, ensuring accurate calculations of income and expenses for association accounting. This ensures financial reporting aligns with French accounting standards for associations.
Original PR description
### Issue: The Profit and Loss report for associations shows incorrect values with inverted signs, leading to wrong totals in the final computation ### Cause: In 19.1, a new fiscal localization package for associations as been added In the report `account_financial_report_l10n_fr_cdr_asso`, all formulas in the `Operating income (I)` section are incorrectly inverted The equivalent section in `account_financial_report_l10n_fr_cdr_column_2024` is correct, where accounts are properly inverted in the formulas ### Steps to reproduce: - Install `l10n_fr_reports` - Create and switch to a French company - In Accounting Settings, select the fiscal localization: `France - Associations accounting plan` - Create and confirm an invoice (any amount) - Open `Profit and Loss` and select `Profit and loss account for associations (FR)` Before the fix, the Operating Income (I) is negative opw-6117967 Forward-Port-Of: odoo/enterprise#114414
This update fixes several issues within the AI chat interface, primarily improving readability and preventing formatting errors. Specifically, the font size of headings was adjusted to better suit the chat channel size, and a bug causing random asterisks within AI responses was resolved. This ensures a cleaner and more accurate user experience.
Original PR description
- The font-size of h1/h2 headers is large given the small size of chat channels which makes it harder to read the rest of the text. So, the font-size of h1/h2 headers is reduced in ai chat channels. - This commit removes the double border at the bottom of tables and updates the table borders by using table-bordered bootstrap class instead of border. - This commit also fixes an error where markdown2 2.4.11 doesn't detect the boundaries of bold markup properly causing asterisks to appear randomly inside AI responses. For example, "The **dog**, the **cat** and the **rat**" becomes "The <strong>dog<em>*, the *</em>cat<em>* and the *</em>rat</strong>" where it should only use <strong>dog/cat/rat</strong> task-6109286 Forward-Port-Of: odoo/enterprise#114687 Forward-Port-Of: odoo/enterprise#114592
This update ensures that the AI chat window opens in full-screen mode when initiated from the system tray or command palette. Previously, the chat opened in the background, which was inconvenient. This change improves the user experience for interacting with the AI assistant.
Original PR description
Prior to this commit, when opening the chat with an agent from the systray button, the chat window was opened in the background. This commit fixes the issue by adding a call to `channel.open` which opens the chat when in full-screen mode. This commit also fixes an issue where the chat window wasn't properly opened when done from the command palette. task-5172978 Forward-Port-Of: odoo/enterprise#115165 Forward-Port-Of: odoo/enterprise#114598
This update fixes a bug where commission calculations were failing for recurring subscription orders. The issue stemmed from an empty currency rate table, which prevented the system from correctly applying commission rates. The fix adds a fallback rate, ensuring commissions are calculated accurately for all subscription orders, regardless of currency settings.
Original PR description
Steps to reproduce: 1- Installed sale_commission_subscription and accounting 2- Go to [Sales -> Commissions -> Commission Plans] 3- Create a new commission plan of type MRR, specify a salesperson and approve 4- Go to Subscriptions app and create a new order with a recurring monthly plan and specify the same salesperson 5- Create an invoice for the order and confirm it 6- Go back to the commission plan and click on the Commissions smart button Issue: Commissions show up as 0 Expected behavior: Should have the corresponding commission based on the rate specified Why this happens: The `res_currency_rate` table is empty by default and only gets populated if you are in a multi-currency environment and sync the rates in the settings or by manually making a currency rate entry. Since the commission calculation depends on this table, it results in 0 rows when joining the sub-query. opw-6108580 Forward-Port-Of: odoo/enterprise#114354
This update corrects a bug that was causing overtime work entries to incorrectly generate on previous days. The fix adjusts how work entries are calculated, considering employee timezones to ensure accurate date comparisons and prevent incorrect overtime assignments. This ensures payroll calculations are reliable.
Original PR description
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate…
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate the work entries for the following day of the attendance - A new overtime work entry is generated on the first day. Reason: Because of how regenerating work entries is done, the computed date for searching overtime lines took into account the previous day (i.e. regenerating a work entry for a tuesday in an UTC+1 timezone made it so the starting date was on monday at 23:00:00), and since the _read_group only looked at the date part of the time start without taking into account the hour, it included the overtime of the previous day. How it was fixed: The domain now takes into account the timezone of the employee to generate the domain for the _read_group to ensure the correct day is selected Task ID: 5899657 Forward-Port-Of: odoo/enterprise#115289 Forward-Port-Of: odoo/enterprise#107266
This update fixes an issue where leave calculations were incorrectly recomputed due to outdated employee version references. The change ensures that leave time-offs are calculated using the correct, active version of employee data, leading to more accurate and reliable leave balances. This improves the stability and accuracy of the payroll system.
Original PR description
The employee_type_id, job_id and structure_type_id fields on hr.leave were stored related fields pointing to current_version_id. This caused all time offs to be recomputed whenever the employee's current version changed, and stored the current version's values instead of those active at the time of the leave. task-6175086
This update resolves two issues impacting manufacturing order management within the Barcode app. Previously, changes to the unit of measure and production quantity were not saved correctly, leading to inconsistencies. Now, these changes are reliably preserved, ensuring accurate production tracking.
Original PR description
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#115254 Forward-Port-Of: odoo/enterprise#114075
This update fixes an error in how tax returns are calculated for companies with multiple branches. Previously, rounding adjustments were incorrectly applied, leading to inaccurate closing entries. The fix ensures that rounding is calculated correctly for each branch, resulting in accurate financial reporting.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#115116 Forward-Port-Of: odoo/enterprise#110652
This update resolves a visual issue where the timesheet system tray overlapped with records when scrolling on smaller devices. The changes expand the timesheet grid and adjust its layout to prevent overlapping, ensuring a cleaner and more user-friendly experience for timesheet management.
Original PR description
Before: The systray overlaps the records when scrolling on small screens Changes: - Expands the record list to avoid scrolling overlaps - Make the timesheet list expand before the checkout button to ensure no overlap - Restrict the height of the timesheet list to avoid the double-scrolling problem --- task: 6115674 Forward-Port-Of: odoo/enterprise#114093
This update corrects a calculation error in the salary configurator. Previously, payslips were generated using outdated salary rules if the configuration was initiated on the contract start date. Now, payslips accurately reflect current salary rules, ensuring correct net pay calculations.
Original PR description
When the salary configurator is used, it generate a simulation payslip to know get a net value based on the gross. It should be done at the current date, because if it is at contract_start day, maybe years ago, it'll use wrong salary rules values to compute it Forward-Port-Of: odoo/enterprise#115319
This update fixes an issue where the system incorrectly flagged payruns as 'missed' reports due to delayed STP payment dates. The change now uses the payrun's creation date to accurately determine if a report needs to be submitted to the ATO, ensuring compliance and accurate reporting.
Original PR description
When a payslip is created after the submission of a previous payrun, it should trigger an update event to ensure the missed payslip is reported to the ATO with the totals, including all the slips already paid. It currently uses the submit date of STP to check if it's a missed report. However, sometimes the submit/payment date might be set in the future for a delayed payment of the payrun. In this case, the new payrun should not be considered as a missed payrun as it is still the correct order. This fix uses past payslip dates to check if a payrun is a missed report or not, instead of using the submit/payment date of STP. task-6134865 Forward-Port-Of: odoo/enterprise#114280
This update enhances the accuracy of French tax reports (liasse) by completing XML data and fixing minor bugs. Specifically, it adds missing fields and tags to the reports, validates company data, and incorporates country information, ensuring more reliable data transmission to tax authorities. This improves compliance and reduces potential reporting errors.
Original PR description
This commit aims to make the xml that we send to aspone for the liasse fiscale is the more complete as possible and to correct some small bugs. - Add missing fields in the reports - Add missing tags in the xml - Add a data validation on company data before exporting the reports - Correct errors in the reports - Add country fields in the reports as many2one task-6128878 Forward-Port-Of: odoo/enterprise#114468
This update resolves an issue where selling a main asset with a closed child asset resulted in incorrect accounting entries. The fix ensures that only active, non-closed assets are considered during the sale process, preventing double-entry errors and maintaining accurate fixed asset and depreciation calculations. A new test case confirms the resolution.
Original PR description
This commit fixes the double entries created when selling the main asset after disposing the child asset. Previously, the sale of the main asset with a closed child asset created 2 entries which resulted in wrong values in fixed asset, depreciation, and gain accounts. This commit filters the non-closed/non-cancelled assets, while previously it would try to close/sell all assets even if it was already closed/cancelled. Test case added to verify fix. opw-6018649 Forward-Port-Of: odoo/enterprise#115559 Forward-Port-Of: odoo/enterprise#115115