Monday, May 11, 2026
6 changes · saas-18.2
Resolved issues and error corrections
This update fixes a limitation in the Helpdesk system where returns for dropshipped orders couldn't be processed. Now, users can correctly initiate returns for dropshipped transfers directly from the Helpdesk ticket, streamlining the returns process and improving customer service. This ensures all order types, including dropshipped ones, can be managed effectively.
Original PR description
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and…
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and quantity under the Purchase tab - Create a sale order for the product - Go to the Purchase stat button and confirm the order - Click on the Dropship stat button and validate the transfer - Open Helpdesk and create a new ticket for the same partner ### Issue: The "Returns" stat button is not visible for dropshipped deliveries. ### Current behaviour: - The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor. - With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket. ### Expected behaviour: Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO). ### Fix: The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket Issue:https://github.com/odoo/enterprise/pull/81378 task-4881338 Forward-Port-Of: odoo/enterprise#91402
This update resolves an issue where the 'Add a line' button was unresponsive at the top of mobile grid views (like Timesheets). The fix adjusts how elements are sized on smaller screens, ensuring the button is always clickable. This improves the user experience for mobile users accessing grid data.
Original PR description
**Steps to reproduce** On mobile: - Open a grid view (e.g. Timesheets > All timesheets) - Try to click on "Add a line" for the first employee - Issue: nothing happens. Notice that by scrolling down the list to employees at the bottom, it becomes possible to click on "Add a line". **Cause** `o_grid_cell_overlay` elements (with `h-100`) were taking more than the expected height in mobile, because the `o_grid_section_title` divs only have `position: sticky` on larger viewports. With the default `position: static`, the child element's height was exceeding its parent's height. opw-5853489 Forward-Port-Of: odoo/enterprise#113400
This update fixes a bug where importing a product with a changed subscription type could bypass a necessary warning. Previously, the system would process the import without alerting the user that they were modifying a product already sold as a subscription. Now, a warning is raised to prevent accidental changes to subscription products after they've been sold.
Original PR description
__ ## Short functional explanation of the error When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription…
__ ## Short functional explanation of the error When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior: when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised. ## Reproduction Steps Make sure you have debug mode enabled. 1. Create a product, and check the Subscription box. 2. Click on Orders and create a Quotation with this product, then confirm. 3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export. 4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded. 5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes. 6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import. ### Expected behavior A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold. ### Unexpected behavior The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised. ## Origin of the issue Nothing prevents the import from occurring in that case. __ opw-6143789 Forward-Port-Of: odoo/enterprise#115046
This update fixes an issue where freight charges were incorrectly applied to all pickings, particularly with backorders. The change ensures freight costs are accurately reflected only on the initial, confirmed picking, aligning with how delivery costs should be billed to the customer.
Original PR description
Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result: 1. When creating backorders, the `freight_costs` are…
Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result: 1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings. 2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself. Solution ----- For the first problem, there are a couple things to keep in mind: - the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer - products can be added and removed from the picking after the SO has been confirmed - actual delivery cost can change between invoice date and actual delivery date - picking can be split into multiple packages at the user's discretion Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders. ----- Ticket: opw-6013387 Forward-Port-Of: odoo/enterprise#111304
This update fixes an issue where partners sharing the same VAT number, but with individual turnovers below €250, were incorrectly excluded from VAT reports. The change groups partners by VAT number and includes them in the report if their combined turnover exceeds the threshold, ensuring accurate reporting for Belgian businesses.
Original PR description
When having different partners with the same vat number and their individual turnover values are less than the threshold they were not included in the partner vat listing report even though if the total turnover for their vat number is above the threshold. This commit handles this case by grouping by vat number and if the total turnover for a vat number is above the threshold then it will be shown in the report with another level beneath it to show the partners having this vat number even if their individual turnovers are below the threshold. task-6133010 Forward-Port-Of: odoo/enterprise#115251
This update corrects errors in the Norwegian VAT XML export that were preventing successful validation by Skatteetaten (the Norwegian tax authority). The changes ensure accurate decimal formatting, mathematical calculations, and required legal notes are included, allowing VAT returns to pass government scrutiny. This resolves a critical issue impacting proper tax reporting.
Original PR description
Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal…
Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal notes, and invalid KID number formats. Fix: To strictly follow Skatteetaten validation rules for the Norway VAT XML, the following changes were implemented: - Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted fractional rates like `11.11` to `11,11` in XML. - Rounded down the `tax_amount` to align precisely with government mathematical expectations. - `base_amount` converted into absolute value to ensuring the calculation (`base * rate = tax`) resolves perfectly. - Add the mandatory `<merknad>` explaining the reverse charge method for codes 81, 83, 86, 88, and 91. - Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix. Expect: The generated XML payload now adheres perfectly to Skatteetaten's strict structural and mathematical rules, allowing the VAT return to pass government validations successfully. Related Community PR: https://github.com/odoo/odoo/pull/258390 Task-6033027 Forward-Port-Of: odoo/enterprise#116553 Forward-Port-Of: odoo/enterprise#110792