Tuesday, March 25, 2025
19 changes
1 change
Resolved issues and error corrections
This fix improves tax calculations when down payments or global discounts are used on Italian sales and point-of-sale orders. It helps ensure final invoices show accurate rounded tax amounts, reducing billing discrepancies and correction work.
Original PR description
Fix the tax rounding issues in down payment and global discount applied on sale orders and pos orders. To do so, this commit introduces a new field 'extra_tax_data' allowing to split the global taxes computation on subset of lines. This is usefull on the down payment because, when generating the final invoice, the first down payment is subtracted with negative lines. However, those lines represent a separated document so the taxes computation in round globally has to be split between the original lines and the negative down payment lines. This extra field could also contain manual tax amounts to be taken into account in the taxes computation engine. task_id: 4457175
18 changes
Resolved issues and error corrections
The Sales app now calculates the uninvoiced balance correctly when discounts are applied to sales order lines. This prevents discounted amounts from being reduced twice, giving users a more accurate view of what still needs to be invoiced.
Original PR description
Steps to reproduce: - Create SO with two products. - Apply 10% discount to both lines. - Confirm SO and create an invoice. - Confirm invoice for only one SOL. - Go to 'Orders to Invoice' and add uninvoiced-balance field to the view using Studio. - Check value of the uninvoiced-balance field. Issue: - The uninvoiced-balance field is not calculated correctly. Cause: - line.price_total already includes the discount, so applying the discount again results in an incorrect calculation. Fix: - Remove price_reduce and directly multiply unit_price_total by qty_to_invoice to ensure the correct calculation of amount_to_invoice. opw-4567563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where accounting document numbers could fail to continue correctly when multiple users or processes created documents at the same time. It helps keep invoice and journal entry numbering consistent and prevents disruptions in accounting workflows.
Original PR description
When looping inside of the `while True` loop because of concurrency, the `sequence_prefix` was not correctly set. This was breaking the behavior of `sequence.mixin` because we were not able to get the last number. Partial revert of 10565c6968a5d0f285f93c4bdc610350999a88e3
Users assigned to a child company in a Belgian company structure can now open the Point of Sale without running into an access error. This matters because shops operated under branch or subsidiary companies can use POS normally even when accounting setup is managed at the parent company level.
Original PR description
Some users are encountering access error when opening the pos from a child company Steps to reproduce: ------------------- * Create a child company for "My Belgian Company" * Register this company for the user Marc Demo * Create a shop in the brach * Now connect as Marc Demo * Try to open the PoS > Observation: Access error Why the fix: ------------ Account chart template are only defined in the parent company. opw-4644042
This fixes issues where employees or resources with flexible working hours could still be treated as having standard attendance hours. It prevents Attendance from failing with a division-by-zero error when a working schedule is changed to flexible hours.
Original PR description
## [FIX] resource: make sure flexible resource don't use attendances This commit makes sure the resource calendar attendance is not used for a flexible resource even if that resource has a working…
## [FIX] resource: make sure flexible resource don't use attendances This commit makes sure the resource calendar attendance is not used for a flexible resource even if that resource has a working schedule with hours per day equals to 0 hour. ## [FIX] hr: recompute is_flexible when working schedule becomes flexible Before this commit, when the user sets a working schedule to an employee and convert that working schedule into a flexible working schedule, the employee is not considered as working with flexible hours. This commit makes sure the `_compute_is_flexible` method defined in `hr.employee` model is triggered when the `flexible_hours` field of the working schedule linked to the employee is altered. Steps to reproduce the issue: ----------------------------- 0. Install Attendance app (`hr_attendance` module). 1. Set a working schedule A to employee E 2. Go to the form view of the working schedule A and check `Flexible Hours` field to convert the working schedule as flexible working schedule. 3. Go to Attendance app Expected Behavior: ----------------- The Attendance app should loaded without any issue. Current Behavior: ---------------- A traceback is occurred saying we have a division by zero. opw-4492625
This fix ensures loyalty history only counts activity tied to the correct sale order type. It prevents eWallet or loyalty amounts from being inflated when point-of-sale and online orders happen to share the same internal ID.
Original PR description
Description of the issue/feature this PR addresses: - Setup an eWallet for POS and website - Place an order of eWallet top up from POS - Place an order of eWallet top up from ecommerce - Make sure both has the same ID, or any POS order that has the same ID with sale.order ID - You will see the loyalty issued becomes the sum of the unrelated model Current behavior before PR: - The loyalty showed in Portal / Odoo will be wrong if it clashes with other model ID Desired behavior after PR is merged: - Only consider the order that comes from the sale order model --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves Odoo IoT display handling so connected displays can be detected and rotated correctly when running under Wayland. It helps point-of-sale and IoT display setups remain reliable on newer Linux display environments.
Original PR description
This commit is a backport of the display driver changes from commit 078533b. These changes allow displays to be detected and rotated correctly under Wayland. task-4657986 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update bundles several bug fixes across Odoo, including faster loading of image-heavy kanban views, corrected invoice dating for Argentina, improved checkout handling for Brazil, and compliance updates for German e-invoicing. It also resolves smaller issues in messaging, POS loyalty flows, inventory route searches, and spreadsheet styling, reducing user friction and business process errors.
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 fixes an issue in the HTML editor where clicking text above a large image could unexpectedly scroll the page to the image, making the text difficult to edit. The editor now only scrolls when most of the selected content is out of view, keeping editing stable and predictable.
Original PR description
**Problem**: When adding text followed by **"Shift+Enter"** and a long image, clicking to edit the text triggers `scrollTo`, causing the view to jump to the image instead. This makes it impossible to edit the text, as the selection keeps switching to the image. This happens because, on `pointerdown`, the selection changes to text, triggering a scroll. On `pointerup`, the target becomes the image, changing the selection again. **Solution**: Scroll only if more than half of the content is not visible. **Steps to Reproduce**: 1. Add text and press **"Shift+Enter"**. 2. Insert a long image below the text. 3. Try to edit the text: - **Issue**: View scrolls to the image, making text uneditable. opw-4606741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the Time Off allocation form from crashing when a user opens it in a company where they do not have an employee record. The system now uses a safe fallback for hours per day, allowing managers to create allocations without interruption.
Original PR description
Steps to reproduce the bug: - Install Timeoff app - Switch to a company that has no employee linked to loggedInUser - Open Timeoff, Management then Allocation and create a New allocation Issue: _compute_number_of_hours_display is called due to onChange of number_of_days when opening the form view. The compute hours function displays as the initial value the number of hours/day of the employee of the allocation. The allocation defaults to the employee linked to loggedInUser, but since the company has none, the allocation form employee is set to empty, causing the compute hours function to fail and throw a traceback. opw-4648319 opw-4652752 opw-4649177 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 fix prevents an error when selling combo products in the German POS certification flow. Combo products are handled correctly without requiring tax settings that should not apply to them, helping sales proceed smoothly.
Original PR description
Before this commit, attempting to sell a combo product resulted in an error due to a missing tax configuration. However, combo products are not supposed to have taxes assigned, leading to an unintended issue. opw-4555159
Restaurant staff can now split POS orders without triggering a system error after a browser refresh. This improves checkout reliability and reduces disruptions during service.
Original PR description
Before this commit, in the restaurant, splitting an order could result in an `IndexError: list index out of range`. This issue occurred due to incorrect handling of order lines during the split process. This fix ensures proper validation and handling of order lines to prevent such errors, improving the stability of the POS system. Steps to reproduce: - Create an order - Refresh browser - Attempt to split the order. - Observe the `IndexError: list index out of range` traceback. opw-4451836
Payment links can no longer be created or used for orders that have already been renewed. This prevents old renewed orders from being reopened by a payment, avoiding duplicate active subscriptions for the same customer.
Original PR description
Before this commit, it was possible to pay payment links linked to renewed orders. It would cause issues as the renewed order would be reopened once the transaction was set to done. Two subscription in progress would live side by side. This commit ensure that such links can't be created and existing links can't be used. taskid: 4607315
German Point of Sale sessions using Fiskaly certification no longer send an extra blank receipt to the printer when automatic receipt printing is enabled. This prevents confusing printer errors and avoids wasting paper during checkout.
Original PR description
When automatically sending the receipt in a DE PoS, there was 2 receipt sent to the printer, one of them was empty and showing an error. Steps to reproduce: ------------------- * Setup a fiskaly PoS * Activate the automatic receipt printing * Open PoS and make an order * Pay the order > Observation: Two receipt are sent to the printer, one of them is empty and showing an error. Why the fix: ------------ We were calling the `super` method twice. This was causing the receipt to be printed twice. We now call the `super` method only once. opw-4520201
Refund invoices are now treated as negative amounts when calculating sales commission achievements. This prevents refunded sales from incorrectly increasing commission totals, improving payout accuracy.
Original PR description
Version: 18.0 When the invoice is a refund, it should reduce the achievement's amount and not increase it. opw-4610960
Refreshing an open Sign document or template now returns users to that same item instead of sending them back to the overview list. This preserves context and reduces disruption when working with signed documents or templates.
Original PR description
This commit fixes the redirect to the documents view when reloading the page of an opened document by restoring the client action context and setting the document name as the display name of the document. task-4323698
This fix prevents the Documents app from crashing when upgraded databases contain older document records with incomplete linked-record information. Users can open the Documents app normally even if some legacy records have missing reference fields.
Original PR description
For databases upgrading to v18 if any `documents.document` records have `NULL` value i.e, `res_id` is present but `res_model=NULL` similarly `res_id=NULL` but `res_model` is present While accessing…
For databases upgrading to v18 if any `documents.document` records have `NULL` value i.e, `res_id` is present but `res_model=NULL` similarly `res_id=NULL` but `res_model` is present
While accessing the documents app by default kaban view is loaded which has `res_id` in its arch after this commit: odoo/enterprise@a32825e
If such records exist it will lead to traceback during `web_search_read` calls while accessing the documents app
```py
File "/home/odoo/odoo/odoo/addons/web/models/models.py", line 46, in web_search_read
values_records = records.web_read(specification)
File "/home/odoo/odoo/odoo/addons/web/models/models.py", line 186, in web_read
co_record = self.env[record[field.model_field]].browse(record[field_name])
File "/home/odoo/odoo/odoo/odoo/api.py", line 596, in __getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/odoo/odoo/odoo/modules/registry.py", line 240, in __getitem__
return self.models[model_name]
KeyError: False
```
Previously, these types of records did not cause any issues due to the absence of res_id in the Kanban view.
OPW - 4527152This fixes an issue where users could not cancel certain Mexican payments after a related CFDI document had been sent to the government. The change prevents an error during cancellation, helping accounting teams correct or reverse payments without manual technical intervention.
Original PR description
When canceling a payment linked to an entry, we try to unlink the entry, but we end up in the following constains: `ir_attachment._unlink_except_cfdi_document` Steps: - Create, confirm an invoice and sent cfdi - Register a payment with `Por Definir` as payment method - Click on `Update Payments` - On CFDI tab, click on `Force CFDI` on payment line - Go to the payment - Reset it to draft and cancel it -> Error: `You can't unlink an attachment being an EDI document sent to the government.` Fix: Backport of https://github.com/odoo-dev/enterprise/commit/6f21aedf1a107acb4c89f7a8264171597068e102 opw-4644528
Batch payment totals are now calculated using the best available amount source, including the related invoice or bill amount when needed. This helps ensure payment batches show accurate totals in the correct currency, reducing reconciliation and payment processing errors.
Original PR description
This commit change the way amount are computed in batch payment: Amount are now computed in this order: 1 - amount of journal entry (old) 2 - amount of account move (new) 3 - amount of payment (old) opw-4574834