Wednesday, October 23, 2024
5 changes · saas-17.4
Resolved issues and error corrections
The checkout address form now shows the VAT field when a localization requires business customer details, such as Ecuador. This prevents an error when customers create a new address during checkout and helps ensure required tax information can be entered correctly.
Original PR description
Steps to reproduce: [l10n_ec] - put an item on the cart - create a new adress Issue: JS error thrown Cause: We don't find the associate field to be set as required https://github.com/odoo/odoo/blob/2361d4606cee0dfea115caf2af8948390a8a71e9/addons/website_sale/static/src/js/address.js#L126-L138 Since we are not editing an existing adress, we are not a sudo_partner and we don't show the vat https://github.com/odoo/odoo/blob/cbe1fbaaa7c82d2c31961d81a223cfa386c89020/addons/website_sale/views/templates.xml#L1988 Therefore the Xpath won't find the vat and we are not setting the necessary fields https://github.com/odoo/odoo/blob/453cfab758505ae15135703fb7be8bdb54981444/addons/l10n_ec_website_sale/views/portal_templates.xml#L27-L33 https://github.com/odoo/odoo/blob/3a73bf6cac9cfed4be7805356378cd064cb8351f/addons/l10n_ec_website_sale/controllers/portal.py#L12-L17 Solution: We show the vat when a localization should always display b2b fields opw-4139919
Point of Sale product listings now show the same converted prices that appear in the cart. This prevents pricing confusion for businesses running POS sessions in a different currency.
Original PR description
Problem: In the product listing, the wrong price attribute `list_price` was used instead of `lst_price`. This causes discrepancies in price display in `saas-17.4`, where the list shows non-converted prices, while the correct converted price is shown in the cart. Solution: Update the product listing to use the correct `lst_price` attribute, ensuring that the displayed prices are correctly converted. Steps to Reproduce: - Create a PoS session with a different currency. - When opening the PoS interface, the product list displays the non-converted price. However, when adding the product to the cart, it shows the converted price. opw-4212288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix reverses a prior change that made required dropdown fields look like the first option was selected even though no value was actually saved. It helps avoid confusion and potential data entry mistakes by making empty required fields behave consistently again.
Original PR description
This reverts commit 21b0872db2ca0483955dd11ff75c5d37606560b1. This commit introduced an unexpected behaviour where the field seems to select by default the first choice but has no value.
Splitting a restaurant bill no longer sends the already prepared order back to the kitchen display. This helps avoid duplicate meal preparation, reducing waste and confusion between waitstaff and kitchen teams.
Original PR description
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to the kitchen as it represents a meal that has already been prepared and consumed. This commit resolves this issue by preventing display of duplicate orders to the kitchen during order splitting. opw-4247067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Production Analysis report now calculates expected component cost per unit using the bill of materials quantity instead of the produced order quantity. This gives managers more accurate manufacturing cost insights when reviewing pivot reports.
Original PR description
Steps to reproduce the issue: 1. Install the MRP module 2. Go to Production Analysis 3. Click on the pivot table 4. Select the `Expected component cost / unit` field 5. The miscalculation will be show for `expected_component_cost_unit`. It is dividing by the MO quantity produced rather than the BOM quantity. Explanation: The issue lies in the SQL query, where the expected cost is divided by `prod_qty.product_quantity`, meaning we are using the quantity produced by a MO. instead, it should be divided by the BOM quantity. Fix reasoning: With this commit, the issue is resolved by dividing the expected cost by the BOM `product_qty`.