Thursday, March 26, 2026
15 changes · saas-18.4
Resolved issues and error corrections
This update fixes a reporting issue where the KMD INF report incorrectly included partners with low turnover. Now, the report accurately filters partners based on a €1,000 turnover threshold, considering both invoices and credit notes. This ensures more reliable financial reporting.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#111737 Forward-Port-Of: odoo/enterprise#101333
This update fixes a potential issue where a user could indirectly change an employee's work email through salary contract updates. Previously, linking an employee to a user allowed for this unintended modification. Now, the system ensures the work_email remains consistent, regardless of whether the employee is linked to a user, improving data integrity.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974 employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. ### Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#111955 Forward-Port-Of: odoo/enterprise#111243
This update corrects a technical error preventing Point of Sale sessions from closing properly. The fix involves renaming a method within the 'l10n_de_pos_cert' module to ensure correct cash move formatting, resolving a previously reported issue. This ensures seamless POS operation.
Original PR description
**Steps to Reproduce:** 1. Start a new Point of Sale session from the Odoo backend. 2. Create and validate a POS order to ensure the session contains at least one transaction. 3. In the POS…
**Steps to Reproduce:** 1. Start a new Point of Sale session from the Odoo backend. 2. Create and validate a POS order to ensure the session contains at least one transaction. 3. In the POS interface, open the menu (☰ icon) in the top-right corner. 4. Navigate to the Cash In/Out functionality. 5. Perform a cash operation: - Select either Cash In or Cash Out - Choose a Category Reason - Select a Type Reason - Confirm the operation 6. Attempt to close the POS session. **Issue:** In version saas-18.2, an error occurs when closing the POS session because the name of the cash move (in the Cash Register) is incorrect. It should be formatted as: `Hauptmarkt/00006-out-category reason-reason` However, it is currently generated as: `Hauptmarkt/00006-out-reason` This happens because the method `"_prepare_try_cash_in_out_payload"` in "l10n_de_pos_cert" is not called due to an incorrect method name. **Solution:** The issue is resolved by renaming the method to the correct name `"_prepareTryCashInOutPayload"`. This ensures the proper method is invoked, generates the correct cash move name, and allows the POS session to close successfully. opw-6059143 Forward-Port-Of: odoo/enterprise#111597
This update resolves an issue where saving a report with an empty XML format in the Web Studio tool would generate an error. The fix prevents the system from attempting to process empty XML data, ensuring a smoother user experience. This change improves stability and usability for report creation.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#88613
This update ensures that when an employee leaves, any scheduled future appraisals are automatically cancelled and archived. Additionally, the employee is removed from appraisal roles, and their personal goals are archived, streamlining the process and preventing outdated appraisals from being created.
Original PR description
Currently, when an employee leaves the company, their future appraisals remain active and can still be completed. This fix ensures that, upon employee departure: - all future appraisals are removed - the employee is removed from appraisals where they are an appraiser - all their personal goals are archived task: 6036427 Forward-Port-Of: odoo/enterprise#111589
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance recorded. The fix ensures that the canteen cost is only applied if the employee has earned money through attendance or working during the payslip period, preventing incorrect charges.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#110991This update resolves a technical problem causing AI conversations to incorrectly display an 'OOO' banner and engage in self-chat. The fix ensures AI conversations function correctly with agents, maintaining proper routing and preventing unwanted self-interaction. This improves the overall AI app experience for users.
Original PR description
Override AI thread correspondent computation to keep the base behavior but clear the correspondent when it resolves to the current user in ai_composer/ai_chat. This avoids self-chat fallback side effects (like OOO banner) while preserving agent flows that rely on a real non-self correspondent. source of this crash: https://github.com/odoo/enterprise/pull/108217 Forward-Port-Of: odoo/enterprise#111736
This update fixes an issue where duplicating a product template automatically published it, even if the original wasn't. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing unintended product listings. This improves data consistency and reduces manual intervention.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789 Forward-Port-Of: odoo/enterprise#111340
This update resolves an issue where the POS scale wasn't accurately displaying product weights due to a change in how the IoT box sends scale data. The fix ensures that the POS correctly reads and displays weight readings from the physical scale, improving the accuracy of order processing. This primarily affects users utilizing the POS module.
Original PR description
Steps to reproduce - Use a localisation other than a european one (l10n_eu_iot_scale_cert must not be installed) - Setup the scale for the POS - Open the POS - Add a product to be weighted by scale to the order - Add product to the physical scale - The displayed weight is always 0 Cause: New versions of the IoT box uses the field result to return the scale measure instead of value. Fix for version 18.0 and its intermediary versions. [opw-5990467](https://www.odoo.com/odoo/project/49/tasks/5990467) Forward-Port-Of: odoo/enterprise#111963
This update fixes an issue where SEPA payment files were incorrectly generating with an outdated version (PAIN 09) even when the underlying data was correct. The fix ensures the correct PAIN version is used, improving the accuracy of payment file generation. This prevents potential errors with bank transfers.
Original PR description
https://github.com/odoo/enterprise/commit/80f9f966d7db793ae82e65c76514323cb10e34ab tried to fix the issue, but assumed the field would be returned empty by the ORM when the value was inconsistent with the db. It's not true: it returns the database value ; only the UI shows the field as empty. Forward-Port-Of: odoo/enterprise#112141
This update resolves a minor issue where the helpdesk tour occasionally failed due to the tour attempting to click a button before the kanban view was fully loaded. By ensuring the kanban view is fully rendered before the tour attempts to interact with it, this fix improves the overall stability and reliability of the tour experience.
Original PR description
This PR fixes a flickering failure in the `helpdesk_tour` ### Problem In the kanban view, the tour occasionally tried to click the "New" (quick create) button before the view's internal structure was fully painted. This caused the tour to click a wrong element. ### Solution Updated the step trigger to include a selector for the kanban group (`.o_kanban_group`). By requiring the presence of the group container, we ensure that: 1. The page content has actually loaded. 2. The specific "New" button within the kanban context is visible and ready. **Runbot ID: 223081** Forward-Port-Of: odoo/enterprise#110333
This update fixes a calculation error in the UAE payroll module that was causing incorrect hourly wage calculations for employees using the attendance work entry source. The change ensures that worked days are accurately reflected, preventing issues when computing payslips, particularly with leave time off entries. This improves payroll accuracy for UAE-based employees.
Original PR description
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry…
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry source to attendance. - Register a paid leave time off entry, for the employee whose work entry source is set to attendance. - Compute a payslip batch using the UAE Monthly pay structure. - Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again. - The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually. ### Cause: In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees ### Fix: We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage. opw-5979631 Forward-Port-Of: odoo/enterprise#111280
This update fixes a display issue in the external value pop-up, ensuring it uses the user's locale (language) to correctly format numbers with the appropriate decimal separator (like a comma instead of a dot). This improves the user experience by presenting financial data in a format that aligns with their preferred regional settings.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533 Forward-Port-Of: odoo/enterprise#111997 Forward-Port-Of: odoo/enterprise#109948
This update corrects a technical issue where the system was incorrectly limiting VAT number lengths when integrating with FedEx. The change ensures that VAT numbers, including those with longer formats like in Switzerland, are properly transmitted to FedEx, preventing delivery errors. This improves the reliability of shipments using FedEx.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452 Forward-Port-Of: odoo/enterprise#111864 Forward-Port-Of: odoo/enterprise#109999
This update resolves an issue where tiny overtime hours (like seconds) were causing incorrect rate calculations on US payslip PDFs. The fix directly calculates the rate from the hourly wage and multiplier, mirroring a previous solution for Australia, ensuring accurate overtime pay is displayed. This improves the precision of reported payroll amounts.
Original PR description
The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate. For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation: $26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06 We then attempted to calculate the rate in reverse for the PDF: $0.06 / 0.00166667 hour = $35.9999 ≈ $36.00 Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5). We now compute the rate directly from hourly_wage * multiplier instead, inspired by edc4ed3c21b which did the same for Australia. task-6052711 Forward-Port-Of: odoo/enterprise#111740 Forward-Port-Of: odoo/enterprise#111540