When importing a sale in PoS and doing a downpayment there was only one downpayment line created. And because of this the taxes where not always correct. If you do a 100% downpayment you would end up with negative untaxed amount on the invoice.

Steps to reproduce:
-------------------
* Create 2 taxes, A and B with 5% and 10%
* Create 2 products, A and B. Assign the 2 taxes to the products
* Create a sale order with the 2 products
* Open the sale order in PoS and make a downpayment for it
> Observation: There is only one downpayment line when it should have 2.

Why the fix:
------------
If you do the same flow in the sales app, you get 2 downpayment lines. We do this to allign the behavior in sales and PoS. For each unique tax combination we compute what part of the total downpayment should be assigned to it. Then we make sure that the taxes are assigned to the line and that the line has the right value.

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

Forward-Port-Of: odoo/odoo#174076

### Steps to reproduce:

- Create a product tracked by lot with a BOM
- Create and confirm an MO for 1 unit of that product
- Assign a producing lot via the [+] smart button
- Change the quantity producing to 2 and produce all
> Go on the Traceability Report an additional move_line associated to
your MO finished move was created and associated to the producing lot.
- Unlock the MO and change the quantity producing to 3
> Go on the Traceability Report an additional move_line associated to
your MO finished move was created and associated but the producing lot **is missing**

### Cause of the issue:

Changing the quantity producing on the MO and then marking the MO as done will trigger a call of the `_post_inventory` method. During this call the quantity of the finished move are adapted according to the quantity producing of the MO by these lines:
https://github.com/odoo/odoo/blob/4a388236ce49e03e3a32447f8fa6ed073a09126b/addons/mrp/models/mrp_production.py#L1700-L1702 The change of quantity will trigger a `_process_increase` of the qties of the finished move and will create an additional stock move line for the remaining qties:
https://github.com/odoo/odoo/blob/4a388236ce49e03e3a32447f8fa6ed073a09126b/addons/stock/models/stock_move.py#L2051-L2055 and the producing lot is added to this new line just after because of these lines:
https://github.com/odoo/odoo/blob/4a388236ce49e03e3a32447f8fa6ed073a09126b/addons/mrp/models/mrp_production.py#L1702-L1705 https://github.com/odoo/odoo/blob/f80094f43bcc464cc99fba6aa59f64659fe659b6/addons/mrp/models/mrp_production.py#L2780-L2784 By contrast, if you modify the quantity producing after the MO is marked as done, the quantity of the finished_move is modified dirrectly by the ovewrite of the `write` method of the `mrp_production` model: https://github.com/odoo/odoo/blob/4a388236ce49e03e3a32447f8fa6ed073a09126b/addons/mrp/models/mrp_production.py#L898-L899 This will also trigger a `_process_increase` but it will not add the `lot_id` to the new sml as in the `_post_inventory` call.

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

Forward-Port-Of: odoo/odoo#174489

Currently, when buying a gift card through the website and choosing the options to pick up in store and pay in store, the quantity set when settling the order is zero.

Steps to reproduce (initial):
-----------------------------
* Go to the **website** app
* Select **configuration** > **Payment Providers**
* Make sure `Pay in store` is published and enabled/or in test mode
* Select **configuration** > **Shipping methods**
* Make sure that a shipping method `Pick in store` is set up and published for your shop
* Now make an order on the website for a gift card and any storable product
* Choose the options to pick and pay in store
* Go to the **Point of sale** app
* Open shop session
* Settle the order just created
> Observation: The quantity for the gift card is 0

Steps to reproduce (alternative):
---------------------------------
* Go to **Sale** App
* Create a quotation for a gift card and any storable product
* Save the quotation (not confirm)
* Go to the **Point of sale** app
* Open shop session
* Settle the order just created

Why the fix:
------------
The issue is not specific to the gift card product, it affects all `'service'` products.
https://github.com/odoo/odoo/blob/7be2770f2a8dc26f7aa0c539b878b258e94592c8/addons/pos_sale/static/src/js/models.js#L85-L91

We notice that, if the order was paid instead of choosing the option to pay in store, the quantity on the pos order when settling it is 1. This is because the order not yet paid is still considered as a quotation. While if it is paid through the website it is considered as a sale order and thus `qty_to_invoice` has been computed.

The same behaviors can be replicated through the **Sale** app. If a quotation is only saved we also have a quantity of 0. If it is confirmed, the quantity is 1.

As discussed with DALA, using `qty_to_invoice` to set up the quantity in POS only makes sense when we deal with sale orders. When dealing with quotations we should set the quantities in the shop order depending on the quantities of the quotation.

opw-4003749

Forward-Port-Of: odoo/odoo#174835
Forward-Port-Of: odoo/odoo#173146

Problem:
For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold

Steps to reproduce:
- Install "point_of_sale" app and "pos_loyalty" module
- Select "Scan existing cards" in the promotions settings
- Generate a gift card with a value of 0.00 $ and copy its code
- Start a shop session
- Select the gift card product and enter the code
- Change the price of the gift card (must be an integer < 10)
- Proceed to the payment
- See the popup error

