Wednesday, December 31, 2025
4 changes · saas-18.4
Resolved issues and error corrections
This update automatically marks UrbanPiper orders as paid in Odoo when they are marked as 'dispatched'. This prevents order cancellations due to cashier oversight and ensures accurate order status tracking, improving the POS process.
Original PR description
*= urban_piper, black_box_be In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. - Also, we are adding this urban piper order to the blackbox, if it was not recorded in it. Task: 5261892 X-original-commit: 808cf7b3f8c185053dac5cbf75307efa67fd6e90 Forward-Port Of:odoo/enterprise#99513
This update fixes an issue where users could inadvertently change product taxes while items were already in their shopping cart. Now, users can still modify product details but tax updates are restricted when a product is in the cart, ensuring order accuracy and consistency.
Original PR description
- When a product is already in the cart, prevent updating its taxes from the frontend product edit popup. This avoids inconsistencies between the product taxes and the taxes applied to the order line. - Now we can still edit other fields of the product. task-id: 4943650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures invoices exported with distance selling correctly use the foreign VAT number defined for the customer's fiscal position. Previously, the company's VAT was incorrectly used, leading to inaccurate VAT reporting. This fix improves invoice accuracy and compliance with EU regulations.
Original PR description
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1.…
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1. Install a European localization (ex: l10n_at) 2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT. 3. Create a valid foreign customer. (within the EU) 4. Create and send an invoice for this customer. 5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position. This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML. This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it. opw-5182837 Forward-Port-Of: odoo/odoo#237666 Forward-Port-Of: odoo/odoo#236692
This update resolves an issue where Odoo invoices with discounts generated for Nemhandel failed validation. The fix ensures that discounts are correctly accounted for in the invoice data, allowing these invoices to be successfully transmitted to customers. This improves the reliability of our Nemhandel integration.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241614