Daily updates from Odoo
Friday, December 5, 2025
9 changes · master
Resolved issues and error corrections
This update resolves an issue where duplicating multiple repair orders would cause errors. The fix ensures the system correctly handles multiple records during duplication, allowing users to efficiently copy repair orders without encountering technical problems. This improves the reliability of a key business process.
Original PR description
## Current behaviour: Duplicating multiple repair orders raises an error due to direct access to record fields without iterating on each record. ## Expected behaviour: Duplicating multiple repair orders should work without errors. ## Steps to reproduce: 1. Open runbot. 2. Select multiple repair orders. 3. Click "Duplicate". 4. System raises an error. ## Cause of the issue: The create/write methods assume a single record and fail when multiple records are processed at once. ## Caused by: https://github.com/odoo/enterprise/commit/16e1a97d85fc8227c73ce4a1507ab92ab7ed8486 The commit introduced logic that accesses values directly without looping over each record. ## Fix: Loop over records in create and write to handle multi-record operations. opw-5382657 Forward-Port-Of: odoo/enterprise#101184
This update resolves an issue where the automatic transfer account rule was creating duplicate and incorrect rules, leading to inaccurate account assignments. The fix simplifies the rule creation process by removing redundant mechanisms, ensuring data integrity and a more reliable transfer process.
Original PR description
## Steps to reproduce: 1. Create a new transfer record 2. Add more than one account to the Accounts field or add a rule with condition on Account or remove account from an Account condition with multiple accounts set ... (various other actions when adding/removing accounts) ## Before: Redundant and incorrect rules are created and an incorrect value is assigned for account_ids due to the faulty sync between the two. ## After: Removing the onchange mechanism that creates the rule with condition on Account whenever an account is added to the Accounts field, this information is redundant for the user. Also removing the onchange mechanism of the reverse (adding accounts to the Accounts field when a rule with condition on Account is added) as it cannot account for nested rules and any/all conditions. opw - 5160635 Forward-Port-Of: odoo/enterprise#100054
This update fixes an issue where the Christmas Bonus payslip incorrectly used a standard periodicity. The change ensures the payslip's periodicity is set to '99' (other periodicity) when the bonus is classified as extraordinary, accurately reflecting Mexican payroll regulations. This ensures correct reporting and payment processing for this specific bonus type.
Original PR description
For the Christmas Bonus, the 'periodicidad_pago', the periodicity of the payslip, should be 99, i.e. other periodicity. Right now, it takes the periodicity from the version which is not correct. Fix: when the structure is of payroll type extraordinary, put 99 in the 'periodicidad_pago'. Task: 5344050 Forward-Port-Of: odoo/enterprise#100271
This update resolves a critical error that prevented the generation of payroll export files. The fix corrects a naming mismatch in the code, ensuring accurate retrieval of employee data. A new test suite has been added to guarantee the reliability of the export process and validate data integrity.
Original PR description
The export generation crashed due to a mismatch between field names — the code was referencing employee_ids, while the model actually defines employee_id. Since the Prisma code is now stored on the employee model, the logic was updated to correctly access the employee_id field and retrieve the related Prisma code. Additionally, a comprehensive test suite was added to validate Prisma code behavior, including: - validation of code length for employees, companies, and work entry types, - handling of codes across different companies, - and the complete Prisma export flow (from work entry creation and validation to export file generation). task-5153727 Forward-Port-Of: odoo/enterprise#101137 Forward-Port-Of: odoo/enterprise#96743
This update resolves an issue where the timesheet grid incorrectly displayed unavailable days when flexible hours were enabled for a company. The fix ensures that all days are treated as working days when flexible hours are in use, providing accurate timesheet availability. This improves the usability of the timesheet feature for companies utilizing flexible work schedules.
Original PR description
**Description** When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days…
**Description** When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent. **Steps to reproduce** 1. Enable flexible hours on company's working schedule 2. Go to Timesheets > All timesheets 3. Switch to Grid view and filter by month 4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out **Fix** The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days. This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths: 1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback 2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found This follows the same pattern as the gantt view fix #100385 opw-5215646 Forward-Port-Of: odoo/enterprise#100881
This update fixes an issue where report start dates were incorrectly calculated based on the current date, leading to inconsistent results. The fix ensures accurate start dates for returns, regardless of the current date or custom fiscal year settings. This improves the reliability of financial reporting across Odoo's localized versions.
Original PR description
compute_fiscalyear_dates using date.today() is wrong and can lead to different start_dates depending the current date. For instance if we create a custom fiscal_year from sept 2025 to Dec 2025 and we are currently the 10th Sept 2025. Then, we try to generate a return for January. The start date would be set to the 1st Sept. Then later, when trying to generate the same return for January 2025 but being after that custom fiscal year (for instance 20th January 2026), We get a completely different start date. The fix is to avoid using the custom fiscal years in get_start_date_elements. An improvement will be done in master to add that feature. We can also safely remove the custom start_date from the belgian localization as now it is not used anymore. See: https://github.com/odoo/enterprise/pull/100034 Forward-Port-Of: odoo/enterprise#101261 Forward-Port-Of: odoo/enterprise#100022
This update corrects an issue causing VAT return XML files to be rejected by the Belgian government. The fix removes incorrect grid numbers ('46L' and '46T') from the generated XML, ensuring compliance with tax regulations. This prevents delays in VAT filing.
Original PR description
**Steps to reproduce:** - Install accountant and l10n_be_reports - Switch to a Belgian company (e.g. BE Company CoA) - Create an Intra-Community invoice: * Customer: [EU customer] * Invoice Date:…
**Steps to reproduce:** - Install accountant and l10n_be_reports - Switch to a Belgian company (e.g. BE Company CoA) - Create an Intra-Community invoice: * Customer: [EU customer] * Invoice Date: [last month] * Fiscal Position: [Intra-Community] * Invoice Lines: [a product with "0% EU M" tax] - Confirm the invoice - Go to "Accounting / Accounting / Closing / Tax Returns" - Open the period containing the created invoice - Mark all lines as "Reviewed" - Validate the VAT Return **Issue:** In the generated XML, there is a line for grid number "46L", which should not appear. Therefore, the XML is rejected by the government. Same issue with grid number "46T". These 2 grids are sub-section of grid number "46" and should not appear in the XML. Cause: Previously, they were filtered out, but since this commit https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b, the formula has changed from "46L" to "-46L" but the excluding filter has not been updated. opw-5344566 Forward-Port-Of: odoo/enterprise#101353
This update prevents users from manually closing invoices for subscription orders. Because these subscriptions automatically generate recurring invoices, closing them would disrupt the ongoing billing process. This change ensures accurate and consistent subscription billing.
Original PR description
Subscription orders with recurring plans cannot have their invoicing manually closed, as they require ongoing invoicing cycles.
This commit adds validation to the `action_close_invoicing` method to raise a user-friendly error when attempting to close invoicing for subscription orders.
task-5027819
- SEE ALSO:
Community PR : https://github.com/odoo/odoo/pull/228008This update resolves a problem where the departure holiday attest form in the Belgian payroll module was not functioning correctly. The fix ensures accurate calculation and reporting of departure holiday entitlements, improving payroll accuracy and compliance. This change impacts the HR and Payroll processes within the Odoo Enterprise system.
Original PR description
Forward-Port-Of: odoo/enterprise#101314