This error occurs because the bank's QRIS API Key and Merchant ID were set up incorrectly.

Steps to reproduce:
---
- Install ``POS`` and ``l10n_id`` module
- Change company to ``ID Company``
- Create a new ``Warehouse`` in Inventory
- Now create a new journal(eg: Test) in invoicing with ``Type`` as ``Bank`` > go to the internal link of ``Account Number`` write any ``QRIS API Key`` and ``QRIS Merchant ID`` and Save
- Now go to ``Payment Methods`` and create a new one in POS(eg: Demo) with ``Integration`` as ``qr_code`` and ``QR Code Format`` as ``QRIS`` > Select ``Journal`` as ``Test`` and Save
- Go to ``Clothes`` > Open Session > Add product > Payment > select payment method as ``Demo`` > Click ``retry``

Traceback: 
---
``AttributeError: 'str' object has no attribute 'get'``

At [1], we are facing an error because ``data`` contains the failed message in it, and the status of the response is ``failed``.

[1]- https://github.com/odoo/odoo/blob/dd71d998796cf426527972a3feac6fdd040f3fe3/addons/l10n_id/models/res_bank.py#L101

sentry-6029900658

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When using the restaurant, orders that were sent to the kitchen did not show the change amount on the receipt.

Steps to reproduce:
-------------------
* Open restaurant
* Select any table, add items to the order
* Select **Order**
* Select **Payment**
* Select any payment method
* Pay more than the order
* Validate
> Observation: The receipt show a change of 0.0

Why the fix:
------------
Before this commit: https://github.com/odoo/odoo/commit/1649ee1a757ab1a095fd92f7605ac2b004568352 the change could get computed on an onchange:
https://github.com/odoo/odoo/blob/662f63b630cae8604179174cdd67536f3300bb53/addons/point_of_sale/models/pos_order.py#L417-L427

By definiton, onchanges will only trigger from web form views. In our case, the onchange was never triggered when synchronizing orders from the UI, even though we would make a change to the payment_ids when adding the change line. After the above mentioned commit, the code inside the onchange was put into a separate function `_compute_prices()` which is still called in the onchange but also in the `write` function.

When an order was previously synced from the UI, we call the write function. https://github.com/odoo/odoo/blob/430656132044f8d675712d5b6cbfef807880d024/addons/point_of_sale/models/pos_order.py#L124

By going into `_compute_prices` in the write method, we compute the `amount_return` before the change line was added to the order.
https://github.com/odoo/odoo/blob/430656132044f8d675712d5b6cbfef807880d024/addons/point_of_sale/models/pos_order.py#L128

Computing `amount_return` before adding the change line is problematic since it is computed with regards to the negative payment lines. https://github.com/odoo/odoo/blob/430656132044f8d675712d5b6cbfef807880d024/addons/point_of_sale/models/pos_order.py#L440

To solve our solution, we call `_compute_prices` after we add the change line. `amount_return` represents the change given to a client. If we give `10$` back to a client, the change payment line will have an amount of `-10$` but `amount_return` should be positive 10. (Thus the change of `-`)

We also add a small fix for `amount_difference` which can have precision error and thus show something like `-0.0`.

opw-4253292

Issue: A traceback occurs when attempting to create an invoice or sales order for a customer whose fiscal position is set to Automatic Tax Mapping in Brazilian accounting.

```python
File "/home/odoo/src/enterprise/account_external_tax/models/account_move.py", line 18, in _compute_tax_totals subtotal = tax_totals['subtotals'][0]
~~~~~~~~~~~~~~~~~~~~~~~^^^
IndexError: list index out of range
```

Steps to reproduce:
- Have Brazilian localization (including EDI modules) with Avatax configuration.
- Create a new Sales Order or Invoice and:
  - Use a contact with a fiscal position set to "Automatic Tax Mapping (Avalara Brazil)", or
  - Set the fiscal position to that on the SO or invoice itself.
- Observe the traceback as described in the ticket.

Explanation: In account_move/sale_order from the modules account_external_tax/sale_external_tax, the method _compute_tax_totals attempted to compute the tax totals when there were no account move lines (tax_totals['subtotals'] is empty), which results in an "out of range" traceback. The Brazilian Automatic Tax Mapping is computed externally, which is why it triggered this issue.

opw-4256191