Daily updates from Odoo
Wednesday, March 25, 2026
13 changes · saas-18.2
Resolved issues and error corrections
This update corrects a technical issue related to how fields are populated during the creation process within Odoo. Specifically, it ensures that the correct model is used when creating certain fields, improving data accuracy and reliability. This change primarily impacts the HR and Payroll modules.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#109725
This update resolves an issue where the AEAT tax report file was being rejected due to an incorrect date format. The fix ensures the file includes a default numeric date ('00000000') when the procuration date is not specified, meeting AEAT's requirements and allowing successful file uploads.
Original PR description
Steps to reproduce: - Install the `l10n_es_reports` module and switch to the `ES company`. - Go to Invoices and create an invoice with taxes, then confirm it. - Navigate to Accounting > Reporting >…
Steps to reproduce: - Install the `l10n_es_reports` module and switch to the `ES company`. - Go to Invoices and create an invoice with taxes, then confirm it. - Navigate to Accounting > Reporting > Tax Report. - From the smart button, select `Report: Tax Report (Mod 390) (ES)` and choose the year as `This Financial Year`. - Download the `BOE` file using the dropdown and fill the wizard fields (e.g., Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345). - Upload the generated .txt file to the AEAT portal. (AEAT credentials are required) **Observation:** AEAT rejects the file with: `Caracteres no válidos '4. Representante - Personas Jurídicas - Represent. 1 - Fecha Poder (DDMMAAAA)'` **Root cause:** At [1], when `judicial_person_procuration_date` is `false`, an empty string is written to the BOE file, resulting in blank spaces in the exported file. This does not comply with AEAT’s required numeric format and causes the file to be rejected. **Fix:** This commit ensures the file contains '00000000' when `judicial_person_procuration_date` is false, complying with AEAT numeric format requirements. [1]: https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/l10n_es_reports/models/aeat_tax_reports.py#L1696 opw-5995290 Forward-Port-Of: odoo/enterprise#109652
This update fixes a potential issue where a user could indirectly change an employee's work email through salary contract settings. The change ensures that an employee's work_email remains consistent, regardless of whether they are linked to a user, improving data integrity. This resolves a bug identified in a previous pull request.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974 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 Forward-Port-Of: odoo/enterprise#111243
This update fixes an issue where barcode scanning with a different serial number than the reserved one didn't create a new lot in stock. The fix ensures that the correct lot is always used when scanning a batch, preventing incorrect inventory tracking. This improves the reliability of the barcode scanning process.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#111696
Forward-Port-Of: odoo/enterprise#109671This update automatically removes all scheduled future appraisals and associated data when an employee leaves the company. It also removes the employee from appraisal roles and archives their personal goals, ensuring data accuracy and a cleaner system after departures. This improves the HR process and reduces manual effort.
Original PR description
Currently, when an employee leaves the company, their future appraisals remain active and can still be completed. This fix ensures that, upon employee departure: - all future appraisals are removed - the employee is removed from appraisals where they are an appraiser - all their personal goals are archived task: 6036427
This update prevents data merge operations from silently failing due to timeouts. Instead, a warning notification is displayed, guiding users to merge smaller groups of records and reload the model upon successful completion. This enhances the reliability of the data cleaning process.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update corrects a technical issue where the system was incorrectly limiting VAT numbers submitted to FedEx, causing problems for customers using VAT numbers with longer formats (like in Switzerland). The change ensures that VAT numbers are properly transmitted to FedEx, preventing delivery errors and maintaining accurate data.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452 Forward-Port-Of: odoo/enterprise#109999
A recent bug prevented newly created approval rules in the Studio interface from being properly saved, leading to their automatic deletion. This issue arose during an upgrade from version 18.0 to 19.0 and was triggered by how the system created records for revoking approval rights. The fix ensures these records are created with a flag preventing automatic deletion.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update corrects a bug in the Belgian payroll module that incorrectly calculated canteen costs for employees with no attendance. The fix ensures that canteen costs are only applied when the employee has recorded actual working hours, preventing incorrect charges. This improves payroll accuracy for Belgian companies.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#110991This update fixes an issue where project budget totals were incorrectly summing expense and revenue amounts. The change adjusts how budgets are calculated, ensuring that expenses and revenue are treated as separate values when determining total spending and allocation. This improves the accuracy of project financial reporting.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update corrects a legal requirement for invoices generated using the l10n_gt_edi module. Previously, certain document types (FCAM, FCAP, FESP) lacked essential 'complementos' attachments in the PDF invoice, while they were present in the XML. This fix ensures compliance and proper invoice formatting.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285 Forward-Port-Of: odoo/enterprise#109061
This update resolves an issue where ISO20022 XML files generated for Swiss companies were being incorrectly formatted, leading to bank rejections. The fix ensures the correct 'PAIN 09' version is used, aligning with bank requirements after upgrading to version 18.2. This prevents delays in payment processing for our Swiss clients.
Original PR description
To reproduce the issue:
- Create a database in 17.0, with a Swiss company, and install account_sepa. Make sure the bank journal uses the Swiss IS020022 PAIN version.
- Migrate this database to 18.0
- Generate an ISO20022 xml file for the Swiss company
==> The file is wrongly formatted, and will be rejected by the bank.
This happens because the sepa_pain_version field of the journal is still set to its old selection value ('pain.001.001.03.ch.02') after migration, which is not supported anymore. The ORM hence returns an empty value when accessing the selection field, and does not enter the proper conditions when generating the file.
An upgrade fix has been made here https://github.com/odoo/upgrade/pull/9771. This commit makes sure already-migrated databases dynamically fix the issue as well.
opw-6060612
Forward-Port-Of: odoo/enterprise#111949This update fixes an error preventing Point of Sale sessions from closing correctly in version 18.2. The issue stemmed from an incorrect method name in the 'l10n_de_pos_cert' module, which was preventing the correct cash move formatting. Renaming the method ensures proper session closure and accurate cash transaction recording.
Original PR description
**Steps to Reproduce:** 1. Start a new Point of Sale session from the Odoo backend. 2. Create and validate a POS order to ensure the session contains at least one transaction. 3. In the POS…
**Steps to Reproduce:** 1. Start a new Point of Sale session from the Odoo backend. 2. Create and validate a POS order to ensure the session contains at least one transaction. 3. In the POS interface, open the menu (☰ icon) in the top-right corner. 4. Navigate to the Cash In/Out functionality. 5. Perform a cash operation: - Select either Cash In or Cash Out - Choose a Category Reason - Select a Type Reason - Confirm the operation 6. Attempt to close the POS session. **Issue:** In version saas-18.2, an error occurs when closing the POS session because the name of the cash move (in the Cash Register) is incorrect. It should be formatted as: `Hauptmarkt/00006-out-category reason-reason` However, it is currently generated as: `Hauptmarkt/00006-out-reason` This happens because the method `"_prepare_try_cash_in_out_payload"` in "l10n_de_pos_cert" is not called due to an incorrect method name. **Solution:** The issue is resolved by renaming the method to the correct name `"_prepareTryCashInOutPayload"`. This ensures the proper method is invoked, generates the correct cash move name, and allows the POS session to close successfully. opw-6059143