Friday, March 8, 2024
31 changes · saas-17.1
Enhancements to existing features
This update enhances the visual appearance of the payment form within the customer portal. The changes make the form more user-friendly, improving the overall customer experience when making payments. This is a simple visual improvement designed to streamline the payment process.
Original PR description
Improve visual of payment form in customer portal task-3640114 backport of odoo/odoo#150919 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156079
This update adjusts Luxembourg's VAT rates to reflect a 2023 temporary reduction. The previous VAT rates have been deactivated, but remain available for clients to use if needed. This ensures continued compliance with Luxembourg's tax regulations.
Original PR description
In Luxembourg, during the year 2023, the VAT rates were decreased by 1% temporarily. Now that we are in 2024, we need to deactivate the taxes added previously. We will not remove them so that client can still use them if needed. Task: 3635758 X-original-commit: eee565f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156928
Resolved issues and error corrections
Restaurant table size and position changes in Point of Sale are now saved correctly. This prevents staff from losing floor plan layout adjustments and helps keep restaurant operations consistent across sessions.
Original PR description
Prior to this commit, changes made to a table's size and position were not being saved. opw-3753272 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This pull request adds a signature for Gaurav Pandey, confirming he has signed a Contributor License Agreement (CLA). This ensures compliance with Odoo's open-source licensing and allows his contributions to be incorporated into the core Odoo platform. It's a standard legal step for all external contributors.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156919
Miscellaneous changes
Issue --> `saveChanges` at https://github.com/odoo/odoo/blob/6fc1f1c146b1385f9acf53c8fe69c3877cea32d5/addons/point_of_sale/static/src/js/Screens/ClientListScreen/ClientListScreen.js#L155-L165 calls `load_new_partners` that calls `prepare_new_partners_domain` to compute the domain on which the `res.partner` model is to be searched on, after the save has been commited. The search is done to update client-side `res.partner `data. Domain in question --> https://github.com/odoo/odoo/blob/5404
Original PR description
Issue --> `saveChanges` at https://github.com/odoo/odoo/blob/6fc1f1c146b1385f9acf53c8fe69c3877cea32d5/addons/point_of_sale/static/src/js/Screens/ClientListScreen/ClientListScreen.js#L155-L165 calls…
Issue --> `saveChanges` at https://github.com/odoo/odoo/blob/6fc1f1c146b1385f9acf53c8fe69c3877cea32d5/addons/point_of_sale/static/src/js/Screens/ClientListScreen/ClientListScreen.js#L155-L165 calls `load_new_partners` that calls `prepare_new_partners_domain` to compute the domain on which the `res.partner` model is to be searched on, after the save has been commited. The search is done to update client-side `res.partner `data. Domain in question --> https://github.com/odoo/odoo/blob/5404f3367a611e527fcecc2dd49e683864ba4b81/addons/point_of_sale/static/src/js/models.js#L784 This domain has the potential to make `search_read` return every `res.partner` record and compute fields such as `total_due` on each one of them. This presents the issue of overworking postgres when we only need to update one `res.partner` record. Solution --> Use the `_loadPartners` method instead to only reload the current partner being edited + saved. opw-3619941 Forward-Port-Of: odoo/odoo#156841 Forward-Port-Of: odoo/odoo#155141
This update resolves a visual issue where the mandatory day color disappeared when hovering over it in the month view. The change adjusts the styling to ensure the correct color is consistently displayed, improving the user experience and visual clarity of the calendar.
Original PR description
Commit (1) introduced a fix on the mandatory day style. But it also creates another color issue: when we hover a mandatory day in the month view the mandatory color dissapears. This commit adapts the selector to handle this issue. (1): d75343d7d83ad56a7532038f01a2038c7e16f15f task-3758658 Part of task-3575827 | The issue | |--------| |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155201
This update fixes an issue where product names within Point of Sale sessions were consistently displayed in English, regardless of the selected language. The fix ensures that product names are correctly translated based on the user's chosen language setting, improving the user experience for international customers. This was a simple bug fix related to language context.
Original PR description
### Steps to reproduce: - Install **pos** app. - Add a new language (ex. french). - Switch to the new language. - Go to pos app, and open a new session. - Notice how the products' names are still in english. ### Investigation: - the source of the product name (`display_name`) is https://github.com/odoo/odoo/blob/de4627069ea2b45544e0c34ff5653cf5f28a1da1/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.xml#L49 - which is computed by `_compute_display_name()` method in https://github.com/odoo/odoo/blob/de4627069ea2b45544e0c34ff5653cf5f28a1da1/addons/product/models/product_product.py#L465 - However the context of the `product.product` provided only contains `display_default_code` lacking `lang` needed for translating the name. opw-3760448
This update fixes an issue where report placeholders were incorrectly including irrelevant data, leading to report errors. The changes also cleaned up unused placeholders to improve report efficiency and clarity. This ensures purchase order reports are accurate and reliable.
Original PR description
Previous PR: odoo/odoo#135739 added in report placeholders for the sake of easier editing of reports with studio. Unfortunately it didn't check that these placeholders aren't printed with real records which results in junk being included in the report, so we add in conditions to avoid this situation. Also, since the report was already being edited, clean up some of the placeholders because they didn't make sense/ didn't do anything (e.g. the `address` values weren't used + already have a special placeholder in studio => remove them). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156674
This update resolves an issue where users with stock manager permissions in Odoo were encountering errors when deactivating stock picking types within the Point of Sale module. The change adds a necessary security check to ensure that POS configuration access is properly controlled, preventing unauthorized modifications and improving stability. This ensures consistent POS functionality for all users.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154888
This update corrects a calculation error in the Gantt chart's progress bar, ensuring accurate representation of employee attendance and contract-related work. Previously, the progress bar didn't account for contract durations, leading to inaccurate visual displays. This fix improves the clarity and reliability of the Gantt chart for HR managers.
Original PR description
Currently the progressbar computation are not contract-aware, we fix this here task-3777971 Forward-Port-Of: odoo/odoo#156040
This update fixes a problem where taxes weren't correctly identified as changed after a fiscal localization reload, specifically when taxes lacked repartition lines. The fix ensures that changes to taxes with different repartition lines are properly detected, preventing incorrect updates to tax settings.
Original PR description
To reproduce: - Install l10n_it - Go in settings - Fiscal Localization => reload - Go to the taxes => You will find taxes with [old] prefix The issue comes that we want to consider that a tax has changed if it has different repartition lines. We don't consider taxes that are defined without repartition lines. The template will have no lines, but the compute on actual taxes will generate default ones. It then considers that the tax has changed. task-3777629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156028
This update fixes a blurry image issue in the Odoo blog posts, specifically within dynamic snippets. The problem stemmed from how images were initially handled, leading to poor quality. The fix ensures all blog images are properly resized, resulting in clearer and more professional-looking blog posts.
Original PR description
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are…
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are not resized down / impacted - Some of the layout are working fine - For the problematic layouts, the problem gets worst when you select only one or two "Fetched Elements". Steps to reproduce: - Add an image on a blog post (you can just download the one on the PR, see at the end of this message) - Add a "Blog Posts" dynamic snippet on a page - Select "Card Layout" - By default, you'll see that the image is very blurry. If you select 2 (or 1) instead of 3 fetched elements, it will get even worst. Note that it's like that since forever, when it was introduced with https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5 opw-3771992 Image to test:  Forward-Port-Of: odoo/odoo#156381
This update resolves a bug that occurred when closing recurring tasks in Odoo. The issue stemmed from a duplicate creation of follower records, leading to a validation error. The fix ensures that the creation process avoids this duplication by temporarily disabling automatic follower creation during recurring task updates.
Original PR description
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the…
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the original task in the new one, but it happens that we create a `mail_followers` twice which violates an SQL constraint of `mail_followers`. https://github.com/odoo/odoo/blob/ea170be9089ee6c784664475ac4ec1218d23dccd/addons/mail/models/mail_thread.py#L253-L262 the create method will create `mail_followers` for the task and as the condition that follows is truthy in this use-case `_insert_followers` will be called and create `mail_followers` again. - In previous versions we didn't face this issue because the creation of occurences was done by a cron, so the condition was never truthy thanks to `and self.env.user.active`. Solution: ========= to make sure the conditon stays falsy, we set `mail_create_nosubscribe` in context to `True` when creating the next occurence. opw-3742737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156900 Forward-Port-Of: odoo/odoo#154927
This update ensures that tracking numbers displayed in the Point of Sale system now accurately match the information recorded in the backend. Previously, tracking numbers were inconsistent due to changes in the session ID. This fix improves data accuracy and provides a more reliable experience for users managing paid orders.
Original PR description
Before this commit, when loading paid orders, the tracking number would differ from the backend. This discrepancy was due to the fact that the `pos_session_id` was being changed to the current session. opw-3788982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156733
This update allows individual company branches to set their own default tax rates within Point of Sale (POS). Previously, all branches used the same tax settings as the parent company. This change improves flexibility and accuracy for businesses with multiple locations.
Original PR description
Before this commit: When a company having branches, they uses the same taxes as the parent company, In POS settings, the default tax used a company domain which does not allow branch to change the default tax After this commit: A branch is allowed to change the default tax task-3775857 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156434
This update resolves an issue where users without registration permissions would receive an access error when attempting to change the partner on a Sales Order. By using 'sudo,' the system now behaves consistently with other related processes, ensuring a smoother experience for all users. This prevents unexpected errors and maintains data integrity.
Original PR description
If the user doesn't have rights to registrations and tries to change the partner on a SO, this will raise an access error even if there's no registrations linked to the SO. We use sudo to be coherent with what is done in _update_registrations. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151920 Forward-Port-Of: odoo/odoo#151506
This update resolves an issue where POS users wouldn't be able to access the self-order mobile menu if they lacked access to the initial company setup. The fix ensures the correct company access settings are applied, preventing access errors when managing multiple companies within the POS system. This improves the user experience for businesses utilizing the self-order feature.
Original PR description
Before this commit, if the POS user didn't have access to the first company, an access error would be raised when accessing the self-order page. The steps to reproduce this issue are as follows: 1. Add another company and set up POS self-order. 2. Remove the other company from the Marc user. 3. Open the POS in the new company. 4. Try to access the mobile menu. This would result in an access error. The issue was that the first company existed in the `allowed_company_ids` in the context. To solve this, we need to correctly set the `allowed_company_ids` in the context. opw-3744500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156357
This update fixes an issue where landed costs were incorrectly applied to the full MO quantity (1000) instead of the actual produced quantity (900). The change reflects a new definition of a field that now accurately tracks initial demand, ensuring landed costs are calculated correctly for partial production runs.
Original PR description
Steps to reproduce: - Create an MO qty = 1000 - Only produce 900 - Create a landed cost for that MO Bug: landed cost is applied on 1000 units instead of 900 starting V17 definition of the field (product_ty) has been changed to reflect the intial demand apply same fix as in: https://github.com/odoo/odoo/pull/137864/files#diff-d41327f63c4c3d8d369a3f8622f794aa03f79f5f93d9ec01dfa5c179fd8f31eaR159-R162 opw-3696385 Forward-Port-Of: odoo/odoo#156366
This update resolves a technical issue that prevented users from creating orderpoints when archived locations were involved. Previously, the system would throw an error (KeyError). Now, orderpoint creation correctly considers archived locations, ensuring accurate inventory calculations and preventing disruptions to the ordering process.
Original PR description
orderpoint creation should also consider archived location while building the domain or else users will be faced with a `KeyError` Description of the issue/feature this PR addresses: Fixes KeyError when creating orderpoints Current behavior before PR: Users are faced with a KeyError Desired behavior after PR is merged: KeyError is fixed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156965 Forward-Port-Of: odoo/odoo#155397
This pull request updates the corporate legal agreement (CLA) signature documentation for VG&Co. This ensures compliance with our legal agreements and strengthens our legal protections. It's a routine update to maintain accurate legal records.
Original PR description
Corporate CLA Signature Forward-Port-Of: odoo/odoo#155971
Context: upgrade script calling `recompute_fields(cr, "sale.subscription.line", ["price_subtotal"])`. It was noticed that this update step runs a long time and is not limited by the DB, but CPU-limited in python. Profiling the code showed that 94% of the execution time is spent in the `filtered()` call in `map_tax()` of model `account.fiscal.position` during this upgrade. The profile also shows that this whole code path effectively creates deeply nested loops, leading to 3.6 **billion** calls to
Original PR description
Context: upgrade script calling `recompute_fields(cr, "sale.subscription.line", ["price_subtotal"])`. It was noticed that this update step runs a long time and is not limited by the DB, but…
Context: upgrade script calling `recompute_fields(cr, "sale.subscription.line", ["price_subtotal"])`. It was noticed that this update step runs a long time and is not limited by the DB, but CPU-limited in python. Profiling the code showed that 94% of the execution time is spent in the `filtered()` call in `map_tax()` of model `account.fiscal.position` during this upgrade. The profile also shows that this whole code path effectively creates deeply nested loops, leading to 3.6 **billion** calls to the `lambda` passed to `filtered()` with only ~4k rows on model `sale.subscription.line` (upg-1218044). The idea of this improvement is to - by the grace of `read_group()` - build a dict of ids that maps tax_src_id to dest_ids outside of the loop over `taxes` and then build the result only through lookups from that dict, reducing the loop nesting by two levels. Using cProfile again, it shows that the average runtime of `map_tax()` is ~6x faster with the patch (16.7ms vs. 2.8ms). For above cited upgrade, the process is no longer CPU limited and the runtime of this step is reduced from ~8h to ~2.5h, which is significant enough to be relevant for upgrades. Considering this code is unchanged on branches up to `master`, this should also reduce response times in normal operation, when recomputations involving multiple calls to `map_tax()` are triggered by user action. Forward-Port-Of: odoo/odoo#151455
Steps to reproduce: - Install Accounting, Sales, eCommerce, Contacts - Go to Accounting settings and configure TaxCloud - Go to Sales settings and activate Delivery Methods - Go to Contacts and configure complete address (in US) and Fiscal Position to "TaxCloud" for a contact (e.g. Mitchell Admin) - Create/configure a shipping method: (e.g. Free delivery charges) * Provider: Fixed Price * Delivery Product: [Delivery_007] Free delivery charges * Fixed Price: $10 * Free if order a
Original PR description
Steps to reproduce: - Install Accounting, Sales, eCommerce, Contacts - Go to Accounting settings and configure TaxCloud - Go to Sales settings and activate Delivery Methods - Go to Contacts and…
Steps to reproduce: - Install Accounting, Sales, eCommerce, Contacts - Go to Accounting settings and configure TaxCloud - Go to Sales settings and activate Delivery Methods - Go to Contacts and configure complete address (in US) and Fiscal Position to "TaxCloud" for a contact (e.g. Mitchell Admin) - Create/configure a shipping method: (e.g. Free delivery charges) * Provider: Fixed Price * Delivery Product: [Delivery_007] Free delivery charges * Fixed Price: $10 * Free if order amount is above Amount $101 - Configure the corresponding delivery products with a TaxCloud category (e.g. [11099] Postage/Delivery) - Create a product: (e.g. Product X) * Price: $100 * TaxCloud Category: [0] Uncategorized - Go to eCommerce with Mitchell Admin - Add Product X to cart - Process checkout Issue: On the payment page, the price with the taxes is above $101 but the delivery is not free. When accessing the payment page, the TaxCloud taxes are not computed yet and the delivery is defined based on the price without taxes. Solution: Compute the taxes during order confirmation before determining the delivery. opw-3696956 Linked enterprise PR: https://github.com/odoo/enterprise/pull/56499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156905 Forward-Port-Of: odoo/odoo#153861
Versions -------- - 16.0+ Steps ----- 1. Have SOL discounts enabled; 2. create a pricelist with a discount; 3. set Discount Policy to Show public price & discount; 4. create a quotation; 5. using the pricelist, add a product it's applicable to; 6. manually modify the discount; 7. in Other Info, add a Start Date. Issue ----- The manually modified discount was reset. Cause ----- The sale_subscription's override of `_compute_discount` adds `start_date` as a dependant field. W
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have SOL discounts enabled; 2. create a pricelist with a discount; 3. set Discount Policy to Show public price & discount; 4. create a quotation; 5. using the pricelist, add a product it's applicable to; 6. manually modify the discount; 7. in Other Info, add a Start Date. Issue ----- The manually modified discount was reset. Cause ----- The sale_subscription's override of `_compute_discount` adds `start_date` as a dependant field. When no start date is at confirmation, it will be set to the current date, triggering a recomputation of discount fields. Solution -------- Add an `action_confirm` value to the context when confirming a subscription, and check for it in `_compute_discount` to avoid recomputing non-upsell line discounts. opw-3646915 Forward-Port-Of: odoo/enterprise#58022 Forward-Port-Of: odoo/enterprise#57222
When coming back to the time selection screen, from an error or through chevrons, the previously chosen resource (resource_selected_id in the url) was selected for 'Time then resource' in the resource dropdown, and at loading, also when computing available slots. In order to let the user choose their resource in that case, do not use the selected resource for time_resource types, nor for computing availabilities at first loading, nor to restrict the resource dropdown. Task-3603354 Forward
Original PR description
When coming back to the time selection screen, from an error or through chevrons, the previously chosen resource (resource_selected_id in the url) was selected for 'Time then resource' in the resource dropdown, and at loading, also when computing available slots. In order to let the user choose their resource in that case, do not use the selected resource for time_resource types, nor for computing availabilities at first loading, nor to restrict the resource dropdown. Task-3603354 Forward-Port-Of: odoo/enterprise#56586
For resource appointments with Resource Then Time setting, when clicking on a day to select a slot, for instance on update of the slots when changing users, or when simply when selecting a day, the resource_selected_id is not added properly to the url as it should, hence not showing the selection in the details column in the /info screen. This is only due to not using the value of the select for the resource. Fix the issue by using the value of the resource dropdown if any. Task-36
Original PR description
For resource appointments with Resource Then Time setting, when clicking on a day to select a slot, for instance on update of the slots when changing users, or when simply when selecting a day, the resource_selected_id is not added properly to the url as it should, hence not showing the selection in the details column in the /info screen. This is only due to not using the value of the select for the resource. Fix the issue by using the value of the resource dropdown if any. Task-3603354 Forward-Port-Of: odoo/enterprise#56585
Behavior before the changes: - When a note was modified, it cancelled the old orderline and recreated it with the new note. - Products were not sorted by category in the order preparation display. - Clicking on the header of an order sent it directly to the next stage, regardless of whether lines were crossed out or not. - There were brackets around the order number. Behavior after changes: - When a note is modified, it is modified directly on the existing orderline. - Products are now
Original PR description
Behavior before the changes: - When a note was modified, it cancelled the old orderline and recreated it with the new note. - Products were not sorted by category in the order preparation display. - Clicking on the header of an order sent it directly to the next stage, regardless of whether lines were crossed out or not. - There were brackets around the order number. Behavior after changes: - When a note is modified, it is modified directly on the existing orderline. - Products are now sorted by category in the order. - Clicking on an order header sends only the crossed-out lines to the next stage. If no line is crossed out, the entire order is sent. - There are no longer any brackets around the order name. taskId: 3764317 community PR: https://github.com/odoo/odoo/pull/155246 Forward-Port-Of: odoo/enterprise#57385
The button "insert in spreadsheet" added in the pivot view would display a tooltip of "0" when the button was active. The tooltip was only meant to be present when the button was disabled due to the presence of duplicated group bys in the pivot. This revision fixes the tooltip presence on the button and also removes a test that: - had a description that did not match the actual test - was in fact testing the same behaviour as another test -> useless redundancy Task: 3790072 Forward-Port
Original PR description
The button "insert in spreadsheet" added in the pivot view would display a tooltip of "0" when the button was active. The tooltip was only meant to be present when the button was disabled due to the presence of duplicated group bys in the pivot. This revision fixes the tooltip presence on the button and also removes a test that: - had a description that did not match the actual test - was in fact testing the same behaviour as another test -> useless redundancy Task: 3790072 Forward-Port-Of: odoo/enterprise#58297 Forward-Port-Of: odoo/enterprise#58160
Forward-Port-Of: odoo/enterprise#58085
Original PR description
Forward-Port-Of: odoo/enterprise#58085
Currently the progressbar computation are not contract-aware, we fix this here task-3777971 Forward-Port-Of: odoo/enterprise#57902
Original PR description
Currently the progressbar computation are not contract-aware, we fix this here task-3777971 Forward-Port-Of: odoo/enterprise#57902
Before this commit, the variable name was wrong in the pos_order.py file in the pos_preparation_display module. We use product_id.pos_categ_id Now its fixed by using the correct name product_id.pos_categ_ids Forward-Port-Of: odoo/enterprise#58187
Original PR description
Before this commit, the variable name was wrong in the pos_order.py file in the pos_preparation_display module. We use product_id.pos_categ_id Now its fixed by using the correct name product_id.pos_categ_ids Forward-Port-Of: odoo/enterprise#58187
Steps to reproduce: - Install Accounting, Sales, eCommerce, Contacts and AvaTax - Go to Accounting settings and configure AvaTax - Go to Sales settings and activate Delivery Methods - Go to Contacts and configure complete address (in US) and Fiscal Position to "AvaTax" for a contact (e.g. Mitchell Admin) - Create/configure a shipping method: (e.g. Free delivery charges) * Provider: Fixed Price * Delivery Product: [Delivery_007] Free delivery charges * Fixed Price: $10 * Free if
Original PR description
Steps to reproduce: - Install Accounting, Sales, eCommerce, Contacts and AvaTax - Go to Accounting settings and configure AvaTax - Go to Sales settings and activate Delivery Methods - Go to Contacts…
Steps to reproduce: - Install Accounting, Sales, eCommerce, Contacts and AvaTax - Go to Accounting settings and configure AvaTax - Go to Sales settings and activate Delivery Methods - Go to Contacts and configure complete address (in US) and Fiscal Position to "AvaTax" for a contact (e.g. Mitchell Admin) - Create/configure a shipping method: (e.g. Free delivery charges) * Provider: Fixed Price * Delivery Product: [Delivery_007] Free delivery charges * Fixed Price: $10 * Free if order amount is above Amount $101 - Configure the corresponding delivery products with an AvaTax category (e.g. [FR20100] Shipping only common carrier - fob destination) - Create a product: (e.g. Product X) * Price: $100 * AvaTax Category: [D0000000] Digital goods - Go to eCommerce with Mitchell Admin - Add Product X to cart - Process checkout Issue: On the payment page, the price with the taxes is above $101 but the delivery is not free. If you go back one step and then return to the payment page, the delivery is free as expected. When accessing the payment page for the first time, the AvaTax taxes are not computed yet and the delivery is defined based on the price without taxes. Solution: Compute the AvaTax taxes during order confirmation before determining the delivery. opw-3696956 Linked community PR: https://github.com/odoo/odoo/pull/153861 Forward-Port-Of: odoo/enterprise#58268 Forward-Port-Of: odoo/enterprise#56499