Cause:
As the gift card has no points, `couponPointChanges` stays empty. But when the price is modified, `couponPointChanges` is updated but has no giftCardId so the error is triggered (see `validateOrder` in PaymentScreen.js). There is no issue if the price is > 10 or is not an integer because `_updatePrograms` is called after each click on the numpad and `changesPerProgram` gets the values of `couponPointChanges` which are the saved in `oldChanges` which is modified by getting the values of `pointsAdded` which has `giftCardId` so `couponPointChanges` get the `giftCardId`

opw-3909019


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

Forward-Port-Of: odoo/odoo#174888
Forward-Port-Of: odoo/odoo#174538

**Steps to reproduce:**
- Install l10n_ar and website_sale
- Switch to an Argentinian company
- Create a product with a customer tax (e.g. IVA 21%)

With a public user or a user without "AFIP Responsibility":
- Go to eShop and add the created product to the cart
- Go to the cart

**Issue:**
No tax is applied.

**Cause:**
There are some fiscal positions from Argentinian localization that map IVA 21% to IVA Exento (i.e. 0%).
These fiscal positions are linked to specific "AFIP Responsibility" types and should only be applied for users having these "AFIP Responsibility" types configured on their contact form.
However, when this field is not set, it is ignored in the domain computing the fiscal position and one of these Argentinian fiscal positions satisfies the resulting domain.

**Solution:**
Filter on "AFIP Responsibility" in the domain computing the fiscal position if "l10n_ar_afip_responsibility_type_id" key is present in the context, no matter what its value.

opw-3943108




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

Forward-Port-Of: odoo/odoo#171923

Errors returned by Avatax when creating an account are not consistent. Sometimes the 'message' key contains a string with JSON. Other times it's a human-readable string with an error message. And other times it's a non-descript error that we replace with a more user-friendly error to guide users towards the most common fix.

Before this fix a traceback appeared when a human-readable error string was returned without 'unhandled error occured':

```
File ".../l10n_br_avatax/models/res_config_settings.py", line 85, in create_account
result = json.loads(result['message'])
File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```

This makes the error handling more robust by first attempting to decode the string as JSON. If that fails we fall back on the other two scenarios.

A new test class is included that provides examples of each type of response.

opw-4067842

Forward-Port-Of: odoo/enterprise#67477

Steps to reproduce
==================

- Install account_accountant,web_studio
- Go to Accounting > Configuration > Account Groups
- Open studio
- Switch to the form view
- Show invisible elements
- Add a new field before the invisible Company field

=> Error: Xpath resolved to nothing or multiple nodes

Cause of the issue
==================

The xpath props of the StudioHook is the string "null"

The fields of this view are defined inside an InnerGroup but there is no OuterGroup.

```xml
<form><sheet>
    <group>
        <field .../>
        ...
    </group>
</sheet></form>
```

In the form compiler, when a group does not contain another group, it is an InnerGroup

The form editor compiler uses some `interestingSelector` to compute xpaths.

It assumed that an InnerGroup was always inside an OuterGroup

Solution
========

Since the `:has` selector has not been widely supported for long enough,
we do the equivalent of `:not(field) group:not(:has(> group)) > *` in
javascript to match any group that has no direct group as a child.

opw-4046558

Forward-Port-Of: odoo/enterprise#67151

## Issue
Shop Floor can show performance issues even with the default limit of 40.
This is mostly due to the `operation_note` fetched for the work orders.
Moreover, as it's a HTML field, it has to be sanitized by the ORM - which is slow considering users tend to put base64 encoded images in it.

## Analysis
It is not necessary to fetch the `operation_note` for all displayed work orders as it's only shown when an user will click on the *Worksheet* button or a *Quality Check* button.

