Daily updates from Odoo
Tuesday, March 24, 2026
17 changes · 19.0
Enhancements to existing features
This update improves the project budget tracking within Odoo Enterprise by allowing more detailed budget information to be displayed in the project side panel. Specifically, the system now inherits a method to include richer budget data, leading to a more comprehensive view of project financial planning.
Original PR description
Enabling the inheritance of the method _get_budget_items to include more budget information, by adding a method for the budget items domain.
Resolved issues and error corrections
This update corrects a rounding error in the US payslip PDF that was causing incorrect overtime rates to be displayed, particularly for very small overtime durations. The fix changes how the rate is calculated directly on the work entry, ensuring accurate overtime pay is reflected in the PDF. This improves the reliability of payroll reporting.
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 on the work entry type instead. This is a manual forward-port of the work in Odoo 18 [1], to instead use the new amount_rate field on hr.work.entry.type instead. task-6052711 [1] https://github.com/odoo/enterprise/pull/111540
This update resolves an issue where repositioning signs within PDF documents caused erratic resizing behavior. The fix ensures only one resize listener is attached to each sign, resulting in a more reliable and predictable resizing experience for users. This enhances the overall usability of the sign request process.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111520 Forward-Port-Of: odoo/enterprise#111146
This update fixes an issue where multi-select rectangles on scaled PDF signature pages were inaccurately drawn, leading to incorrect selections. Additionally, the fix resolves a potential error when dropping elements and ensures helper lines align correctly during dragging. This improves the reliability and usability of the signature process.
Original PR description
When drawing the multi-select rectangle on scaled PDF pages, the rectangle corner was not properly synchronized with the mouse pointer, leading to inaccurate selection. Additional fixes: - An uncaught error could be triggered when dropping elements on the page. - Helper lines during dragging were not accurately aligned around sign items. task-6049004 Forward-Port-Of: odoo/enterprise#111156
This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the data source, leading to inaccurate unit conversions. The change ensures correct rate calculations by using the primary 'RATE' value from the XML data.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111275
This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA. The fix uses a simplified unit price for discount calculations, ensuring accurate decimal handling and successful invoice transmission.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#110706
This update fixes an issue where contract changes mid-pay period could lead to overpayments. The system now processes payslips in layers, considering previously calculated amounts to ensure accurate contributions and allowances, particularly for Hong Kong payroll. This improves payroll accuracy and reduces the risk of financial discrepancies.
Original PR description
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all…
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all payslips of a same payrun have their line calculated all at once. While this is better for performances, it has a negative effect when a single employee has multiple payslips in the same payrun. In such cases, we may want or need for the payslips to know what was already calculated in the same payrun to avoid overpaying contributions or allowances that have caps. To solve this issue, we now group payslips by employee, sort them chronologically, and evaluate them in horizontal "layers": - Layer 1: Computes the 1st payslip for ALL employees simultaneously. - Layer 2: Computes the 2nd payslip for the subset of employees who have one, etc 2) More tools in HK payroll to support these cases The payslip rules now have a `l10n_hk_payrun_totals` dict that contains the total amount already reported in previous payslips of a same payruns for a selection of rules that needs it. We also provides a `worked_days_prorata_rate` which gives the ratio of worked days vs unworked days in a month for cases where we need to adjust amounts based on that ratio. 3) Rule updates The last part of the fix requires some updates in a few rules that are fixed amounts/not based on the wage and ends up being counted double in our use case. These rules will now take into account already computed amounts as said above to avoid going over the limit. In most cases it will only affect that specific use case, with a small exception for fixed mpf voluntary contributions, which have been updated to be prorated based on the worked days in the month.
This update fixes a potential issue where a user could indirectly change an employee's work email through salary configuration. Now, the work_email field is protected and will not be reset if the employee is linked to a user, ensuring data consistency and preventing unintended email updates.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974,the 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
This update corrects a small, unintended message appearing in the documents generated for employee payroll. The fix ensures a cleaner and more professional presentation of these important documents. This change improves the overall user experience and consistency of our HR reporting.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update resolves a technical error that prevented the generation of 281.10 reports for Belgian payroll. The fix ensures accurate report creation by adjusting how the system identifies vehicle information, avoiding a previous traceback. This improves the reliability of payroll reporting.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#111506
Forward-Port-Of: odoo/enterprise#110860This update resolves a technical issue that caused warnings during the initial setup of reports on some migrated Odoo databases. Specifically, it adds a backup method to identify accounts using their code when XMLIDs are missing, ensuring reports load correctly without errors. This improves the reliability of the reporting process.
Original PR description
Description of the issue this commit addresses: On some migrated BE databases, account template refs a4121/a4521 are missing as XMLIDs. l10n_be_reports then fails to recover partner/reconcile account refs and logs warnings during post-init load. --- Desired behavior after this commit is merged: This commit adds a fallback in BE report chart template data to resolve a4121/a4521 by account code when XMLIDs are missing, preventing recovery warnings while keeping normal XMLID behavior unchanged. --- runbot-[233845](https://runbot.odoo.com/odoo/runbot.build.error/233845)
This update resolves an issue where uploading documents to the 'All' folder in the Documents app prevented them from being viewable through the bridge interface. The fix ensures that 'All' folder uploads now default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the default bridge folder rather than to `My Drive`. task-6023290 Forward-Port-Of: odoo/enterprise#111537 Forward-Port-Of: odoo/enterprise#111290
This update resolves an issue where users were directed to the wrong document form view when configuring PEPPOL document syncing settings. The change adds a dedicated Kanban view for PEPPOL documents within the settings, ensuring users can easily manage their PEPPOL documents. This improves the user experience and streamlines the configuration process.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111712 Forward-Port-Of: odoo/enterprise#111341
This update fixes an issue where tax reports were incorrectly calculating period boundaries, leading to inaccurate reporting for trimester-based tax periods. The change ensures that the report correctly identifies the relevant tax period, particularly for carryover calculations, improving the accuracy of financial reporting.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#111483 Forward-Port-Of: odoo/enterprise#110504
This update fixes a bug that prevented XML documents (like invoices and vendor bills) from being properly synced to the Documents app when created or updated in the accounting system. Previously, certain invoice creation methods missed syncing the original XML files. Now, all XML attachments to invoices are automatically linked, ensuring accurate document tracking and compliance.
Original PR description
[FIX] documents_account: sync all XML documents for account moves Before this commit, the synchronization between accounting attachments and the Documents app was incomplete regarding XML files…
[FIX] documents_account: sync all XML documents for account moves Before this commit, the synchronization between accounting attachments and the Documents app was incomplete regarding XML files (e.g., e-invoices, Peppol). This caused several specific issues: 1. When creating an invoice via the Accounting upload interface, only the generated PDF was synced to the correct Documents folder, leaving the original XML file unsynced. 2. When creating an invoice from an existing file in the Documents app (via server action), the system correctly synced the generated PDF, but failed to move or sync the original XML source file to the target folder. 3. When receiving vendor bills via Peppol or other EDI networks, the proxy attaches the fetched XML to the `account.move` via an `ir.attachment` write. Because this bypassed the existing sync filters, the Peppol XMLs were never pushed to the Documents app. This commit updates the `ir.attachment` logic in both `create` and `write`. It ensures that whenever an XML file (mimetype `application/xml` or `text/xml`) is attached to an `account.move`—regardless of the move type or whether it was uploaded manually or fetched via EDI—the document synchronization logic is triggered, properly linking and filing the XML alongside the PDF. Task-5909245 Task-5917535
This update resolves two critical issues preventing new employee creation within the Belgian payroll module. The first issue involved duplicate record creation due to a mail activity trigger. The second addressed a problem where actions were attempted before the employee record was fully saved. These fixes ensure reliable employee onboarding for Belgian companies.
Original PR description
First bug: Steps: - Switch to belgian company - Create new employee - Set contract start date - Click save manually -> boom Cause: in _trigger_l10n_be_next_activities, we create a new mail activity for the created employee which is already created in the default create function leading to duplicate follower records. Fix: in the super.create, pass the context variable mail_create_nosubscribe=True to disable adding the current user as a follower again to the same record Second bug: Steps: - Switch to belgian company - Create new employee - Set contract date - Add a wage then click anywhere -> boom Cause: _trigger_l10n_be_next_activities is called before the record is saved, hence trying to link to a null object Fix: check if the record is created before working on the activities Forward-Port-Of: odoo/enterprise#109799
This update resolves a bug where users could incorrectly create 'Requested Documents' instead of folders when syncing Peppol documents. To avoid a complex workaround and a functional issue with folder placement, the ability to create or edit these documents through settings has been disabled. This ensures accurate Peppol document synchronization.
Original PR description
Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder. This commit removes the possibility to create or edit documents through the settings. An alternative would have been to add the contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f. Task-6063736 Forward-Port-Of: odoo/enterprise#111761