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

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 a customer adds an empty internal note and tries to order the product,
a traceback will appear.

Steps to reproduce the error:
- Open PoS restaurant session
- Add any product > Order
- Add same product again > Add an empty internal note
- Order

Traceback:
```
KeyError: (3, 'pou', '[]')
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/pos_restaurant_preparation_display/models/preparation_display_order.py", line 33, in process_order
    res = super().process_order(order_id, cancelled, note_history)
  File "home/odoo/src/enterprise/saas-17.2/pos_preparation_display/models/preparation_display_order.py", line 28, in process_order
    data = order._process_preparation_changes(cancelled, note_history)
  File "home/odoo/src/enterprise/saas-17.2/pos_preparation_display/models/pos_order.py", line 95, in _process_preparation_changes
    quantity_data[key_new]["display"] += old_quantity["display"]
```

https://github.com/odoo/enterprise/blob/4077a5e39fba7197d32d5db05171ad9c8f98c392/pos_preparation_display/models/pos_order.py#L95
Here when customer adds an empty internal note, ```quantity_data``` will become empty,
So, it will lead to the above traceback.

sentry-5494183916

Forward-Port-Of: odoo/enterprise#67135
Forward-Port-Of: odoo/enterprise#66145

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

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

This commit does three things:
    
1) Global Discounts: When creating an invoice with a negative line, such as a Tax Invoice with global discount, we process the line as a document level allowance as required by ZATCA, and remove it from the lines sent in the UBL. This allows us to provide support for global discounts, such as those applied by promotion programs

2) Add support for down-payment document type in _l10n_sa_get_invoice_type method: 386
    
3) Trim spaces from phone numbers before submission to avoid receiving warnings from ZATCA

Description of the issue/feature this PR addresses:
Process global discounts into AllowanceCharge values for ZATCA saudi eInvoicing.
Avoid warnings regarding spaces in phone numbers.
Add support for down-payment invoice type code.

Current behavior before PR:
If a promotions program is applied on a sale order or POS order, or a line with a negative amount is added on an invoice, the line is sent as is to the authorities, which triggers an error as ZATCA only accepts positive amount lines.
If a phone number is provided, ZATCA returns a warning regarding the phone number format.

Desired behavior after PR is merged:
Negative lines on an invoice, that are not related to a down-payment, should be processed as document level allowances.
Phone numbers are correctly formatted prior to sending to ZATCA.
Down-payment invoices use the appropriate document type code.



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

Forward-Port-Of: odoo/odoo#154608
Forward-Port-Of: odoo/odoo#153379

Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price.

Steps to reproduce:
-------------------
* Make a new quotation in **sales**
* Change the unit price of a product
* Confirm quotation
* Open the pos shop session
* Import the newly created quotation to be settled
* Change the partner
> Observation: The price set manually changes to the product sale price

Why the fix:
------------
When changing the partner of a sale order we compute all the line that have to recompute their prices:
https://github.com/odoo/odoo/blob/57f1b0bd502938a6d50244896e71df73705584b5/addons/point_of_sale/static/src/js/models.js#L2918-L2920

We see that when we settle an order, `price_manually_set` is set to false. In this example, if we set it to true it would solve the issue but we cannot use it, see with https://github.com/odoo/odoo/commit/70668ee3c3e2c1dd213903b44f4d36cc8ac9fa29 .

Instead what we can do is to use `price_automatically_set` and set it to true. This does not undo the previously mentionned commit and fixes this current issue. This variable was created in https://github.com/odoo/odoo/commit/067299539116b55a449f022706c395dda2177829

opw-4001497

Forward-Port-Of: odoo/odoo#174649
Forward-Port-Of: odoo/odoo#172205

**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

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#174982
Forward-Port-Of: odoo/odoo#174538

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#175000
Forward-Port-Of: odoo/odoo#173146