Friday, September 12, 2025
23 changes · saas-18.3
Enhancements to existing features
Italian fiscal position mapping now includes separate service taxes, preventing a single base tax from being converted into multiple EU zero-rate taxes. This makes tax application more accurate for businesses handling domestic and intra-EU goods or services.
Original PR description
Due to service taxes missing from the domestic fiscal position, when using the base tax on a product and the intracom fiscal position, it is mapped to both the 0% EU G and 0% EU S taxes. This happens with multiple taxes. By adding service taxes and splitting the mapping from default to goods and from services to services, the fiscal position only ever applies one tax per origin. task-none
Resolved issues and error corrections
Sales orders created from the Contacts app now use the customer's preferred delivery address instead of defaulting to the first listed address. This makes address selection consistent with the Sales app and helps avoid deliveries or invoices being prepared with the wrong contact details.
Original PR description
## Versions 17.0+ ## Issue When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery…
## Versions
17.0+
## Issue
When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery address. This fix ensures consistent behavior across both.
## Steps to reproduce
*Ensure Contacts app is installed*
*Activate "Customer Addresses" in the settings*
- Go to the Contacts app:
- Create a new contact:
- Name: C1;
- Contacts & Addresses:
- Delivery Address (Add 2 new addresses):
- D1;
- D2.
- Click the "Sales" action button:
- Create a new SO for C1 (pre-filled):
- Invoice Address: C1, D2;
- Delivery Address: C1, D2;
- Add any product with:
- Quantity: 1;
- Delivered: 1.
- Create the invoice and confirm it.
- Go back to Contacts and look for C1:
- Click the the "Sales" action button:
- Create a new SO and see the Delivery Address set to "C1, D1".
- Go to Sales app:
- Create a new SO and select C1 as customer;
- Delivery Address retrieves "C1, D2" as it is the preferred address.
## Cause
Each time an invoice is validated, the corresponding address gets a higher score.
This score is then used in the SQL ordering of customers/suppliers:
https://github.com/odoo/odoo/blob/b523f5c6d8e235a6cedb029f701a0ebd89a5f74a/addons/account/models/partner.py#L347-L354
## Fix
Apply context search mode if first call. This mimics the base behavior: https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/odoo/addons/base/views/res_partner_views.xml#L534
opw-4916381
Forward-Port-Of: odoo/odoo#225189Printing an invoice now respects the custom PDF report configured for the customer or journal, matching the behavior already used when sending invoices. This prevents businesses from accidentally printing generic invoice layouts when a specific branded or localized template should be used.
Original PR description
Before: Clicking 'Print' on an invoice did not respect the custom PDF report template set on the partner profile or journal. The selection was only applied in the 'Send' flow, while 'Print' always fell back to the generic invoice report. After: 'Print' now uses `_get_default_pdf_report_id()` to determine the correct PDF report. This ensures the same priority order is applied as in 'Send'. Explanation: The method `_get_default_pdf_report_id()` encapsulates the logic for choosing the report template (user → invoice default in 18.0, extended with journal in later versions). By reusing this method, we avoid duplicating logic and ensure consistency between 'Send' and 'Print'. task-5072522 Forward-Port-Of: odoo/odoo#226082
Checkout now validates the order before sending a payment request when customers use a saved payment method. This prevents payment attempts from being sent if a cart change, such as an expired coupon, makes the order invalid before completion.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a saved Stripe payment token; 2. create a discount coupon program & a coupon; 3. go to /shop & add a product to your cart; 4. go to checkout; 5. apply coupon; 6. before finalizing payment, set coupon program expiration to yesterday; 7. finalize payment. Issue ----- An error appears, because of the reward change, but a payment request has already been sent. Cause ----- For token transactions, `_send_payment_request` is called immediately upon creation, i.e. before the `WebsiteSale` controller is able to validate the transaction using `_validate_transaction_for_order`. Solution -------- If the payment flow happens via token, add a `delay_payment_request` context value. When creating a token transaction in `PaymentPortal`, only call `_send_payment_request` if this value is not set in the current context. opw-5013284 Forward-Port-Of: odoo/odoo#226067 Forward-Port-Of: odoo/odoo#225008
This change lets users with invoicing permissions update partner perception and withholding settings in Argentine localization. It helps billing teams prepare invoices correctly without needing full accounting administrator access.
Original PR description
Description of the issue/feature this PR addresses: This pull request adds `l10n_ar.partner.tax_billing` on the `l10n_ar_partner_tax` model, granting read, write, and create permissions (but not…
Description of the issue/feature this PR addresses: This pull request adds `l10n_ar.partner.tax_billing` on the `l10n_ar_partner_tax` model, granting read, write, and create permissions (but not unlink) to users in the `account.group_account_invoice` group. Current behavior before PR: Only users with administrator access rights on the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners. <img width="1236" height="673" alt="image" src="https://github.com/user-attachments/assets/92b42973-2b01-4019-8e23-5e3cbf5111a4" /> Desired behavior after PR is merged: Users with invoicing rights can modify the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners. This is needed to properly create the invoices with the perceptions / withholding that apply, for example in cases where by default all partners are set with perceptions, but some depending on their activity are not taxed. In that case, the user that created the partner needs to be able to modify the field by putting a 0% aliquot or deleting the perception line on the contact. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225180
The survey live session leaderboard now shows score changes in a clearer sequence, making it easier for participants and presenters to understand how points are added. The leaderboard display size was also adjusted so scores fit properly and are easier to read.
Original PR description
The way the score bars were animated was a bit confusing. We simplify the animation by: - Showing the score accumulated so far without the question - Animating the score bar towards the accumulated…
The way the score bars were animated was a bit confusing. We simplify the
animation by:
- Showing the score accumulated so far without the question
- Animating the score bar towards the accumulated score with the question
- Animating the numerical score on the left towards the accumulated score with the question while fading the numerical score increment on the bar ("+ x p")
- (reordering participants)
We also fix the size of the leaderboard as it was too small to display the score correctly.
How to reproduce
- Create a scored survey with time reward
- Add a question to get the name and toggle the nickname option
- Add a question with an answer that grants n points
- Start a live session
- After a user has completed the question
- Display the leaderboard
The score animation is confusion as it was going through:
- Showing the score accumulated so far without the question
- Animating towards 0: showing a minimal bar due to the minimum size of the score bar
- Animating towards the score question (on top of the minimal bar)
- And finally adding the score accumulated so far without the question
Task-4893763This fix prevents point-of-sale payments through Adyen from getting stuck when a cancellation receives no response. It also improves error reporting when the Adyen payment service is unavailable, helping staff recover faster at checkout.
Original PR description
When we try to cancel a processing payment, we can get stuck with a in the state waiting card, if there is no anwser from adyen. Also when we call Adyen to process payment, the value returned by data.silentCall is false, so we don't get error when the service is not available --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a rounding mismatch that could cause Mexican electronic payment documents for foreign-currency invoices to be rejected. Payments made in MXN against USD invoices now calculate values consistently with the required reported precision, reducing failed validations.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to: - 0.049216958195 for day 1 - 0.053418803419 for day 2 - Create an invoice in USD as follows: - line 1: price_unit 91, quantity 64,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
- 0.049216958195 for day 1
- 0.053418803419 for day 2
- Create an invoice in USD as follows:
- line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI
Issue: Payment validation will fail with error
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862
This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.
opw-4750981
Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768This fixes an issue where adding a prepaid service line to an already confirmed sales order showed a zero cost instead of the product’s configured cost. The correction helps keep margin reporting accurate when sales orders are updated after confirmation.
Original PR description
…O confirmation **Problem:** When a service is added on a SO after the confirmation the cost column (purchase_price) is 0 **Steps to reproduce:** - make sure that sale_timesheet_margin is installed - create a service with a positive cost - create a SO for 1 unit of this service - confirm - add a new line on the SO for the same service **Current behavior:** the cost is 0 **Expected behavior:** the cost should be the cost you set on the product form **Cause of the issue:** since this PR https://github.com/odoo/odoo/pull/207228 services that are "ordered_prepaid" on confirmed sale order are filtered out the purchase price computation https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/sale_timesheet_margin/models/sale_order_line.py#L9-L15 opw-5016622 Forward-Port-Of: odoo/odoo#225704 Forward-Port-Of: odoo/odoo#225027
This update prevents errors when users choose a measure while configuring a cohort view in Studio. It limits the measure choices to compatible fields and removes an unnecessary request parameter that was causing system warnings.
Original PR description
Currently, an error occurs when user tries to select any measure in cohort view. Steps to replicate: - Install `sale_management` and `web_studio`. - Open the Sales app and turn on studio mode. -…
Currently, an error occurs when user tries to select any measure in cohort view. Steps to replicate: - Install `sale_management` and `web_studio`. - Open the Sales app and turn on studio mode. - Under the Views tab, turn on cohort view. - Under the Measures field, select any value and observe the error appearing in the terminal. Error: `ValueError: Invalid aggregate method 'None' for 'create_date:None'` Cause: - The Measure field dropdown in the Cohort Editor was mistakenly assigned the choices of `dateFields` [1] instead of `measureFields`. - This allowed users to select incompatible field types (e.g., date/datetime), which lead to error in aggregation behavior in the cohort view. Solution: - Corrected the choices of Measure field to `measureFields`. - Also added a condition to allow only those fields that have an aggregator (for some fields like `sequence` that dont have an aggregator). - Also removed context field from arguments [2] in the rpc call as function doesnt need it [3] (This shows warning on runbot as well). [1]: https://github.com/odoo/enterprise/blob/d8539dff5f3dcecfeb99fd7fc22a6915aaa02c4b/web_studio/static/src/client_action/view_editor/editors/cohort/cohort_editor_sidebar.xml#L30 [2]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/static/src/client_action/editor/new_view_dialogs/new_view_dialog.js#L87 [3]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/controllers/main.py#L805 sentry-6781792463 Forward-Port-Of: odoo/enterprise#94354 Forward-Port-Of: odoo/enterprise#91599
Express checkout will no longer offer Click & Collect delivery options when multiple pickup stores are available, because shoppers cannot choose a store in that flow. This prevents unclear pickup expectations while still allowing the option when there is only one possible store.
Original PR description
Before this commit, when entering the express checkout flow, Click & Collect (C&C) delivery methods (DM) were included in the list of possible delivery methods available for express checkout. However, the express checkout flow does not allow customers to select which store they want to pick up their order from. After this commit, C&C DMs are excluded from the list if they have more than one store configured. If only one store is configured, the customer implicitly knows where they will need to pick up their order. Forward-Port-Of: odoo/odoo#226329
Mollie payments that remain open, such as SEPA bank transfers, are now treated as pending instead of invalid. This prevents customers from seeing an error after checkout when the payment is still awaiting completion.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Mollie as a payment provider; 2. set up an eCommerce order in EUR; 3. go to checkout; 4. pay via Mollie; 5. pick SEPA bank transfer as payment method; 6. leave the transaction open. Issue ----- When returning from the redirect, we get the following error message: > Mollie: Received data with invalid payment status: open Cause ----- An 'open' payment indicates the payment has been created, but nothing else has happened yet[^1]. This is the expected status for bank transfers, but is currently not getting handled in `_process_notification_data`, leading to the error. [^1]: https://docs.mollie.com/docs/status-change Solution -------- Handle 'open' payments the same as 'pending' ones. opw-4894556 Forward-Port-Of: odoo/odoo#226642 Forward-Port-Of: odoo/odoo#225875
Orders paid entirely with a gift card now run the same stock availability checks as other payment methods. This prevents customers from completing checkout when an item in their cart became unavailable, reducing fulfillment issues and manual corrections.
Original PR description
In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The…
In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The other payment methods fail successfully but if gift card is used, the order can be validated. To reproduce: 1- Create a product and add quantity on stock. 2- Uncheck `Conitnue Selling` in `Out-of-Stock` 3- Publish the product on the website 4- Create a gift card 5- Add the product to the cart using portal user 7- Using admin user, set the quantity to less than ordered quantity 8- Using portal user, proceed to payment, and use the gift card. Then checkout. 9- As you see, the order is validated The issue is because `_check_cart_is_ready_to_be_paid()` which is supposed to check the stock, is only called inside `shop_payment_transaction()`. However, when checking out with gift card, this method is not called. To solve the issue, we can call `_check_cart_is_ready_to_be_paid()` also inside payment validate flow. However this only be called when a gift card is used solely. (The case `order.amount_total` is 0) opw-4941658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226394 Forward-Port-Of: odoo/odoo#222306
Neutralized databases now prevent existing Peppol connections from contacting live or test networks by switching them to a fully mocked demo mode. New Peppol connections on these databases are directed to the test network, reducing failed registrations and accidental production use.
Original PR description
Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect: - someone connected in production does not necessarily have a registration on the test network,…
Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect: - someone connected in production does not necessarily have a registration on the test network, therefore the database is in an inconsistent state, and calls to the test network are very likely to fail - if you create a new connection to Peppol on a neutralized database, since the system parameter was not changed, the new connection was on production After this commit: - existing connections are switched in `demo` where everything is mocked locally, no call to the network (whether it's `test` or `prod` can happen) - the system parameter is switched to `test`, therefore new connections will register to the Peppol test network - Also added some fields on the Edi Proxy User to display the mode of the user, as well as the proxy_type in list view. (Those records are only accessible in debug already.) <img width="579" height="333" alt="image" src="https://github.com/user-attachments/assets/87847726-d954-4f68-8336-07771747365f" /> task-none (report from PMAX + WTA) Forward-Port-Of: odoo/odoo#226435
Fixes a missing button that prevented employees from submitting new time off requests in certain Swiss payroll setups. Users can now submit the request from the dialog, while the usual validation checks still happen afterward.
Original PR description
**Steps to reproduce** 1. Install l10n_ch_hr_payroll_elm_transmission 2. Go to an employee's profile 3. Click on "Absences" smart button 4. Create a new Time Off request Issue: the form view dialog is missing a button to confirm the request. Cause: the dashboard warning message is not part of the l10n_ch_hr_payroll_elm_transmission view. Solution: display the "Submit Request" button if we don't have any dashboard warning message. There will still be a validation after the request is submitted. opw-4972467
Fixes an issue where coupons meant for a customer's next order could be claimed on the order that generated them. This keeps loyalty promotions applied as intended and avoids unintended discounts on current sales.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a next-order coupon program; 2. create an order that would generate a coupon; 3. confirm order; 4. click on the "Reward" button. Issue ----- It's possible to claim the reward on the current order. Cause ----- When retrieving claimable rewards, it checks the coupons generated by the current order using `coupon_point_ids`, but does not verify whether the program should be applicable to the current order. Solution -------- If the program only applies on future orders, and the coupon's `order_id` is the current order, skip the coupon when retrieving claimable rewards. opw-4910922 opw-4948757 Forward-Port-Of: odoo/odoo#221536
Changing an expense product's billing policy no longer unintentionally updates the analytic accounts on existing expenses. This protects previously entered expense allocations from being replaced by a newer distribution rule.
Original PR description
When changing the expense policy of an expense product, the compute of analytic distribution of all expenses linked to the product is triggered. Steps: - Have an expense product X with expense policy…
When changing the expense policy of an expense product, the compute of analytic distribution of all expenses linked to the product is triggered. Steps: - Have an expense product X with expense policy 'at_sales' - Create several expenses with an expense product X and any analytic account - Create an analytic distribution model that link the expense account of X with a specific analytic account AA - Create a new expense for product X, the analytic account AA should be set from the distribution model - Go to the form view of product x and change the expense policy to 'cost' - Go back to the expense list view -> All expenses having the product X have the AA account Cause: `sale_order_id` has been added to the `depends` of `hr_expense._compute_analytic_distribution` by 2b3bf5e0fe31d4b4ef6b487da493657f695b14e1 but this wrong since we have the `sale_expense._onchange_sale_order_id` that add the `analytic_dostribution` field to the fields to be computed. The compute is triggered since we change `product_id.expense_policy`, which triggers the `_compute_can_be_reinvoiced` which triggers the `_compute_sale_order_id` Fix: With this commit, we emove the depends on the compute and we also adapt `test_compute_analytic_distribution_expense` in a way that it triggers the onchange as we do in the original flow. opw-4998899 Forward-Port-Of: odoo/odoo#226741 Forward-Port-Of: odoo/odoo#224226
Service products in Indian POS GSTR reports are now reported with a quantity of zero, matching GST portal requirements. This prevents validation errors during filing while keeping normal quantity reporting for goods unchanged.
Original PR description
Before this PR: - Service products in POS GSTR lines were reported with their actual quantity. - This caused GST portal validation error: `RET191355: The Quantity entered is not valid`. After this PR: - For service-type products, `qty` is always set to `0`. - For goods, `qty` continues to reflect the actual ordered quantity. OPW: 5070636 Forward-Port-Of: odoo/enterprise#94522 Forward-Port-Of: odoo/enterprise#94272
UPS shipping rate checks now handle orders that include combo products correctly. This prevents valid orders from being blocked when customers request delivery pricing, improving checkout reliability for businesses using UPS delivery.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit 59a79a5bc51 fixed a bug in 8 shipping connectors, preventing the retrieval of the shipping rate if combo products were present, but failed to fix it in `delivery_ups_rest`. Solution -------- Use `_get_invalid_delivery_weight_lines` helper method to check if there are any lines where a weight is expected, but is lacking. opw-4940973 Forward-Port-Of: odoo/enterprise#93737
Fixes an issue where security lead time could be counted more than once when one warehouse resupplies another, causing manufacturing and delivery dates to be pushed too far out. It also ensures manufacturing lead time is still applied when a product is manufactured without a bill of materials, improving date reliability for sales and replenishment planning.
Original PR description
In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations. To reproduce the bug: 1- Create a db with, stock, mrp,…
In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations. To reproduce the bug: 1- Create a db with, stock, mrp, sale installed. 2- Unarchive `MTO` route. 3- Set `Security Lead` Time in Setting. 4- Create two warehouses wh1, wh2. 5- In wh1, set `Manufacture to Resupply` to True. 6- In wh2, set `Manufacture to Resupply` to False and make it resupply from wh1. 7- Create a product and track inventory. 8- Create a BOM for the product. 9- Enable `Manufacture`, `MTO`, `wh2: Supply Product from wh1` routes for the product. 10- Create a new Quote for the product and in the Delivery, select `wh2` as the warehouse. Confirm the Quote. 11- Open MO. Security lead time is considered twice in dates calculations which is mistake. To solve this issue, we must call `_get_dates_info` only once. The current condition might be True more than once for multiple moves. We should also check that it is not True for next moves which otherwise means the security lead time is already effected. This issue is reproduced because this condition is not sufficient to ensure it is called once: https://github.com/odoo/odoo/blob/c0a7b51c9e14d29cefa96c29dd716b7aec698818/addons/stock/models/stock_move.py#L1656-L1657 The above condition is written to ensure we are adding the delay only when move location is warehouse stock location. This cause problem in multi-warehouse because we have this case that move location is warehouse stock location once for wh1 and once in wh2. To solve this issue, we make sure the call `_get_dates_info` doesn't affect when the move has rules with src location in warehouse stock location. related: #112325 opw-4889642 Forward-Port-Of: odoo/odoo#226712 Forward-Port-Of: odoo/odoo#224232
Restaurant point of sale sessions without preparation printers or displays no longer treat every product category as needing preparation. This prevents staff from seeing an unnecessary “send to preparation” prompt when paying for normal orders, making checkout smoother.
Original PR description
Steps to reproduce: - Open a pos restaurant config that has no prep printer/display. - Add an orderline. - The order button appear and if you try to pay the popup ask for send to preparation is shown. Issue: If there is no preparationCategories for a config getOrderChanges consider that all the available categories are the preparationCategories. Fix: If there is no preparationCategories, set the orderline uiState hasChange to false. Note: When no preparation printer category is defined, no categories is to be return by default. For the preparation display, if no preparation categories is selected preparationCategories will return all the available categories. Task-5016231 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
The Spanish balance sheet report now avoids counting certain payable accounts twice. This ensures the “Other Current Payables” line shows accurate totals, helping businesses rely on correct financial statements.
Original PR description
**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from *Accounting → Reporting → Balance Sheet*. **Observed behavior:** - In the Balance Sheet, under *3. Other Current Payables*, the amount shown is double the journal entry. - Drilling down shows the correct amount in the journal entry, but the Balance Sheet line is overstated. **Root cause:** * In the expression for *3. Other Current Payables*, accounts **551** and **5525** were included twice: * once in credits and again in the balance, leading to double counting. **Reference:** * BOE: https://www.boe.es/eli/es/rd/2007/11/16/1514/con#cuenta * PR with related changes: [odoo/enterprise#82447](https://github.com/odoo/enterprise/pull/82447) **Solution:** - Removed accounts 551 and 5525 from the balance calculation to prevent duplication. opw-5056965
This fixes an issue where POS orders could get stuck if the browser was refreshed before cancelling a Worldline terminal payment. The POS now continues to receive the cancellation confirmation, and Worldline terminal error messages are clearer for users and support teams.
Original PR description
This PR fixes a bug where the point of sale didn't receive notifications from the Worldline payment terminal for the cancellations if the browser webpage was refreshed How to reproduce: 1. Open a POS session with Worldline terminal 2. Send a transaction to the terminal 3. Refresh the browser webpage before paying 4. Click on "Cancel" on the POS screen --> your order will be stuck and never receive the confirmation This PR removes the check for the iot longpolling action identifier which changes on refresh of the webpage + adds more error messages for Worldline terminals Related PR in v17 -> saas-18.2: https://github.com/odoo/enterprise/pull/94635 task-5075860