Daily updates from Odoo
Monday, September 15, 2025
5 changes · master
Resolved issues and error corrections
POS GST reports in India now report service product quantities as zero, matching GST portal requirements. This prevents validation errors during filing while keeping normal quantity reporting unchanged for goods.
Original PR description
Before this PR: - Service products in POS GSTR lines were reported with their actual quantity. - This caused GST portal validation error: `RET191355: The Quantity entered is not valid`. After this PR: - For service-type products, `qty` is always set to `0`. - For goods, `qty` continues to reflect the actual ordered quantity. OPW: 5070636 Forward-Port-Of: odoo/enterprise#94607 Forward-Port-Of: odoo/enterprise#94272
This fixes an issue that prevented users from saving the document sorting setup for Finance folders when certain pinned actions were present. It also avoids selecting actions by default that the AI assistant cannot reliably run, reducing failed automation attempts while still allowing users to choose them manually if needed.
Original PR description
Bug === When trying to save the sort wizard for a folder having a pinned multi action, with a `documents_account_record_create` child action, then the constraint `_check_use_in_ai` was triggered, and it shouldn't. The reason is the way recursive compute work, we can not set `False` as the default, because it will allow the parent to be computed with that. Task-5077569 Forward-Port-Of: odoo/enterprise#94290
Fixed an issue where German DATEV reporting could miss the main account when a POS session contained both sales and refunds with different tax rates. The export now reliably selects the correct account, helping ensure complete accounting data for affected POS entries.
Original PR description
In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to…
In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to searching for a unique non-tax line among debit or credit lines. In POS, however, there is the possibility of generating journal entries that break this flow: - In a single POS session, add product A with tax 19% and product B with tax 7%. - In the same session, refund product A. - Close the session to generate the entries. In the resulting entry, since both sale and refund are present, it is not possible to discriminate using debit and credit amounts alone, and as a result, the field l10n_de_datev_main_account_id is not populated. Since account 1411 is always the one to be used for l10n_de_datev_main_account_id in this specific case, this commit adds a final fallback filter to select the correct line and ensure the field is populated. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4915272) opw-4915272 Forward-Port-Of: odoo/enterprise#92664
Default salary input values now appear as expected when payroll rules are selected for employees or payslips. This helps payroll teams avoid manual corrections and reduces the risk of incorrect payslip calculations.
Original PR description
## Steps to reproduce 1. Make a new salary rule with condition based on 'salary input'. 2. Enable 'Input on' employee and payslip both and set a default value. 3. Go to employees 'Payroll tab' and 'add inputs', then select the rule. 4. Similary in 'Payslip' on 'Salary inputs' tab, 'add inputs' and select the rule. ## Issue - The default values on the employee and payslips were not being reflected on selection of the rule. ## Fix - Modified '_update_payroll_properties'. It now fetches active_id and updates properties based on the default values of input rules. - Updated '_compute_payslip_properties'. Ensures that payslips without common payroll properties fall back to the default values of the related input rules. task-5072646
Repair orders with quality checks can now be saved without triggering an error. This prevents interruptions when users work with repaired products and their lot or serial numbers.
Original PR description
Issue: ---------------------------------------- When creating a repair order that has a quality point (defined for all products or for a specific product), or when trying to create a new lot/serial…
Issue: ---------------------------------------- When creating a repair order that has a quality point (defined for all products or for a specific product), or when trying to create a new lot/serial number from the repair order, a traceback is triggered: `ValueError: Invalid field 'lot_id' in 'quality.check'` Steps to reproduce: ---------------------------------------- - Install the `quality_repair` module. - Create a Quality Point for Operation: Repair Orders and set Control per Product/Operation. - Create a Repair Order and add a product to repair. - Save the Repair Order. - Traceback is triggered. Cause: ---------------------------------------- In PR https://github.com/odoo/enterprise/pull/90930, the `lot_id` field was replaced by a many2many field `lot_ids`. Repair orders were still trying to assign `lot_id`, causing the error. Solution: ---------------------------------------- In this commit, we ensure that `lot_ids` is set properly, allowing repair orders with quality checks to work smoothly and enabling users to assign lots/serial numbers without triggering errors. Task ID:- 5067457 Forward-Port-Of: odoo/enterprise#94199