Daily updates from Odoo
Tuesday, June 16, 2026
16 changes · master
Resolved issues and error corrections
This update fixes an issue where the Datev export incorrectly displayed currency amounts due to a mismatch between the invoice currency and the company currency. The change ensures that tax amounts are accurately reflected in the Datev export, regardless of the invoice's currency, improving financial reporting accuracy.
Original PR description
There is an issue in the Datev export functionality. In the current functionality, the code calculates a delta between the taxes in the `tax_totals` and the ones on the journal items. Issue is, the tax amounts from tax_totals were always in company currency, while the entry itself can use a foreign one. This replaces the use of company currency with the use of the invoice's currency and appropriately adjusts the test featuring foreign currency. Steps: Create a foreign currency. Create an invoice with a taxed product using the currency. Export the ledger to Datev. Inspect the resulting csv. Note that neither the final listed price, nor the rate listed for the currency align with the ones in the db. opw-6275889 Forward-Port-Of: odoo/enterprise#120293
This update resolves an issue where inventory counts weren't accurately recording products without lot numbers. The fix ensures that new units without a lot are correctly added to inventory counts, preventing miscounts and improving data accuracy. It addresses a validation error related to how the system handles lotless products during inventory adjustments.
Original PR description
### Steps to reproduce: 1. Create a product tracked by lot 2. Put 10 units in WH/Stock without lot 3. Inventory > Operations > Adjustments > Physical Inventory 4. Select the line referring to your…
### Steps to reproduce: 1. Create a product tracked by lot 2. Put 10 units in WH/Stock without lot 3. Inventory > Operations > Adjustments > Physical Inventory 4. Select the line referring to your product and request an inventory count + Show Expected Quantity 5. Open the barcode app > Count Inventory 6. Scan your product #### > The line is not selected, in particular, next scans will be re-interpreted as product scans rather than new serial creation for your product. ### Cause of the issue: Scanning your product search a line to select if any: https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1432-L1435 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1630-L1632 However, the `findLine` will fail since this method calls the `_canOverrideTrackingNumber` to determine if the lot of the barcodData matches the one of the line: https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1859-L1863 But, the override of the `_canOverrideTrackingNumber` method for the `BarcodeQuantModel` does not handle the absence of lotName in the barcodeData correctly as it does not consider that a line without lot can be overridden by an empty lotName: https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_quant_model.js#L729-L731 Note however that the super call does: https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L795-L798 ### Issue 2: ### Steps to reproduce: - Steps 1 -> 5 - Click on your product line to select it - Scan a new lot to add one new unit referring to that lot - Confirm (1) - Apply Now #### > User Error: Quant's editing is restricted, you can't do this operation Since the line is selected, you have a currentLine during the `processBarcode` and hence the existing line will be updated using the `lotName``: https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L1560-L1584 However, writing on the line will then try to write on the related quant during the validation process which will be forbiden since we are not allowed to change the lot of an existing quant: https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/stock/models/stock_quant.py#L351-L360 Now, the issue is that actually due to the nature of the line and of the barcode data, the line lot is not expected to be updated but rather a new line is expected to be created: https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L795-L798 Additional issue: Fixing issue 1 and 2 highlight and other issue of the validation process: - Steps 1 -> 6 > The line gets selected - Scan a newlot > a new subline is added referring to 1 unit of your new quant - Confirm (1) > Some serials where not counted, set them as missing #### > Check your quants: the 10 unit lotless quant was not updated but a new quant for 1 units was created for your newlot ### Cause of the issue: Applying all quantities is expecting to toggle them as counted before applying to update the existing quants: https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L72-L82 https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L287-L296 However, only line tracked by serial numbers are set as counted: https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L60-L63 opw-6212923 Forward-Port-Of: odoo/enterprise#118373
This update fixes a potential problem where users could accidentally trigger mass email campaigns bypassing intended filters. The change prevents users from directly retrying failed mailings linked to marketing automation, reducing the risk of unintended spam and ensuring targeted email delivery. The fix includes a user error message and a hidden retry button to guide users.
Original PR description
When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing…
When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam. This commit fixes the issue by: 1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`). 2. Hiding the "Retry" button in the frontend view to prevent confusion. 3. Adding a unit test to ensure this edge case is caught in the future. Steps to reproduce: 1. Create a marketing campaign with a filter and an email activity. 2. Run the activity and ensure at least one email trace fails. 3. Open the mailing template via the "Templates" smart button. 4. Click the "Retry" button on the template form. 5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model. OPW-6220106 Forward-Port-Of: odoo/enterprise#119760 Forward-Port-Of: odoo/enterprise#118759
This update resolves an issue where bank statement imports were incorrectly multiplying amounts by 100. This was caused by a double-parsing of debit and credit values when both the bank statement extract and import modules are installed. The fix ensures the correct parsing of these values, preventing inaccurate financial data.
Original PR description
Steps to reproduce --- 1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56"). 2. Map the columns…
Steps to reproduce --- 1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56"). 2. Map the columns to Debit and Credit and import. The imported amounts are multiplied by 100: "1.234,56" is imported as 123,456.00. Issue --- This only happens when both `account_bank_statement_import_csv` and `account_bank_statement_extract` are installed, which is the default in any Accounting database since both modules are auto-installed. `account_bank_statement_extract` turns debit and credit into real Monetary fields on `account.bank.statement.line`: https://github.com/odoo/enterprise/blob/af863c5a53d0ab50fe67cb9ea910391d4a1979dd/account_bank_statement_extract/models/account_bank_statement_line.py#L7-L8 Because they are now real fields, the generic importer already converts those columns to floats: https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/base_import/models/base_import.py#L1281-L1285 The CSV statement wizard then parses the same columns a second time: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L92-L93 The first pass correctly reads "1.234,56" as "1234.56", but the second pass sees a lone dot, mistakes it for the thousands separator, strips it, and produces 123456. The wizard now parses debit and credit only when they are virtual fields, so when they are real fields the values parsed by the generic importer are reused instead of being parsed twice. Without `account_bank_statement_extract`, debit and credit exist only as virtual import fields, so the generic importer skips them and the wizard parses them once. That is why the regression stays hidden until the extract module is present. opw-6227083 --- Forward-Port-Of: odoo/enterprise#118979
This update corrects a calculation error in the GOSI (Saudi Government Social Insurance) contributions for employees with unpaid leave. The fix prortions contributions based on actual worked days, ensuring accurate deductions for employees who are absent. This improves payroll accuracy and compliance for Saudi Arabia operations.
Original PR description
Task: 6279514 Forward-Port-Of: odoo/enterprise#119990
This update addresses a missing rule in the calculation of employer costs within the Odoo Enterprise HR module. Following a review, a crucial rule was added to ensure accurate employer cost computations, building upon previous fixes. This improves the reliability of payroll and HR reporting.
Original PR description
In this previous PR https://github.com/odoo/enterprise/pull/106839 the computation of the employer cost was fixed and many rules were flagged as needed in that computation. After a report, we found one of the rules was missing so we add it in this PR. Task: 6088412 Forward-Port-Of: odoo/enterprise#112681
This update fixes a potential issue where certified point-of-sale configurations could allow users to enter negative quantities on order lines. This has now been resolved across both the backend and frontend of the system, ensuring data accuracy and preventing errors in sales transactions. This change improves the reliability and stability of our POS functionality.
Original PR description
Certified pos configs should not allow to set negative quantities on order lines. We now prevent it from both backend and frontend. see odoo/odoo#269487 task-5942777 Forward-Port-Of: odoo/enterprise#120513 Forward-Port-Of: odoo/enterprise#119702
This update resolves a previous installation problem that caused a compulsory logout. It also restores the functionality to generate payruns through the module's initialization process, ensuring accurate payroll calculations. The fix includes safeguards to prevent long-running processes and maintain system stability.
Original PR description
This commit fixes the compulsory logout that was happening when trying to install the module and also brings back the payrun generation through the init hook. It was previously commented due to an error and now it's back and working perfectly, while respecting the runbot limits so the execution don't timeout. task-6259077
This update prevents users from sending receipts directly from the Ticket Screen when the Blackbox BE feature is active. This change ensures data consistency and accuracy, particularly in scenarios where Blackbox BE is used for enhanced transaction tracking. It addresses a potential issue related to redundant receipt generation.
Original PR description
In this commit: ------------------- - Restrict the send-receipt functionality on the Ticket Screen when Blackbox BE is enabled. Task- 6139558 Related PR - https://github.com/odoo/odoo/pull/260596
This update fixes an issue where removing a BoM operation left behind unnecessary data in manufacturing quality checks. By automatically deleting related quality points and ECO changes, the system now provides cleaner, more accurate manufacturing data. This improves the reliability of production reporting and reduces data clutter.
Original PR description
Deleting a BoM operation removes the linked `mrp.routing.workcenter` record, but its instruction steps could remain in the database. Those steps are stored as `quality.point` records linked through `operation_id`. Since that relation did not cascade on deletion, removing an operation left orphaned quality points behind, creating unnecessary noise in manufacturing quality checks. This commit's change: - Set the `quality.point`'s operation_id relation to cascade on delete - Set the `mrp.eco.routing.change`'s operation_id relation to cascade on delete - Set the `mrp.eco.routing.change`'s quality_point_id to cascade on delete task-6079838
This update fixes an issue where long-term sick leave payments weren't correctly calculated for existing employee data. The change ensures that legacy sick leave records are handled properly, preventing incorrect unpaid sick leave payouts. This maintains accurate payroll processing for Belgian employees.
Original PR description
Following this task: https://www.odoo.com/odoo/project/1251/tasks/5942163, sick time offs are automatically split between paid/unpaid when the leave is created. However, existing data was not upgraded, and might result on sick leaves not being unpaid when they should. This commit re-introduces the method to ensure legacy compatibility with existing sick leaves. Upgrading the data by splitting/creating new sick leaves would be too heavy. task-6297274 Forward-Port-Of: odoo/enterprise#120546
This update resolves an issue where demo leave allocations wouldn't correctly validate during an Odoo upgrade from 17.0 to 18.0. The fix ensures that the approval process is executed during upgrades, preventing data inconsistencies and ensuring accurate leave tracking.
Original PR description
Steps: - Install an Odoo 17.0 database with the Indian Payroll module and demo data. - Upgrade the database to 18.0. Issue: - The Indian payroll demo data creates leave allocations and approves them…
Steps: - Install an Odoo 17.0 database with the Indian Payroll module and demo data. - Upgrade the database to 18.0. Issue: - The Indian payroll demo data creates leave allocations and approves them through an XML function call. - During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'. - However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function: - This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'. - When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition. - As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading. Fix: - Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'. - As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios. runbot error-https://runbot.odoo.com/odoo/error/230430 task-6268381 Forward-Port-Of: odoo/enterprise#119217
This update ensures that changes made to leave requests within the popover form are now correctly saved. Previously, modifications weren't persisted, leading to data inconsistencies. The fix automatically saves changes with a slight delay to handle rapid input, while maintaining accessibility to key actions like 'Refuse' and 'Delete'.
Original PR description
Steps:- - Navigate Payroll > Time Offs. - Create a leave of any type (STO, PTO etc...) - Click on the pill after creating leave. - Try to change values on popover. - Changed values are not saved!! Cause:- There is no save action trigger on popover form. Fix:- - Hooked `debounceAutoSave` method on every field value changes. - `debounceAutoSave` will save record with 500ms debounce to batch rapid changes. - Set popover form to readonly mode for validated leaves (validate/validate1 states) - Remove readonly condition from action buttons footer to keep Refuse/Delete accessible task-[6117310](https://www.odoo.com/odoo/project/1251/tasks/6117310) Forward-Port-Of: odoo/enterprise#120634 Forward-Port-Of: odoo/enterprise#114445
This update fixes a payroll calculation error that occurred when employees had multiple contract versions active simultaneously. Previously, the system incorrectly calculated out-of-contract deductions. The fix ensures that all worked days across all contract versions are considered, leading to accurate wage deductions.
Original PR description
…rsions on same contract **Steps to reproduce**: - Create a contract version from May 1 to May 14. - Create another contract version starting on May 15, then create an amendment version from May 20. - Generate a payslip for May using the May 20 version. - The employee receives the full monthly wage. The out of contract period (May 1 to May 14) is not deducted. **Reason**: - OUT worked days are linked to the first version of the contract starting on May 15. - When computing the OUT ratio, the system only considers worked days linked to the exact version being processed. - As a result, the May 20 amendment version does not see the OUT worked days and no deduction is applied. **Fix**: - Compute the OUT ratio using the contract start date instead of the current version, ensuring OUT worked days are correctly taken into account across all versions of the same contract. Task: 6259341 Forward-Port-Of: odoo/enterprise#120462 Forward-Port-Of: odoo/enterprise#119893
This update ensures that data isn't lost when an IoT box is removed from a point-of-sale system. Previously, deleting an IoT box could result in the loss of associated fiscal data. Now, the system verifies that the IoT box isn't currently linked to a POS configuration before deletion, safeguarding important business information.
Original PR description
Before unlinking an iot.box from the database, we must ensure that its fiscal data module is not currently used in any pos.config. task-id: 5144489 Forward-Port-Of: odoo/enterprise#110099
This update resolves a critical issue that caused OOM crashes when generating the Swedish SIE 4 report for large datasets. By optimizing the data extraction process with a single SQL query and efficient chunking, the report now runs significantly faster and uses far less memory, improving overall system performance.
Original PR description
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive…
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets. ### Current behavior before PR: When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash. ### Desired behavior after PR is merged: The method now utilizes a hybrid data extraction approach: - The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids. - A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query. - itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries. The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure. ### Benchmark: For Memory: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 407MB| | ~200,000 moves | 1.8GB | 174.8 MB| For Speed: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 5.10s | | ~200,000 moves | 1m29s| 5.3s| ### Reference: opw-6067999 Forward-Port-Of: odoo/enterprise#119303 Forward-Port-Of: odoo/enterprise#113227