Daily updates from Odoo
Monday, December 1, 2025
13 changes · master
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