Daily updates from Odoo
Monday, December 1, 2025
29 changes · master
New functionality added to Odoo
This update introduces a new process to accurately calculate and apply year-end tax adjustments for employees in Egypt and Pakistan. Previously, HR managers had to manually correct tax discrepancies. Now, a wizard allows for the calculation of the difference between expected and actual tax, automatically applied to the final payslip.
Original PR description
purpose: In Egypt & Pakistan, the tax amount is based on monthly computations, where each month's portion is accounted for. However, in cases where an employee gets a raise during the year that increases the gross amount into a different tax slab, the tax amount paid would not be correct, and in most cases, HR managers are responsible for computing it manually. The reason behind this task is to introduce a way to compute the difference, if any, and apply it to the last payslip of the year. current behavior: - added server action for End of year Tax Adjustment which opens a wizard with the actual ytd gross and ytd tax and on confirming, it creates a salary input on the payslip with the difference between actual tax that should be paid and ytd tax - added 2 salary rules for positive and negative tax correction - added corresponding accounts for the salary rules (Eg only) task-id: 5092724
This pull request introduces a new module within Odoo Enterprise focused on managing equity information, including share classes, transactions, and valuations. This addition provides a framework for businesses to track and report on equity-related data, streamlining financial reporting and compliance processes. The module includes demo data and security settings for initial configuration.
This pull request introduces a new module within Odoo Enterprise focused on managing equity-based investments. The module provides tools for tracking share classes, shareholders, transactions, and valuations, offering a more comprehensive solution for businesses managing equity holdings. This addition expands Odoo's capabilities to support financial reporting and investment tracking.
This update adds the ability to send sign requests directly through WhatsApp. Users can now customize a WhatsApp message template and send requests with placeholders like recipient name and document title. This expands communication channels and streamlines the digital signature process.
Original PR description
Implemented a new feature that allows users to send sign requests via WhatsApp. A new global setting has been added in the Sign app configuration to let users define a WhatsApp message template for sign requests. Once configured, a new button appears in the Send Request wizard, enabling users to send the request via WhatsApp using the selected template. The system uses the defined WhatsApp template to generate the message, including placeholders such as recipient name, document title, and signing link. If no template is configured, the WhatsApp button remains hidden. This enhancement improves flexibility and expands the available communication channels for collecting digital signatures. task-5079248 Forward-Port-Of: odoo/enterprise#94429
Enhancements to existing features
This update significantly improves the speed of auditing large financial reports. By caching report data and line expansions, users avoid lengthy reloads and blank screens when navigating between reports and their details. A warning banner indicates when data is being refreshed in the background.
Original PR description
When auditing large reports, users often navigate back and forth between the report and its underlying move lines. Each time the user returns to the report, it triggers a full reload, resulting in a blank screen and long wait time making auditing slow and painful. This commit caches the report information, and line expansion rpc calls in disk with validity of 90 minutes. RPC calls are being called asynchronously and report is updated if data changed. While data is being refreshed in the background, cached report is displayed along with a warning banner informing the user that report is being loaded. task-5145462
This update enhances tax reports by allowing labels to be associated with cell values. This solves the issue of using codes in multi-column reports, making it easier to understand and reference data directly within the report UI. It improves the clarity and usability of tax reporting.
Original PR description
Tax reports often denote values by codes. While these are easily added to line names in simple reports, this is insufficient for multi-column reports where every cell corresponds to a code needed for reference. This commit introduces a mechanism to attach specific labels to report cells using a reserved expression prefix: `_cell_label_`. When an expression is named with this prefix (e.g`_cell_label_balance`), its value computed using the 'text' engine is treated as a label for the target expression (e.g `balance`). The label is then displayed next to the cell value in report UI. task-5233075
This update enhances Odoo's automation performance by logging the duration of each action. The logging system now uses increasing log levels based on action duration, helping the Odoo Infra team identify and address slow-running automations. Additionally, statistics on automation run times are now included in server dumpstacks.
Original PR description
The Odoo Infra team wants to be able to track down the base automations that slow down the server, but at the same time they don't want to fill logs with silly data. In this work we refactored the logging to log the run duration, the log level increases with the action duration. The longer the action takes to run, the more severe the log level is. Also as per request of the Infra team, we also included some statistics about base automations in the SIGQUIT dumpstack. At the moment the stats are a mapping action_id: accumulated run duration.
This update enhances the reliability of our website generation process by proactively verifying URLs before sending requests to the website scraper. The system now checks URLs on the IAP server to filter out invalid or unauthorized links, preventing wasted resources and potential errors. This ensures a smoother and more efficient website generation experience.
Original PR description
This PR adds the client side verification of an url for the request we make to generate a website using the website scraper. **The goal is to filter all the unwanted requests (invalid urls, banned urls) before launching the scraper process.** The check is done on the IAP server, and retrieved on the DB. The reason is that we don't want to send a request directly from the db [as this was already discussed](https://github.com/odoo/enterprise/pull/92724). Since the IAP server is also the one that will eventually do the scraping request, it also makes more sense that it is the one to check (to avoid the case where odooDB has access to an URL and IAP server does not).
This update enhances the initial guidance provided to users when running payruns within the Odoo Enterprise system. The previous implementation relied heavily on custom JavaScript and lacked robust testing, leading to potential instability. This change introduces a more structured tour to guide users through the payrun process, improving usability and reducing the risk of errors.
Original PR description
Payruns are currently heavily customized with javascript, and we have weak integration tests. So everytime framework makes a change in the ORM, it is likely that it might break. Such as with this PR https://github.com/odoo/odoo/pull/233635, that lead to this fix https://github.com/odoo/enterprise/pull/99771. Task: 5323872
This update ensures Odoo's Swissdec ELM certification is compatible with version 5.3. It includes key enhancements for payroll calculations, specifically related to French-crossborder workers, retirement regulations, and allowance calculations, improving compliance and accuracy.
Original PR description
This Pull request extends the Odoo Swissdec ELM Certification to the minor version 5.3. By doing so we add the following features : - Telework Percentage declaration for French-crossborder comuters - Adapting to AVS21 regulation, where retired employees can refuse their right to retirement - Adding automatic Child and education allowance calculation - Add the calculation of LPP in % - Allowing the specification of custom employer parts for LAAC and IJM Forward-Port-Of: odoo/enterprise#95518
This update enhances the payroll system by providing specific warnings for employees not included in completed pay runs. Instead of a general alert, users now see a message for each missing employee with an option to add a payslip. This improves clarity and streamlines the process of ensuring all employees are accounted for in payroll.
Original PR description
Replace the global warning for missing employees with a per-employee message. Now, employees not included in a confirmed but not validated pay run show a warning with an option to add a payslip. The message disappears when the pay run is closed. task-5156963.
This pull request focuses on improving the Equity app within Odoo Enterprise. It includes enhanced user interface elements, expanded unit testing for UBO calculations, and resolutions for previously identified issues. These changes aim to streamline the equity valuation process and improve data accuracy.
Original PR description
1. Unit tests for UBO 2. UI/UX improvements 3. Fixes for detected issues task-5078906
This update prepares Odoo to store sales achievement data for faster reporting. Previously, generating reports took a significant amount of time, especially with large sales volumes. By allowing the system to 'materialize' this data, performance will be noticeably improved for sales commission reports.
Original PR description
This commits aims to ease the possibility to materialize the achievements. The achievement table was a report built on the fly. Several commits were introduced to speed up the performances but on big systems with thousands of invoices, reading the achievements takes a few seconds. On big databases, it may be needed to materialized the achievement view to speed up reads. This commit reorganize the code to ease the materialization in a simple override commit. task-5170644 Forward-Port-Of: odoo/enterprise#97268
This update makes the employee benefits and personal information sections more relevant by showing only data applicable to the selected company’s country. Previously, all country-specific fields were displayed, leading to potentially confusing information. This change ensures users see the most accurate and useful data for each organization.
Original PR description
This change improves data relevance and user experience by making the Benefits and Personal Info sections context-aware. Previously, all country-specific fields and benefits were displayed regardless of the selected company or salary structure corresponding country. Now, the Benefits and Personal Info list views display only records related to the selected company’s country, ensuring users see data applicable to that organization’s jurisdiction. In the Benefits form view, the Related Fields section dynamically shows only fields relevant to the selected Salary Structure’s country, preventing the display of irrelevant or non-applicable country fields. task-5152545 (https://www.odoo.com/odoo/my-tasks/5152545)
This update enhances the bank reconciliation process by providing a clearer display of transaction details, statement information, and improved usability. Key changes include a streamlined interface, enhanced communication features, and expanded functionality for handling longer payment references, ultimately improving efficiency and accuracy.
Original PR description
See commits' description Forward-Port-Of: odoo/enterprise#99529
This update automatically notifies users when invoices are canceled due to DGI rejections, preventing unnoticed cancellations and ensuring invoices are corrected promptly. It also allows users to manually update invoice statuses if DGI changes its acceptance, resolving inconsistencies and maintaining accurate invoice records.
Original PR description
Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI: **For invoices that have been rejected by DGI:** - Added logic to automatically notify…
Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI: **For invoices that have been rejected by DGI:** - Added logic to automatically notify relevant users when an electronic invoice (CFE) is rejected by the DGI and, as a result, canceled in the system. The goal is to ensure that there is always someone responsible who is informed to correct and resend the receipt. - Added logs in the terminal to make the debug easier in case we want to identify rejected invoices. **Particular case of an invoice that had been rejected by DGI but the user somehow fixes it and then DGI accepts it:** - Added logic to verify both DGI state and Invoice state and adjust it accordingly when updating invoice DGI status. - Make 'Update DGI status' button always visible to be able to adjust invoices states. **== Context of the Problem ==** Previously, when Odoo detected that a CFE had been rejected by the DGI, the system proceeded to cancel the invoice automatically. However, this process was carried out silently, without generating any notification. This could mean that if no user or salesperson was actively monitoring the status of the receipts, the cancellation would go unnoticed, resulting in invoices that were never corrected or reissued. For the case of a previously rejected and then accepted invoice, we always thought that 'Rejected' state in DGI was a definite state and could not suffer any change. But recently it has been a case that this state changed, creating inconsistencies in Odoo invoices states as they appear as cancelled. With these changes, the user can adjust the invoices state by clicking 'Update DGI status' button. **== Automatic Notification Logic ==** With the new functionality, every time an invoice is automatically canceled due to a DGI rejection, the system posts a message in the document chatter to report the situation. The logic for determining who is notified is as follows: _Scenario 1: Invoice with Internal Followers_ - If the canceled invoice has at least one internal follower (an Odoo user), the system will perform the following actions: - It will post a message in the invoice chatter. - It will tag (@) all internal followers to notify them directly. _Scenario 2: Invoice without Internal Followers_ - If the invoice does not have any internal followers, the system will search for a more general but relevant audience to ensure that the notification is addressed: - It will post a message in the invoice chat. - It will tag (@) all users who belong to the “Accounting Manager” permission group (technical name: group_account_manager). Task ODOO: #[1362](https://latam-localizations.odoo.com/web?debug=1#id=1362&cids=1&menu_id=88&action=131&active_id=16&model=project.task&view_type=form) Task ADHOC: #[54799](https://www.adhoc.inc/odoo//project.task/54799) Forward-Port-Of: odoo/enterprise#100523 Forward-Port-Of: odoo/enterprise#94502
Resolved issues and error corrections
This update resolves an issue where the DIOT report export failed when journal entries lacked a linked partner. The fix ensures that the export process gracefully handles entries without partners, preventing errors and improving data reporting accuracy. The change includes a safeguard to prevent crashes and a more robust method for retrieving data.
Original PR description
**Steps to reproduce:** 1. Install `Accounting` and `l10n_mx_reports` modules. 2. Create two journal entries using DIOT tax grid: one with partner, one without 3. Confirm the entries. 4. Go to `Accounting → Reporting → Tax Report → DIOT (MX)`. 5. Try to print the DIOT report in TXT format from the top-right dropdown. **Observed behavior:** * Export fails with a traceback if any entry has no partner. **Root cause:** The method `_get_diot_values_per_partner` does not handle entries without partners. **Solution:** raise `Usererror` if entries without partners when sorting and exporting. note: The second commit addresses a traceback caused by a missing operation_type_code. This occurs when all entries lack a partner or when a partner’s operation_type_code field is not set. opw-5060825 Forward-Port-Of: odoo/enterprise#100843 Forward-Port-Of: odoo/enterprise#96529
This update ensures that the indexed wage for Luxembourg employees remains read-only after a contract is signed. This prevents manual changes to the base salary threshold, aligning with local regulations and guaranteeing accurate payroll calculations based on annual indexing.
Original PR description
In LU, when you sign a new contract, the salary should automatically increase henceforth and is indexed each year. The indexed wage at a given year defines the base threshold for the employee's salary. It is dependent on the country's salary rules, index at signature and current index, and must not be modifiable by the company's officers. The field should thus be read-only. TaskID: 5217101
This update resolves an issue where the generation of Intrastat export files for Belgium was inconsistent, potentially leading to discrepancies in reporting. The change ensures a predictable and reliable export process, improving the accuracy of Intrastat data. This fix addresses a technical problem that impacts the integrity of business reporting.
Original PR description
Ensure be intrastat file export is deterministic Runbot error 234045
This update resolves an issue where changing a contract template on a new offer would trigger a validation error. The fix ensures that the system correctly handles work entries and salary simulations, preventing incorrect contract assignments. This improves the accuracy of offer creation and avoids potential data inconsistencies.
Original PR description
Steps to reproduce the bug: 1. install hr_contract_salary_payroll 2. check "My US Company" 3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries…
Steps to reproduce the bug: 1. install hr_contract_salary_payroll 2. check "My US Company" 3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries for the next month 4. Go back to employees / Troy Cruz / Offers (smart button) -> You should be on the form view of a new offer. Do not save it. 5. Change the contract template to (e.g.) Experienced Developer -> A validation Error should appear The validation error would tell us that we are trying to set a new contract to the employee, but the employee already had a running contract. This happens because `self.employee_id` would be set to false just after the write of it's version's `contract_date_end`: https://github.com/odoo/enterprise/blob/9ea4c1382a75024acacba7af1529d0c5cc762827/hr_contract_salary_payroll/models/hr_contract_salary_offer.py#L78C1-L78C7 This only happens when there are work entries after the specified end date. This is why we had to look at the next month's work entries. The problematic code gets rolled back at some point, but `self.employee_id` stays empty if we don't save the form, since self is a `newId` in this case, which is not stored in the DB (and thus not rolled back) The issue was that the context was supposed to have the `salary_simulation` key present, since we are doing a salary simulation. But, the backend would still try to unlink the work entries of current_version during the simulation. Which is not needed and causes `self.current_employee_id` to be set to `False` The context variable and a check before `_remove_work_entries()` has thus been added to fix that. task-5207567 Forward-Port-Of: odoo/enterprise#100151
This update ensures that when a customer in Mexico uses the Point of Sale (PoS), the correct CFDI usage (as defined on their partner record) is automatically applied to the order. Previously, the system defaulted to 'G03', which is now corrected to reflect the customer's specific CFDI setting, ensuring compliance with Mexican tax regulations.
Original PR description
When making an order in the PoS in Mexico, if the customer has a CFDI usage set on their partner, it should be used for the order instead of the default one. Steps to reproduce: ------------------- * Install l10n_mx_edi_pos * Create a partner with a CFDI usage different than 'G03' * Open the PoS, select the partner and make an order * Validate the order and check the order in the backend > Observation: The CFDI usage is 'G03' instead of the one set on the partner. opw-5018288 Forward-Port-Of: odoo/enterprise#98607
This update corrects a reporting issue where employee leave days were incorrectly included in planned hour calculations. The fix ensures that leave and holidays are properly excluded, providing more accurate data for project planning and analysis within the Timesheets > Planning Analysis report. This improves the reliability of time tracking information.
Original PR description
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in…
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects. **Steps to Reproduce** 1. Create a planning slot for an employee spanning a full month 2. Add employee time-off (resource.calendar.leaves) during that period 4. Navigate to Timesheets > Timesheets / Planning Analysis report 5. Filter by the employee and date range 6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project **Root Cause** The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy. **Solution** Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates. opw-5027070 Forward-Port-Of: odoo/enterprise#100664 Forward-Port-Of: odoo/enterprise#97657
This update ensures the Sign app meets the ESIGN Act requirements for U.S. companies. Users are now notified when a U.S. sender is involved and given the option to request a paper copy of signed documents, providing legal protection.
Original PR description
Previously, the Sign app did not comply with the ESIGN Act. It now notifies users when the sender company is U.S.-based that they can request a paper copy of a signed document, ensuring ESIGN Act compliance. task-5166918 Forward-Port-Of: odoo/enterprise#100674 Forward-Port-Of: odoo/enterprise#97163
This update fixes a bug that prevented users from editing statement lines when currency exchange differences were involved. Previously, attempting to mark an invoice as fully paid triggered an error. The fix now intelligently filters out exchange moves during reconciliation checks, allowing users to successfully edit statement lines without encountering this issue.
Original PR description
When you create a statement line with one currency rate, and you reconcile it with a move with a different currency rate, this creates an exchange move. But when you want to edit the statement line amount, like marking the invoice as fully paid, this raise a UserError, as the Exchange move is reverted and reconciled, which means it throw an error like "You are trying to reconcile some entries that are already reconciled." This commit, fix this behaviour, by excluding the exchange moves from the check process. Linked:https://github.com/odoo/odoo/pull/237367 [opw-5184679](https://www.odoo.com/odoo/my-support-tasks/5184679) Forward-Port-Of: odoo/enterprise#100864 Forward-Port-Of: odoo/enterprise#100493
This update prevents the loss of CUFE codes during DIAN invoice processing for Colombian companies. The fix addresses a technical issue where invoices were being incorrectly marked as duplicates, leading to the removal of the necessary code. This ensures accurate reporting and compliance with Colombian tax regulations.
Original PR description
This issue requires a valid Colombia DIAN certificate and credentials to reproduce. Access to the Odoo Knowledge article *[CO] EDI – DIAN* is necessary for the setup. With `l10n_co_dian` installed…
This issue requires a valid Colombia DIAN certificate and credentials to reproduce. Access to the Odoo Knowledge article *[CO] EDI – DIAN* is necessary for the setup. With `l10n_co_dian` installed and a Colombian company: - Set up the DIAN Sales journal with the correct *Technical Key / Technical Control Key* as described in the article. - Ensure that each invoice name follows the required format. - Create a commercial invoice in the DIAN Sales journal (invoice date set in the past) and send it to DIAN. - Create the corresponding bill by copying the invoice reference and the CUFE code, then acknowledge receipt. - Run the server action **“Colombian EDI: Update Invoice Commercial States”**. Repeat this process at least twice. The CUFE code on the older invoice is removed. The server action calls `_l10n_co_dian_cron_update_event_status()`, which triggers `l10n_co_dian_action_update_event_status`. In this method, we remove `l10n_co_dian_document_ids` from moves considered duplicates. This deletion removes the `document_id` from the older move since it is treated as a duplicate of the newer one (both are in the “sent” state). However, in the compute method for `l10n_co_edi_cufe_cude_ref` (`_compute_l10n_co_dian_cufe`), we always reset `l10n_co_edi_cufe_cude_ref` to `False` before checking documents. Since the oldest move ends up with no documents, it never enters the loop and the CUFE code is lost. opw-5257129 Forward-Port-Of: odoo/enterprise#99776
This update fixes an issue where the mobility budget was incorrectly calculated for part-time employees during salary simulations. The system now accurately computes the budget based on a full-time equivalent, aligning with Belgian regulations. This ensures accurate budget reporting and compliance.
Original PR description
Mobility budget should be computed based on a full time equivalent: https://lebudgetmobilite.be/fr/6-quel-est-le-montant-du-budget-mobilite#te During salary simulation, that is based on work time rate, a payslip is computed and triggers to recompute the version on which the payslip is bas That makes the mobility budget recompute as well, but this time, based on part time wage (e.g.: 2000 instead of 4000 for a mid-time). This PR adds context keys to ensure that during the salary simulation, the Mobility budget is still computed based on a full time equivalent. Also, this PR reintroduces wage with mobility budget on employee view Task-5360844 Forward-Port-Of: odoo/enterprise#100597
This update corrects a flaw in how time off requests are searched within the departure holiday attest process. The system now prioritizes searching based on the work entry type, which is a more reliable and consistent method. This ensures more accurate and reliable time off calculations for payroll.
Original PR description
The search on legal and european time off were barely based on leave types. It's safer to search based on the leave type of the corresponding work entry types as work entry types are more rigid. task-5367240 Forward-Port-Of: odoo/enterprise#100860
This update streamlines the process for correcting invalid financial statements. Previously, users were bounced to a limited view, requiring manual navigation to fix errors. Now, the alert directly opens the list view, allowing for immediate and efficient corrections, saving user time and effort.
Original PR description
When the dashboard shows an invalid statement, clicking the alert redirected users to the kanban view of statements. That view does not allow editing or performing any corrective actions, forcing users to manually switch to the list view to fix the invalid entries. This commit updates the 'Invalid Statement(s)' alert so it redirects directly to the list view, allowing users to correct the statements without extra navigation. task-5346063 Forward-Port-Of: odoo/enterprise#100407
This update corrects a bug where credit notes weren't automatically generating deferred revenue entries. The system was incorrectly using a setting designed for invoices. Now, credit notes will correctly create deferred revenue entries when configured to 'On bill validation', ensuring accurate accounting for deferrals.
Original PR description
The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do. As a result, deferred entries for credit notes are not created when expected. Steps to reproduce: - Go to Accounting → Configuration → Settings. - In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped - In the Deferred Revenue Entries section, set Generate entries to: On bill validation - Navigate to Accounting → Customers → Credit Notes. - Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line). - Validate the credit note. - No deferred revenue entries are created. Ticket [link](https://www.odoo.com/odoo/project.task/5187051) opw-5187051 Forward-Port-Of: odoo/enterprise#100211