Daily updates from Odoo
Monday, November 17, 2025
8 changes · saas-18.2
Resolved issues and error corrections
This update fixes how withholding taxes on payments are reflected in Philippine tax reports. It helps ensure the reported amounts match the actual taxes applied, reducing discrepancies in accounting and compliance reporting.
Original PR description
Partially backport the rework from 19 in order to ensure withholding taxes on payment affect the amounts as expected. Community PR: odoo/odoo#226794 Ref 19.0 Community: odoo/odoo#218090 Ref 19.0 Enterprise: odoo/enterprise#89830 Task [link](https://www.odoo.com/odoo/project.task/5081387) task-5081387 Forward-Port-Of: odoo/enterprise#94541
This change fixes an error that could appear when users enter a barcode manually in the barcode scanning flow, especially with GS1 barcodes. It ensures the barcode data is interpreted consistently so the barcode screen no longer crashes and users can continue their work normally.
Original PR description
This error occurs while entering the barcode number. Steps to reproduce: --- - Install `stock_barcode` module(without demo) - Setting > Barcode > Set Barcode Nomenclature = `Default GS1 Nomenclature`…
This error occurs while entering the barcode number. Steps to reproduce: --- - Install `stock_barcode` module(without demo) - Setting > Barcode > Set Barcode Nomenclature = `Default GS1 Nomenclature` - Barcode > click on `Scan or tap` > Enter a barcode(barcode number should startwith `urn` (eg: "urn:epc:tag:sgtin-96 : 3.0614141.038656.0")) > Apply Traceback: --- `KeyError: 'rule'` (with GS1 Nomenclature) `AttributeError: 'list' object has no attribute 'get'` (without GS1 Nomenclature) At [1], we expect the key `rule` to be present in the result, but this key is never set in the return statement at [2]. Since [1] also relies on the result’s type, a new key value `type` has been added in this [commit] to address that. This commit ensures that the correct keys are passed in the result dictionary. [1]- https://github.com/odoo/enterprise/blob/b001e9cc2af0f800e2a7965b61aa9b9c5bd4e89e/stock_barcode/controllers/stock_barcode.py#L29-L31 [2]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/barcodes/models/barcode_nomenclature.py#L174-L189 [commit]: https://github.com/odoo/odoo/commit/1394fa161a6fcf77b4443cbf784ad7dd635e7f9e#diff-be2a58d0591614180295c070396ff487f4bc04bf33aad2829d7bfab4671a792cR60 sentry-6992944243 Forward-Port-Of: odoo/enterprise#98761
This fix removes an access error that could block non-admin users when creating a Global Invoice in the Mexican e-invoicing flow. Regular users can now complete the process successfully without needing elevated permissions, improving day-to-day accounting operations.
Original PR description
## Issue: When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised: `Sorry, you are not allowed to access this document` ## Cause: This commit change the…
## Issue: When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised: `Sorry, you are not allowed to access this document` ## Cause: This commit change the attachment creation to use the SUPERUSER: https://github.com/odoo/enterprise/pull/95197 However, updating `attachment.res_id` then required `base.group_system` access rights, preventing regular users from modifying the attachment As a result, non-admin users (like demo) triggered an access error during Global Invoice creation ## Steps to reproduce: - Switch to the MX company - Create a product with an UNSPSC Category (Accounting Tab) - Create and Confirm an Invoice for the product (enable CFDI to public) - Connect as Demo - Go in Accounting > Customers > Invoices - Toggle the last created invoice checkbox - Actions > Create Global Invoice - Before the fix, the Access Error is displayed - Check in the invoice Chatter for the Global CFDI document creation success opw-5181925 Forward-Port-Of: odoo/enterprise#98218
This update fixes an issue in the VoIP softphone where pressing backspace could fail when a phone number selection started at the first character. It restores the expected behavior so users can delete highlighted digits normally while keeping typing protection intact.
Original PR description
This commit fixes a regression introduced in commit [1] prevented deleting when a selection began at index 0; extend the guard so the numpad (keypad) backspace still removes the highlighted characters while keeping the cursor-safety logic. [1]: https://github.com/odoo/enterprise/commit/73b01fa5e1f56d4ab71d67760b15942fb2fa0e31 task-5217676 Forward-Port-Of: odoo/enterprise#99437 Forward-Port-Of: odoo/enterprise#99358
This update brings back contact information in the Swiss payroll eLM transmission form. It ensures the needed employee details are available again when preparing payroll communications, reducing the risk of incomplete submissions.
Original PR description
task-5248986 Forward-Port-Of: odoo/enterprise#99401
This change corrects how exchange rates are calculated in the Uruguay EDI module. It now always uses the Uruguayan Peso as the reference currency, which keeps electronic invoice data consistent no matter what currency the company uses internally.
Original PR description
This PR fixes the currency rate calculation in the Uruguay EDI module to always compute the rate relative to UYU (Uruguayan Peso) regardless of the company's base currency. * Replaces the previous logic that calculated rates based on company currency with a direct UYU conversioni * Simplifies the rate calculation by removing the amount-based fallback logic * Ensures consistent UYU rate computation for all non-UYU currencies LATAM Task 1358 / Adhoc task 51716 Forward-Port-Of: odoo/enterprise#99374 Forward-Port-Of: odoo/enterprise#93144
Fixed an issue where finishing a work order directly from the status widget could skip its labor cost. With this update, the system correctly includes the work order duration in project accounting, so margin and cost figures are accurate.
Original PR description
Backport of: 223ec6ac83ba2ec94f7ea394458aee0972bb8b44 **Original msg commit:** This commit fixes the problem of adding the hourly cost of the work center when marking an operation as done from the status widget. To reproduce the bug: 1- Create a work center with an hourly cost > 0. 2- Create an MO with 1 operation in that work center, expected time > 0. 3- Create and set a project on the MO. 4- Make sure that project has an analytic account. 5- Mark the operation as done from the status widget. (click on it and choose done, don't use the start button) 6- Go to the analytic account of the project and check the gross margin. = No cost of the workorder was added. Now, this commit takes into account the duration of the WO first when marking it as done directly from the status widget. opw-5170664 Forward-Port-Of: odoo/enterprise#99439
When processing deliveries in the barcode app, scanning an available serial/lot for a reserved kit component now updates the existing reserved line instead of creating a separate one. This prevents the system from incorrectly treating the original reservation as unfulfilled and reduces unnecessary backorder prompts.
Original PR description
### Issue: Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that…
### Issue:
Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that every unscanned yet initially reserved quantity is to backorder.
### Steps to reproduce:
- Create a kit product with a kit BOM:
- 1 x COMP (tracked by SN)
- Add two Serial numbers SN001 and SN002 in stock for the COMP product
- Create and confirm a delivery order for 1 unit of oyur kit product
- Go the barcode app to process your delivery
- Scan SN002
> A new line is created instead of updating the initial reservation
- Validate the delivery
#### > A backorder dialog opens proposing to update the unscanned reservation
### Cause of the issue:
Scanning a lot will first try to find a line to update, however, currently a line will only be found if the scanned lot has been reserved or if no particular lot has been reserved:
https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L1659-L1661 https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L743-L746 In particular, since no line is considered as valid, a new line is created. And, since this new line does not refer to any `move_id` while the existing one does, the move with the initial reservation will be backordered considering none of its demand was fulfilled: https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_picking_model.js#L904-L921
### Fix:
In order to loosen the condition of lot override on barcode lines we add a check on the package and the location of the line in order to avoid use cases where the initial move line already contains info's that are proper to the initial lot.
opw-5100026
Forward-Port-Of: odoo/enterprise#98589