Friday, December 5, 2025
12 changes · saas-18.4
Enhancements to existing features
This update enhances the handling of Chilean electronic invoices by ensuring correct folio number management based on available CAF files. It also strengthens data validation for certificate information, specifically requiring a valid owner document to meet SII validation requirements. This improves data integrity and compliance.
Original PR description
This pull request introduces improvements to the handling of Chilean electronic document sequences, enforces stricter validation for certificate data, and modernizes string formatting throughout the…
This pull request introduces improvements to the handling of Chilean electronic document sequences, enforces stricter validation for certificate data, and modernizes string formatting throughout the codebase. The most significant changes focus on ensuring that document folio numbers are correctly managed in accordance with available CAFs, making the certificate model more robust, and updating code style for clarity and consistency. This improvement is mostly made because CAFs have expiration dates and fixed folio numbers. If the expiration date is reached but the folios were not fully consumed, the system will try to generate a document with following number in the sequence but an error will be raised because that number belongs to an expired CAF, althought the user had already uploaded a new CAF. To fix this, whenever the system looks for the highest number to set to a document, it previously check if that number is between the folio numbers of a valid CAF file. ### Chilean electronic document sequence management * Added `_get_last_sequence` method to `account_move.py` to ensure that the folio number used for Chilean electronic documents (DTE) is valid and corresponds to an available CAF. If no CAF is available for the current folio, the sequence is reset using the document type's prefix and starting number. ### Certificate model validation * Made `subject_serial_number` a required field in the `Certificate` model, enforcing that every certificate has a valid owner document and improving data integrity. We made this change to prevent the field being empty after loading the certificate in Odoo, since it is required by the SII to validate invoices. Forward-Port-Of: odoo/enterprise#92208
Resolved issues and error corrections
This update resolves a bug where the aged receivable report was not displaying correct data for invoices without a due date. The fix ensures the report accurately reflects outstanding balances by aligning the data source used in the report with the invoice's maturity date. This improves report accuracy and data visibility.
Original PR description
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this…
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this entry <img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" /> Observation: - on clicking the entry, when redirected to list view, there are `0` records. Issue: - The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)` https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226 - while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view - This creates inconsistencies between two. https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394 opw-5237298 Forward-Port-Of: odoo/enterprise#99883
This update resolves an error that occurred when creating time off requests, specifically when a start date was removed and the employee was changed. The fix ensures the system only checks for past dates when a start date is provided, preventing the 'bool' object has no attribute 'date' error.
Original PR description
Currently, an error occurs when creating a time off request for an employee. Steps to Reproduce: - Install the `hr_holiday` module. - Go to `Management > Time Off`. - Create a `new time off` and…
Currently, an error occurs when creating a time off request for an employee. Steps to Reproduce: - Install the `hr_holiday` module. - Go to `Management > Time Off`. - Create a `new time off` and `remove the start date`. - Now `change the employee`. `AttributeError: 'bool' object has no attribute 'date'` This error occurs when creating a time off request for an employee. If the start date is removed and then the employee is changed, the compute method [1] runs to determine whether the time off can be approved and to update the states [2]. During this process, the system checks whether the time off date is in the past, and since the start date is missing, it results in the error [3]. This commit ensures that the system only checks whether the time off is in the past when a start date is provided. [1]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L594-L597 [2]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1279 [3]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1237 No Task ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238281
This update ensures that bills automatically received through the PEPPOL network are immediately posted to the system, rather than remaining in a draft state. This streamlines the billing process and improves efficiency for partners using the PEPPOL network for invoice receipt.
Original PR description
Currently, even if a partner has auto-post bills enabled, the incoming bills stay in the draft state. This change addresses that issue. Task-5373302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238473
This update fixes an issue where tax calculations weren't automatically applied during Express Checkout using Stripe. Now, the correct tax position (based on the user's address) is applied immediately, eliminating the need for a page reload. This ensures accurate pricing and tax calculations for eCommerce users.
Original PR description
## Issue: When a fiscal position should apply based on the address provided during Express Checkout, it was not applied automatically The correct fiscal position only appeared after reloading the…
## Issue: When a fiscal position should apply based on the address provided during Express Checkout, it was not applied automatically The correct fiscal position only appeared after reloading the checkout page This issue affects public users using the eCommerce with Stripe Express Checkout ## Cause: The fiscal position was correctly determined during the `availableCarriers` computation, but it was not propagated to the payment request itself As a result, prices and taxes were only updated after a full page reload ## Steps to reproduce: - Configure Stripe with Express Checkout (e.g., Google Pay) - Create a fiscal position with automatic detection (Country = US, Tax mapping: 15% → 0%) - Create a product using the 15% tax - Go to the website shop and add the product to the cart - Use Express Checkout with a US address - Observe that the fiscal position is not applied unless the page is reloaded opw-5018238 Forward-Port-Of: odoo/odoo#238690 Forward-Port-Of: odoo/odoo#236832
This update resolves an issue where users without the correct permissions couldn't upload documents to activities. The fix checks user rights before attempting the upload, preventing errors and ensuring all users can properly attach files to activities. This improves the usability of the Project management feature.
Original PR description
Step To Reproduce: - install Project - login with admin and open any Project settings, say Project 1. - create a upload document activity for 'marc demo' - ensure marc demo has 'User' access for…
Step To Reproduce: - install Project - login with admin and open any Project settings, say Project 1. - create a upload document activity for 'marc demo' - ensure marc demo has 'User' access for project - login with marc demo - open same project (kanban card -> view) - upload a document for the created activity Observation: - Traceback ``` TypeError: Cannot destructure property 'id' of '(intermediate value)' as it is undefined at Activity.onFileUploaded ``` Cause: - upload request to `/mail/attachment/upload` , calls `mail_attachment_upload` which then tries to access thread for 'write' mode, 'project.project ' model . - as marc demo does not have write access to this model, no thread is returned - so `NotFound()` is raised https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mail/controllers/attachment.py#L48-L55 Fix: - we check if selected user has appropriate rights or not for upload activity opw-5160132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238360 Forward-Port-Of: odoo/odoo#234936
This update resolves an error that occurred when creating time off allocations with hourly time off types, specifically when all attendance entries had start and end dates. The fix prevents a division-by-zero error, ensuring time off allocations are created correctly. This addresses a symptom of a deeper issue with how attendance dates are handled, but doesn't fully resolve the underlying problem.
Original PR description
_ ## Short functional explanation of the error When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding…
_ ## Short functional explanation of the error When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised. ## Reproduction Steps 1. Go to Employees and click on the Configuration tab > Working Schedules. 2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date. 3. Set a starting date for each entry. 4. Go to Time Off. Click on the Configuration tab > Time Off Types. 5. Click on a time off and next to the Take Time Off in, select Hours. 6. Click on the Management tab > Allocations. Click on New. 7. Select an employee that has the schedule you updated earlier. ## Expected behavior The allocation is created. ## Unexpected Behavior A traceback occurs: ``` ZeroDivisionError: float division by zero ``` ## Origin of the issue When setting a start or/and an end date to an attendance, this attendance won't be taken into account for global attendances anymore. This leads to an erroneous computation of hours_per_day, leading to a few issues; one of them is related to time off allocation: When setting a time off with a time off type expressed in hours, if every single attendance in the calendar has a start/end date, there will be no global attendance hours left, leading to a division by 0: https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262 After discussion, we decided that this fix would only fix a symptom, and not the problem itself. _ opw-5340056 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237782
This update resolves an issue where the timesheet grid incorrectly displayed unavailable days when flexible hours were enabled for a company. The fix ensures that all days are treated as working days when flexible hours are in use, providing accurate timesheet availability. This improves the usability of the timesheet feature for companies utilizing flexible work schedules.
Original PR description
**Description** When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days…
**Description** When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent. **Steps to reproduce** 1. Enable flexible hours on company's working schedule 2. Go to Timesheets > All timesheets 3. Switch to Grid view and filter by month 4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out **Fix** The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days. This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths: 1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback 2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found This follows the same pattern as the gantt view fix #100385 opw-5215646 Forward-Port-Of: odoo/enterprise#100881
This update corrects a previous error in the EPF (Employee Provident Fund) tax calculations for Malaysian employees. The changes ensure accurate rounding of tax amounts to the next ringgit, aligning with current legislation. This update improves the accuracy of payroll processing for Malaysian businesses.
Original PR description
Previous behavior did not account for the rounding of the amount of tax to the next ringgit. Also the employee's rate has been updated in accordance to the legislation. task-5286179 Forward-Port-Of: odoo/enterprise#100736
This update resolves an issue where onchange events in Odoo didn't consistently update related records when multiple One2many fields were involved. Specifically, it ensures that all relevant changes are reflected across related records during updates, improving data consistency and accuracy. This fix addresses a potential data discrepancy and enhances the reliability of Odoo's record management.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where scanning a lot multiple times during a barcode picking process would incorrectly create a backorder. The fix ensures that quantity updates are applied correctly to the relevant lines, preventing unnecessary backorders and improving order fulfillment accuracy. This change resolves a bug related to how the system interprets lot scans.
Original PR description
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm -…
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm - open the picking in barcode - scan the stock location - scan the lot - scan the lot another time - validate **Current behavior:** a backorder is created **Expected behavior:** No back order should be created **Cause of the issue:** After scanning the lot for the first time we have the following situation: two lines : - one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1 - one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1 both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2 All of this is correct. when scanning the lot for the second time: _findLine iterates through the lines to select the right line to use. _findLine calls _lineIsNotComplete on the first line to check if it's complete (this first line is complete). https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684 But _lineIsNotComplete will actually do the check on the parent line (which is not complete), so the return value will be true. https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338 As a consequence, the quantity will be added in the first line and we will have a qty_done of 2 in the first line and a qty_done of 0 in the second line. Which will lead to the creation of a back order opw Forward-Port-Of: odoo/enterprise#100912 Forward-Port-Of: odoo/enterprise#99774
This update corrects a problem that arose in the production environment after migrating to versioned employees. The fix ensures that time off calculations only consider employees and their companies, preventing incorrect totals when calculating paid time off. This improves data accuracy and reliability for payroll processing.
Original PR description
this commit fixs an issue introduced in production by adding a where clause to select employees and their version belonging to the selected companies only. This prevents from accessing employees from other companies later when summing the attestation days that might not be accessed by the user. task-5386951