## Solution
In case there is no PDF or Slide, the *Worksheet* button is only displayed when there's an `operation_note`. 
Therefore, we introduce a `has_operation_note` field to keep that behavior (refer to the Community commit).
When a user clicks on a *Worksheet*/*Quality Check* button, we fetch the `operation_note` from the backend and cache it so we don't need to send another request later on.

## Benchmarks
Benchmarks are done calling `web_search_read` on a database containing base64 images.
|  Displayed MO    | Before  | After  | Speed up |
|-------------|---------|--------| --------|
| 40 | 8.19 s | 400 ms | ~95%
| 100 | 23.9 s / MemoryError | 900 ms | ~96%

## References
opw-3983324

--
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#66176

Module : account_reports

Issue reproduction : 
- Go to Accounting / Configuration / Management / Accounting reports
- Edit "Journal Report"
- Activate the filter "Account types" in the options tab
- Go on Accounting / Reporting / Audit reports / Journal Report
- traceback with a psycopg2.errors.UndefinedTable error 

Cause : 
The query generated in **_query_journal()** on account_journal_report.py doesn't use **account_account** table in the FROM clause. This table is included in the  **tables** value created from **_query_get()** but this variable can't be used as it is because it starts with the **account_move_line** table for the FROM clause. 

Solution : 
Use the **tables** variable and modify the sql query. 

Versions impacted : 
- 16.0, saas-16-1, saas-16-2, saas-16-3, saas-16-4
- 17, saas-17-1 

Note : **filter_account_type** change from a boolean field to a selection field from version 17 but the error is the same

Support ticket : 3708809

Forward-Port-Of: odoo/enterprise#59439
Forward-Port-Of: odoo/enterprise#57828

The amount to settle was not shown in the tree view for the older column due to the [domain prepared](https://github.com/odoo/enterprise/blob/17.0/account_reports/models/account_aged_partner_balance.py#L380-L392) for the older column being capped between 30 days, similar to the other columns(1-30, 31-60, etc.) in the Aged Receivable report.

**Step to reproduce:**
 - create an invoice with due date 150 days back
 - open the Aged receivable report and find that invoice
 - The record of `account.move.line` will not be shown in the tree view (Amount to settle)

This patch handle the domain for `period5`.

**Before fix:** 
![Screenshot from 2024-07-18 16-45-10](https://github.com/user-attachments/assets/8b0be875-cc6b-4365-a003-c37781094387)

![Screenshot from 2024-07-18 16-45-28](https://github.com/user-attachments/assets/49b5a875-7fa7-420d-bba4-24bd7098031b)

**After fix:**
![Screenshot from 2024-07-18 16-45-59](https://github.com/user-attachments/assets/b615a080-deb8-4955-8426-a7fe53b02f93)


OPW - 4048535

Forward-Port-Of: odoo/enterprise#66884

When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field.

### Steps to Reproduce

1. Install `l10n_be`, `account_accountant`, and `account_sepa_pain_001_001_09`.
2. In the settings, enable 'SEPA Credit Transfer (SCT)'.
3. Switch to a Belgian company.
4. Set up an IBAN bank account on the bank journal.
5. Ensure a partner has an IBAN bank account defined.
6. Create and confirm an outgoing payment for that partner, setting the payment method to 'SEPA Credit Transfer'.
7. In the Outgoing Payments tab of the bank journal, set the SEPA Pain Version to 'New generic version'.
8. Create a batch payment with the payment you just created.
9. Attempt to validate it.

### Expected Result

The payment should be validated successfully.

### Actual Result

A traceback occurs: `TypeError: Argument must be bytes or unicode, got 'bool'`

### Cause

The payment in the batch was created before the SEPA PAIN version was updated on the bank journal. Consequently, the payment is missing some necessary data (specifically, the UETR field is not set) required for the new SEPA version.


opw-3973374

Forward-Port-Of: odoo/enterprise#67451
Forward-Port-Of: odoo/enterprise#65614

Using distinct websockets (ws) per company cause a lot of diffent issues, for example:

## Issue this PR solve:
### Multi-company:
Assume we have an IoT with no company set. In this case, it should be able to print from any company.
In practice, it is not the case as the IoT will listen to the channel of the first company, so it will always fail if the user company is not the first one.

Same goes if we have child companies, if C2 is a child company of C1, then C2 should be able to print too. With current code it is not the case as C1 and C2 will have distincts channels

### Change of IoT company:
When the IoT start, it makes a call to know its channel (see iot/setup route).
However, if we change the company set on the IoT, it should change its channel to match the one of newly set company. In practice it is not the case and will only happen on the next iot/setup call (which happen each 3 seconds call in theory IF new devices are detected)

### Simplicity
Help simplifying the code as it was sometime complicated to be get the right websocket.

For example, when the IoT reply back that the operation completed, see `/iot/printer/status` route. Relying on the IoT device company might be wrong as if no company is set, we don't know the company that the user who did the request is, so we might send on the bus on the wrong channel.
In this case, the document did print but the pop-up will still pop

### Visibility
The iot.channel had no practical way to be browsed as there is no view defined for this model. The only feasible way to get its data for a functional would be to run a server action or create a view.

Using a system parameter is more practical and only accessible for admin users


## Downside of this PR:
- system parameter could be modified manually
- websocket send/receive more messages
- stability: to ease the transition, I tried to get the existing ws channel using basic heuristics, but it might be wrong (if a company other than the first is set on the IoT).
In the worst case, they will have to restart their IoT to get the new channel

opw-4038176

Forward-Port-Of: odoo/enterprise#66573

Steps:
-------
1. go to any operations of th barcorde app
2. go to a specific line
3. change the quantity thanks to the +1 / -1
4. try to erase using backspace or the erase button

Current behavior before PR:
------
We need several backspaces to erase the value

Desired behavior after PR is merged:
-------
If the value is '3' for example, only 1 backspace should be needed.

Explanation:
-----
Incrementing will set the precision to the value specified, which mean 3 is actually stored as 3.00 on the Digipad, but parsing it as a Number in `_notifyChanges` will remove these trailing zeros.

One solution would be to pass the string to the ORM instead of passing it a number, but this has the disadvantages to set the value as 3.00 visually (so the user still need to delete multiple zeros).

The solution adopted removes the trailing zeros.

Side note: This does not fix the inconsitency where the value displayed is "3" when the Digipad value id "3.".

opw-4061351

Forward-Port-Of: odoo/enterprise#67459
Forward-Port-Of: odoo/enterprise#67279