Daily updates from Odoo
Thursday, December 4, 2025
9 changes · saas-18.2
Resolved issues and error corrections
This update prevents the system from accidentally changing the names of existing journals during the import process. Previously, importing journal data would overwrite existing journal names with values from the import file. This fix ensures that existing journal names are preserved, maintaining data integrity.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Go to **Accounting > Configuration > Settings**. * Download the **Import Journal Items** template. * Keep the default journal codes in…
**Steps to reproduce:** * Install the **Accounting** module. * Go to **Accounting > Configuration > Settings**. * Download the **Import Journal Items** template. * Keep the default journal codes in the template (e.g. *MISC*, *SAL*, *BNK*). * Import the file containing these existing journal codes into it by **Accounting > Configuration > Settings > Initial Setup > Import > Import Journal Items > Upload data file**. **Observed behavior:** * Existing journals have their names overwritten by the values provided in the import file. * For example, a journal with code **MISC** and name *Miscellaneous Operations* is updated to name **MISC** after import. **Cause:** * Journals are looked up by their `code`, but `_load_records()` passes both `name` and `id` for all rows. * As a result, existing journals are updated instead of preserved. **Fix:** * Pass only `id` for journals already found by code. * Pass `name` only when creating new journals. * This prevents unintended updates to existing journal names. opw-5345876 Forward-Port-Of: odoo/enterprise#100143
This update fixes a minor issue in the Belgian payroll module (l10n_be_hr_payroll_acerta) related to the error message displayed when an Acerta code is invalid. The message has been clarified to be more user-friendly and accurate, ensuring users receive clear guidance on code length requirements. This improves the overall user experience and reduces potential confusion.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll_acerta 2. Switch to a Belgian company 3. Go to Payroll → Configuration → Work Entry Types 4. Edit a record and enter an Acerta code with only 2 characters Issue: - The validation message is missing a space between `that` and `is` - The message wording is ambiguous (PO request - fdav) Fix: - Updated the validation message to: `The following work entry types have an Acerta code that is not between 3 and 6 characters` opw-5347488 Forward-Port-Of: odoo/enterprise#100432
This update prevents users from modifying existing approval requests. Allowing edits would have caused unpredictable behavior and potential errors within the system. This change ensures the integrity and reliability of the approval process.
Original PR description
There is no legitimate use case that should modify the approval request. This would result in unexpected behaviour. task-5269982 Forward-Port-Of: odoo/enterprise#101051 Forward-Port-Of: odoo/enterprise#100273
This update corrects a minor issue in how vehicle availability is determined, specifically for vehicles undergoing a change. It now correctly excludes vehicles with a 'plan_to_change' flag set to 'False', ensuring accurate availability reporting. This ensures the system accurately reflects vehicle status for payroll and fleet management.
Original PR description
Refine _get_available_vehicles_domain to consider only vehicles with plan_to_change_car or plan_to_change_bike set to True as available. This ensures vehicles planned for change but marked False are treated as unavailable. Related task: 4963484. Forward-Port-Of: odoo/enterprise#101014 Forward-Port-Of: odoo/enterprise#90812
This update resolves a bug where field syncs would disappear after inserting a new row in the Quote calculator spreadsheet. The fix ensures that field syncs are correctly maintained when expanding the spreadsheet, preventing data inconsistencies. This improves the reliability of quote calculations.
Original PR description
Steps to reproduce: - create a Quote calculator spreadsheet - add a field sync on A1 - autofill it down on a few cells - select row B - right click and "Insert row above" => some field syncs disapeared Forward-Port-Of: odoo/enterprise#101066
This update ensures the NIF (tax identification number) is now included in the BOE export for model 347 reports, as required by Spanish tax regulations. Previously, the system only included VAT, but this change corrects that to align with specific reporting requirements outlined in official documentation. Users are responsible for accurately entering the NIF in the company's VAT field.
Original PR description
[FIX] l10n_es_reports: include NIF in boe export for model 347 The NIF must be included in the BOE export for modelo 347 https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos/347.pdf pages 3 & 12. Before this commit, we read the vat but if it doesn't start with 'ES' we return an empty string because we based on TIN. Now we'll read the vat (without 'ES' if it starts with it). The user is responsible to fill a correct number in the vat field of the company. opw-5207241 Forward-Port-Of: odoo/enterprise#100489
This update resolves an issue where users couldn't assign analytic distributions to batch payments during bank reconciliation, leading to validation errors. The fix removes a restriction that was preventing edits to these payments, now allowing users to correctly apply analytics for improved financial reporting and tracking. This ensures accurate reconciliation processes.
Original PR description
**Issue** Users were unable to set analytic distributions on batch payments via the bank reconciliation widget. This limitation could lead to validation errors. **Steps to Reproduce** 1. Create two customer payments 2. Group them into a batch and validate it 3. Open the bank reconciliation widget 4. Create a bank statement line 5. Navigate to the batch payment tab and click on the batch payment 6. Attempt to click on the batch payment line **Root Cause** The method handleLineClicked was overridden in a way that prevented the call to the parent implementation when the flag was 'new_batch', disabling interactivity for these lines. **Fix** The restrictive override of handleLineClicked was removed. All fields in the Manual Operations tab are made read-only, except for analytic distributions, as this is the only field users should be allowed to edit in this context. Opw-4757131 Forward-Port-Of: odoo/enterprise#89858
This update fixes an issue where the VAT summary report for Argentinian invoices was incorrectly calculating totals when multiple IIBB taxes were applied. The fix ensures that VAT amounts are counted accurately, matching the totals displayed in the accounting form. This improves the reliability of financial reporting for Argentinian customers.
Original PR description
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#97951 Forward-Port-Of: odoo/enterprise#85873
This update simplifies the appointment calendar by showing only one period (day, week, month, quarter, or year) at a time, instead of three. This change reduces visual clutter and provides users with a clearer view of their appointments. It addresses an issue of overwhelming users with excessive information.
Original PR description
This PR displays one period of the requested scale (day, week, month, quarter and year) in the calendar instead of three. It avoids displaying unwanted periods and overwhelming users with information. Task-5022091