Daily updates from Odoo
Saturday, July 26, 2025
4 changes · 18.0
Resolved issues and error corrections
Invoice rounding differences are now spread across invoice lines instead of being applied to a single line. This helps generated UBL/Peppol invoices stay within validation limits and reduces the risk of rejected electronic invoices.
Original PR description
Before this commit, the behaviour of `_round_base_lines_tax_details` was to assign all the base line delta to the largest base line. However, when generating the UBL, the delta would then get included in the LineExtensionAmount, but BIS3 rule PEPPOL-EN16931-R120 enforces that the LineExtensionAmount must be at most 2 cents away from `(quantity * net price) + sum(charges) - sum(allowances)`. Effectively this means that we can put at most 2 cents base delta on each invoice line. After this commit, `_round_base_lines_tax_details` redistributes the base delta evenly over all the base lines. task-none
This fix prevents the same point-of-sale order from being sent to preparation printers by multiple devices. It checks whether an order was already sent and synchronizes the order after printing, reducing duplicate tickets and kitchen confusion.
Original PR description
Before this change, when a device sent an order in preparation via the ticket printer, this could result in the same order being printed by multiple devices, as the order was not synchronized after it was sent. The error is a bit tricky, because if the user had installed a preparation screen, the order was sent to the preparation screen via syncAllOrders. In this case, the order was correctly synchronized and the other devices were informed of the changes. This commit adds two things. - We check the server before sending the order to preparation to make sure it has not already been sent. - Even when the user does not have a preparation display, the order will be synchronized after being sent to a printer.
This fix prevents the same point-of-sale order from being sent to preparation printers by multiple devices. It checks whether an order was already sent and keeps devices synchronized after printing, reducing duplicate tickets and operational confusion in restaurants or stores.
Original PR description
*: pos_urban_piper_enhancements Before this change, when a device sent an order in preparation via the ticket printer, this could result in the same order being printed by multiple devices, as the order was not synchronized after it was sent. The error is a bit tricky, because if the user had installed a preparation screen, the order was sent to the preparation screen via syncAllOrders. In this case, the order was correctly synchronized and the other devices were informed of the changes. This commit adds two things. - We check the server before sending the order to preparation to make sure it has not already been sent. - Even when the user does not have a preparation display, the order will be synchronized after being sent to a printer.
Users with timesheet access can now start and stop timers on tasks they are allowed to access, even when the parent project is private. This prevents access errors and lets field service teams record time normally on assigned work.
Original PR description
Before this commit, when the project is private and the user can only access to some tasks inside that project, he can create timesheets but cannot stop timer in one of those tasks when `industry_fsm` module is installed. This commit makes sure the user can start/stop a timer on task for which he has access to even if the project is private and he does not have access to it. Steps to reproduce the issue: ---------------------------- 0. install industry_fsm module 1. Create a project A with "followers" as privacy visibility 2. Create a task A and assign it to a project user with lowest timesheet access right. 3. log in as that user 4. Start a timer on Task A 5. Stop the timer and confirm the wizard Expected Behavior: ----------------- The timesheet should be created without any issue Current Behavior: ---------------- An Access error is raised because the user has no access to the project. task-4680412 Forward-Port-Of: odoo/enterprise#84807