Monday, January 12, 2026
6 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 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 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 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