Wednesday, September 18, 2024
6 changes · saas-17.4
Resolved issues and error corrections
Point of Sale now shows the base product price when products have variants, instead of accidentally showing a variant-specific price adjustment. This prevents staff and customers from seeing misleading prices in the product list.
Original PR description
In saas-17.4, instead of directly showing a list of `product.product` records in the `ProductScreen` in pos, we show the products "grouped" by `product_template_id`. With this change, one would…
In saas-17.4, instead of directly showing a list of `product.product` records in the `ProductScreen` in pos, we show the products "grouped" by `product_template_id`. With this change, one would expect when seeing a product with variants to be shown the base price of the corresponding `product.template` record. Instead, we simply show one of the variants. The problem is that the variant shown might have a price extra. In that case, instead of showing the base price, we show the price of the variant, which includes the price extra. Ex: 1. Create a product template with price 100 and no variants. 2. In pos you will see the corresponding `product.product` record and the price will be the correct 100. 3. Create 2 variants for the `product.template` ( create_variant: always ), each variant having a price extra of 10, respectively 20. 4. Open pos and observe that the product no longer has price 100, but in fact either 10 or 20. In this commit we make it such that when showing the price of a product, we take into consideration the `list_price`, not the `lst_price` of the specific `product.product` record. Task: 4188122 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures Point of Sale order totals are preserved when orders are processed and merged. It prevents incorrect handling of subtotal information that could affect order line consolidation, and includes a test to reduce the chance of recurrence.
Original PR description
This reverts commit 76f06383d405e129a00bd4fffa3943d68dccec46. When serializing an object from the PoS computed fields are ignored, and this caused issues because `price_subtotal_incl` is needed in `_merge_order_lines`. This also fix the issue of the reverted commit in another and add a test for it. opw-4171641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures cross-dock transfers always move goods from the input area to the output area, regardless of warehouse reception or delivery settings. It prevents incorrect stock routing when warehouses are not configured with multi-step flows.
Original PR description
In #165778, cross-dock was given a specific picking type as other old Internal Transfers. It was set as using the input / output locations as its source / destination. However, at warehouse creation, if it was not set as multi step reception and/or delivery, then respectively the input and/or the output location will the warehouse `lot_stock_id`. This is incorrect for Cross-Dock, as we always want to have Input -> Output. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale now loads only the events linked to products that can actually be sold in that POS. This reduces unnecessary startup work and also removes an outdated restriction that prevented deleting the POS event category when it is no longer needed.
Original PR description
Commit 1: When you are launching a POS, you are loading all events of your companies, even if you don't sale any of the related products of those event. To avoid unnecessary load time, we only take the events we can sell Commit 2: We are preventing the deletion of the pos category events, which is a data. We don't need to do so, as the only place where we are using it we correctly manage the fact that the category exists or not by checking if the record is still there before using it.
This fixes an issue where Chilean point-of-sale invoices could fail during validation because the system looked for the customer in the wrong place. Businesses using Chilean localization can now complete POS invoice payments for properly configured customers without a console error.
Original PR description
Problem was we try to get partner from `order.partner` instead of `order.partner_id` Steps to reproduce: - Install l10n_cl - Select the CL Company - Go to POS - Select products - Change the client to Blanco Martin & Asociados EIRL (has all the information for l10n_cl) - Click on "payment" - Select any payment method - Select the option "Invoice" - Validate - Console error opw-4180894
This update ensures that Point of Sale can load the required connection file when printing reports through IoT devices. It prevents errors during printing, helping stores use connected printers more reliably.
Original PR description
Before this PR, trying to print an IoT linked report from PoS would result in an error, as the JS file for websockets was not loaded. This PR fixes the issue by including the file. Related community PR: https://github.com/odoo/odoo/pull/180063