Tuesday, October 28, 2025
7 changes · saas-18.2
Resolved issues and error corrections
Refreshing a signature document no longer hides the Sign Now and Cancel buttons or replaces the document name with 'unnamed'. This keeps the signing flow clear and stable for users who reload the page.
Original PR description
Version: - 18.0 Steps to reproduce: - Open document which is send for signature. - Refresh the browser. Before: - Refreshing the page was hiding the `sign now` and `cancel` button from control panel…
Version: - 18.0 Steps to reproduce: - Open document which is send for signature. - Refresh the browser. Before: - Refreshing the page was hiding the `sign now` and `cancel` button from control panel and also the name of document get replaced by 'unnamed' in breadcrumbs - The `needToSign` value was loaded from the context and used later to show those button, which is only available when navigating from `go_to_document`. On refresh, the context was lost, leading to the error. - Breadcrumbs were not getting set properly on reload. After: - Added `needToSign` to the URL query string.On page refresh, the data is retrieved from the URL as a fallback instead of relying on the context. - Add name of document to URL query string and on page refresh use that name to get correct name of document and update name to breadcrumbs using `setDisplayName`. Impact: - Buttons remain visible after refresh. - Correct document name is shown in breadcrumbs. - Ensures a smoother and more stable user experience when viewing documents. task-4805166 Forward-Port-Of: odoo/enterprise#93589
RFQs created from approvals now use the currency configured for the product's vendor instead of defaulting to the company currency. This keeps purchasing documents consistent with other RFQ creation flows and helps avoid currency and price mismatches.
Original PR description
Issue: When creating an RFQ from an approval, the created purchase order does not use the currency set on the vendor of the product. Rather, it uses the currency of the company, with the value converted based on the vendor's currency to get the price. This is not consistent with other ways we create RFQs, which all respect the vendor currency. Solution: Pass the vendor's currency into the values sent when creating the purchase order. In the case of modifying an existing purchase order, only modify purchase orders matching vendor's currency. opw-4549937 Forward-Port-Of: odoo/enterprise#97069
This fixes Lithuanian payroll calculations so employees enrolled in pension accumulation are not charged the pension contribution twice. Payslips will now reflect the expected social security contribution, helping avoid payroll over-deductions and correction work.
Original PR description
**Issue**
When generating a payslip for an employee with the `l10n_lt_pension` setting enabled on the contract ("Participate to pension accumulation system"):
- the SSC is raised from 19.5% to 22.5%
- a 3% pension contribution ("Pension Scheme") is added This effectively doubles the expected contribution.
Various sources (e.g. https://taxsummaries.pwc.com/lithuania/individual/other-taxes) seem to show this is not correct.
opw-5067664
Forward-Port-Of: odoo/enterprise#95880This fix prevents UPS label generation from failing when sender or shipper VAT details are not provided. It avoids sending blank tax ID values that UPS rejects in production, helping deliveries continue without unnecessary errors.
Original PR description
Only in production mode, if the sender or the shipper's VAT was not set, the UPS answer would be an error, preventing the label generation altogether. This is because we send an empty string if the VAT was not set, and UPS couldn't process it. Forward-Port-Of: odoo/enterprise#98227
DHL pallet package defaults were corrected from millimeter-style values to the centimeter values DHL expects. This prevents delivery validation failures and allows shipping labels to be generated when users keep the default pallet dimensions.
Original PR description
## Short functional explanation of the error When setting the 'DHLxw Package Type' of a DHL delivery method to 'DHL pallets' without changing default values, trying to validate an order delivery…
## Short functional explanation of the error When setting the 'DHLxw Package Type' of a DHL delivery method to 'DHL pallets' without changing default values, trying to validate an order delivery causes an error. ## Reproduction Steps 1. Type 'Delivery method' in the dashboard. Select DHL BE, set the region to Europe and the 'DHLxw Package Type' to 'DHL pallets'. Click on the arrow at the right of 'DHL pallets'. You should see the default values set to 1200, 1600 and 1200. These correspond to millimeters, while DHL expects centimeters. 2. Make sure you're using a company located in Belgium. 3. In the inventory settings, make sure that either 'multi-step route' is unchecked or that for your warehouse, the outgoing shipments are set to '1 step'. 3. Create a new quotation. Select a Customer with a Belgian address. Add a product for which there's at least 1 copy in stock. 4. Click on add shipping and select DHL BE. Then click add and ok. 5. Click on confirm. A smart button at the top of the page called "delivery" should appear. Click on it and set the scheduled date to a future day. Finally, click validate. ### Expected behavior New labels should generate without issue. ### Unexpected behavior An error occurs: ```Bad request Multiple problems found, see Additional Details 1001: The requested product(s) (N) not available based on your search criteria.(687662d08999745d3df3783068fcca24) 410107: The piece height exceeds max, N/- 410304: No products available ``` ## Origin of the issue The default values for DHL are set to 1200, 1600 and 1200, which correspond to millimeters. However, DHL expects centimeters, for which the default value is thus too high. Note: because the issue stems from default values, after implementing the fix, the module should be reinstalled. __ opw-4804639
Assets created from vendor bills now calculate their original value using only the deductible portion of partially deductible lines. This prevents asset values from being overstated and improves accuracy in depreciation and accounting records.
Original PR description
We allow the user to create an asset from a bill with lines which are not fully deductible but the created asset's original value is the based on the entire balance of the journal item. It should be only the deductible part. task-5156256
This update restores the Swedish POS control that limits receipt reprints to one time, helping businesses stay compliant with local fiscal requirements. It also improves blackbox error handling so disconnected devices and driver issues are reported more reliably instead of causing endless loading or hidden errors.
Original PR description
Before this commit, the receipt reprint check logic (which only allows a receipt to be reprinted once) was not working. There were two issues preventing it from working: - The name of the function had changed but not been updated in this module, so the override was not applied. - The ID being used to check the order was incorrect. A few smaller issues were also fixed: - A logging issue in the IoT driver, which prevented the error severity from being printed. - An infinite loading UI if the blackbox was disconnected. - The blackbox error handler swallowing up some errors due to only expecting one specific format. Forward-Port-Of: odoo/enterprise#98152 Forward-Port-Of: odoo/enterprise#98076