Daily updates from Odoo
Monday, January 12, 2026
12 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where modifying milestones linked to sales orders would trigger an error. The fix corrects a misidentification of the record ID, ensuring the system correctly updates milestones associated with sales projects. This prevents disruptions to sales workflows and improves data accuracy.
Original PR description
**Issue:** A MissingError is raised when trying to modify a milestone from a sale order **Steps to reproduce:** 1. In Sales, create a quotation based on a product milestone (this creates a project + task) 2. Confirm the quotation 3. Click the Milestone button on the sale.order 4. Modify any field in the milestone list view The error “Record does not exist or has been deleted” is raised **cause:** https://github.com/odoo/odoo/blob/61116191c6b933ca9b40863774d506f219a410a1/addons/project/models/project_milestone.py#L18-L19 The active_id being passed down is the sale order id not the project id **opw-4944212**
This update corrects a display issue where archived recurring plans continued to show up as pricing options on product pages. The fix ensures that archived plans are no longer considered during pricing selection, providing a cleaner and more accurate presentation of available plans to customers. This improves the user experience and prevents confusion.
Original PR description
**Steps to produce:** - Install `sale_subscription,website_sale` module. - `Subscription > Configuration > Recurring Plans`. - `Archive` the `Monthly` plan. - Go to website > Shop > Open product `Car…
**Steps to produce:** - Install `sale_subscription,website_sale` module. - `Subscription > Configuration > Recurring Plans`. - `Archive` the `Monthly` plan. - Go to website > Shop > Open product `Car Leasing (SUB)`. **Issue:** - Even after archiving the Monthly recurring plan, its pricing still appears on the website product page. **Root cause:** - At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans. - As a result, inactive plans are still considered during pricing selection. **Solution:** - In this fix, we ensure that recurring plan pricing is included only if the related plan is active. - Archived plans are now ignored, preventing them from appearing on the website. [1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79 before <img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" /> after <img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" /> **opw-5266333** Forward-Port-Of: odoo/enterprise#103428 Forward-Port-Of: odoo/enterprise#100587
This update corrects a bug where the FAIA XML reports generated for l10n_lu companies with products having multiple taxes were missing a crucial element (`TaxBase`). This ensures accurate reporting to tax authorities, resolving a compliance issue and improving data integrity.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103543 Forward-Port-Of: odoo/enterprise#101178
This update fixes an issue where the automated PDF generation for paychecks wasn't working when multiple payslips were being processed. The change ensures that PDFs are correctly generated regardless of the number of paychecks being created, improving payroll processing reliability. This resolves a bug that prevented scheduled PDF generation from functioning as intended.
Original PR description
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled…
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step) - Refuse all time off for "Anita Oliver" (to avoid side effect in next step) - Create a user for the employee "Anita Oliver" - Link the employee and the user - Create 2 payslips - 1 for "Mitchell Admin" - 1 for "Anita Oliver" - Compute sheet and confirm both payslips - Run scheduled action: "Payroll: Generate pdfs" - Nothing happens ### Cause: The traceback is raised on the line `self._get_document_partner().id` because `_get_document_partner()` can return a recordset. ### Solution: Call `ids` instead of `id`. ### Note: Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`. The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86). opw-5213979 Forward-Port-Of: odoo/enterprise#103548 Forward-Port-Of: odoo/enterprise#101911
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to employment bonuses. The changes ensure that bonus calculations accurately reflect payments up to March 2026, aligning with updated Belgian tax regulations. This update maintains accurate financial reporting for businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#103820
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to the 3000 deduction. The change ensures the deduction accurately reflects tax regulations up to the year 2026, improving payroll accuracy for Belgian users. This fix addresses a previously identified discrepancy.
Original PR description
Forward-Port-Of: odoo/enterprise#103824
This update resolves an issue where generating offers for new applicants in the 'Experienced Developer' role within the US company triggered a multi-company error. The fix involved creating a dedicated demo record for the Belgian version of this job position, ensuring accurate data and functionality for users in Belgium. This resolves a reported bug impacting recruitment workflows.
Original PR description
## Issue: When we go to recruitment and try to generate offer for a new applicant for job position 'Experienced Developer', it shows multi company error. ## Steps to reproduce: 1. Go to recruitment for US company 2. Make a new applicant for the position 'Experienced Developer'. 3. Then generate offer for that applicant, multi company error will come. ## Cause: The job was inherited and given `contract_template_id`. ## Fix: Made a new record for Belgium Job position 'Experienced Devloper(BE)'. backport of task-4885755 task-5445798
This update fixes an error in the Mexican payroll module that caused incorrect calculation of pay run end dates when using specific scheduling options. The code was updated to align with the standard payroll method, ensuring accurate period determination for Mexican companies. This resolves a potential issue impacting payroll accuracy.
Original PR description
Bug: When we create a new pay run for a mexican company and we select the schedule "10 Days", "14 Days", "Bi-weekly" or "Bi-monthly", the end of the period is computed incorrectly. Cause: The standard method changed but it wasn't updated in the mexican payroll module. Fix: Change the signature of the method to match the one in hr_payroll. Task: 5421825
This update fixes an issue where the ‘Next Milestone’ display in the Project list view was missing the milestone deadline. The fix ensures that milestone names now accurately include the deadline, providing users with clearer project timelines. This improves the usability of the Industry FSM module.
Original PR description
**Steps to Reproduce:** - Install the Industry FSM module. - Navigate to Project Configuration. - Enable Milestones. - Go to the Project list view. - Observe that the Next Milestone does not display the deadline along with the milestone name. **Issue:** The milestone display name is incomplete and does not include the deadline date. **Cause:** The required context was not passed in the action, so the display_name computation did not add the deadline to the milestone name. **Fix:** Pass the appropriate context in the action to correctly compute and display the name along with its deadline. Task: 5255295 Forward-Port-Of: odoo/enterprise#103895 Forward-Port-Of: odoo/enterprise#103160
This update resolves an issue where credit notes with discounts on invoice lines were failing validation by SUNAT. The fix prevents users from creating credit or debit notes with line discounts, aligning with SUNAT regulations that treat credit notes as pure amount adjustments. This ensures accurate credit note processing and avoids validation errors.
Original PR description
Steps to reproduce: - With a PE Company setup - Create an Invoice with "Document Type" set to "(01) Factura" - Set a discount on the invoice line - Confirm and send for validation - Create the credit note - Confirm the credit note and send for validation Issue: Credit note validation will fail with error `3271|El valor de venta por ítem difiere de los importes consignados. - Detalle: xxx.xxx.xxx value='ticket: 1767185167086 error: Error en la linea: 1: 3271 (nodo: "cac:CreditNoteLine/cbc:LineExtensionAmount" valor: "600.00")'` This occurs because while UBL standard allows AllowanceCharge in credit notes, SUNAT does not. Credit notes are treated as pure amount adjustments, not price recalculations. Discounts were already applied in the invoice, so SUNAT ignores AllowanceCharge in CN, causing error 3271. With this commit we introduce a check to ensure users won't post edi credit or debit notes containing line discounts opw-5414766
This update fixes a bug in the invoice import process within Odoo Enterprise v18.4. Previously, the wrong company's purchase tax could be applied when invoices were processed, particularly through automated cron jobs. This change ensures that the correct tax is selected based on the company setting, improving invoice accuracy and compliance.
Original PR description
In v18.4, the invoice import has been refactored with these 2 PRs: - [189979](https://github.com/odoo/odoo/pull/189979) - [75327](https://github.com/odoo/enterprise/pull/75327) This introduced a small bug where, in a multi-company setup, an `account.tax` could be selected from the wrong company when `_fetch_mail()` was called from the cron `Mail: Fetchmail Service` or if the method was called manually from the wrong company. Ticket: opw-5375785
This update fixes an issue where public channels in Odoo were incorrectly configured, defaulting to an internal user instead of being publicly accessible. The change sets the `group_public_id` to `None` to ensure channels are correctly designated as public, improving channel visibility and collaboration.
Original PR description
Since #206619, the fixed test has used a wrong value for `group_public_id`, as if it's not set, the default is `Internal User`. This change sets it to `None` to make the channel public. Forward-Port-Of: odoo/odoo#243237