…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it should be. **Steps to reproduce:** - Open point Of Sale/Configuration/Taxes - Create a new tax, with an amount of 7% - In the Advanced option tab set "Included In Price" to "Tax Included" - Create a product A with a Sales Price of 95$ and select the tax you created as the "Sales tax" - Cr

…unding method

**Problem:**
The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it should be.

**Steps to reproduce:**
- Open point Of Sale/Configuration/Taxes
- Create a new tax, with an amount of 7%
- In the Advanced option tab set "Included In Price" to "Tax Included"
- Create a product A with a Sales Price of 95$ and select the tax you created as the "Sales tax"
- Create a product B with a Sales Price of 42$ and select the tax you created as the "Sales tax"
- Open Accounting/Configuration/Management/Cash Roundings and create a new rounding
- As Rounding Precision select 1.00 (the bug can happen also with other values here)
- Set Rounding Strategy as "Add a rounding line"
- Set Rounding Method to "Up"
- Open the point of Sale app and open a store
- Select one product A and two product B in the order
- Click on payment and Cash
- Enter a cash value of 200$

**Current behavior:**
The Change has a value of 20

**Expected behavior:**
The change should have a value of 21

**Cause of the issue:**
In account_tax.js

tax_totals_summary.base_amount_currency takes the values of values.total_excluded_currency https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L871

values.total_excluded_currency is computed as the sum of two floats With the values of our steps it creates a floating-point rounding error (the value is 88.79+78.50=167.29000000000002 and the rounding error is 0.00000000000002) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1166

tax_totals_summary.base_amount_currency is then used in another float addition to compute total_amount_currency.Because it's the second float addition the rounding error increases. (the value calculated is 167.29000000000002+11.71=179.00000000000003 and now the rounding error is 0.00000000000003)
https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1011

total_amount_currency is then used in pos_order.js to compute the remaining https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L157 https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L161

The remaining is used inside of the get_change method https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L887 this 0.00000000000003 rounding error has propagated to there and the value is 20.99999999999997 instead of 21

Because the rounding error comes from two consecutive float addition it's too big to be compensated by epsilon (here epsilon has a value of 1.8651746813702624e-14 which brings the value to 20.99999999999999)
https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/web/static/src/core/utils/numbers.js#L71 Consequently when it's rounded down (the inversion from up to down is because the change value is negative) it's rounded to 20 instead of 21

**Fix:**
Because this rounding mistake only appears with the value of "remaining" I added a rounding inside getRoundedRemaining before applying any customized rounding method.

opw-4615638

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#204301

**Problem**: When a RFQ is created automatically (MTO, reordering rule, manual replenish) for a product which has a different currency in general information (next to cost) and in the vendor line (in the pruchase tab). If the conditions of the vendors pricelists aren't met (ex not enough quantity) the price on the RFQ will be the cost from the "general information tab" and the currency will come from the vendor in the purchase tab. This could be an issue especially if there's a high exchange

**Problem**: 
When a RFQ is created automatically (MTO, reordering rule, manual replenish) for a product which has a different currency in general information (next to cost) and in the vendor line (in the pruchase tab).
If the conditions of the vendors pricelists aren't met (ex not enough quantity) the price on the RFQ will be the cost from the "general information tab" and the currency will come from the vendor in the purchase tab. This could be an issue especially if there's a high exchange rate between the currencies. 

**Steps to reproduce**:
- in settings, activate another currency (ex:kr)
- create a new product
- set the product type as "storable product"
- set a cost in the general information tab and a currency (ex:1000kr)
- in the inventory tab set the route as "Buy"
- in the pruchase tab add a vendor line, with a vendor name, a quantity (ex:10) and a price in another currency (ex:8$)
- click on the replenish button and set a quantity below the minimum quantity of the vendor line you just created

**Current behavior**:
A RFQ is created, with a price equal to the cost set in general information and the currency of the vendor in the purchase tab (here:1000$).

**Expected behavior**:
When the conditions of the vendor's pricelist aren't met the price should be 0 and the currency should be the one of the vendor

**Fix**:
I reversed the changes made in this commit
https://github.com/odoo/odoo/pull/158650/commits/caf4974b770b3295faebdaab5014a879760ccd67 and adapted the test
Now, if the seller variable is empty (which happens when no pricelist is matched), the price is set to zero
https://github.com/odoo/odoo/blob/953eb7cc241e290e3e5d1ef19048213a206a1947/addons/purchase/models/purchase_order_line.py#L599

opw-4547212

Forward-Port-Of: odoo/odoo#205916
Forward-Port-Of: odoo/odoo#202011

When searching `message_partner_ids`, we have a search method that will replace the domain, so `_condition_to_sql` will not be called for that field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206562 Forward-Port-Of: odoo/odoo#203893

When searching `message_partner_ids`, we have a search method that will replace the domain, so `_condition_to_sql` will not be called for that field.


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

Forward-Port-Of: odoo/odoo#206562
Forward-Port-Of: odoo/odoo#203893

This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands. task-3572344 --- I confirm I have signed the CLA

This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands.


task-3572344


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

Forward-Port-Of: odoo/odoo#206412
Forward-Port-Of: odoo/odoo#180313

`TestItEdiDDT.test_deferred_invoice` creates a sales order but does not ensure the user has the rights to create one. https://runbot.odoo.com/odoo/error/163639 Forward-Port-Of: odoo/odoo#206613

`TestItEdiDDT.test_deferred_invoice` creates a sales order but does not ensure the user has the rights to create one.

https://runbot.odoo.com/odoo/error/163639

Forward-Port-Of: odoo/odoo#206613

Steps to reproduce the bug: - Create a storable product P1: - Tracked by: Lot - Update the quantity of P1 with one unit and Lot 1 - Create a storable product C1 - Tracked by: Serial Number - Update the quantity of C1 with one unit and SN1 - Navigate to Product P1 → Lot/SN → Click on Lot 1 → Repair Orders - Create a repair order: - Add part: Select product C1 with SN1 - Try to save Problem: The lot "Lot 1" is incompatible with the product "C1". Since we access

Steps to reproduce the bug:
- Create a storable product P1:
    - Tracked by: Lot

- Update the quantity of P1 with one unit and Lot 1

- Create a storable product C1
    - Tracked by: Serial Number

- Update the quantity of C1 with one unit and SN1

- Navigate to Product P1 → Lot/SN → Click on Lot 1 → Repair Orders
- Create a repair order:
    - Add part: Select product C1 with SN1
- Try to save

Problem:
The lot "Lot 1" is incompatible with the product "C1".
 Since we access the Repair Order view from the Lot/SN view, a default
 key is added with "Lot 1". As a result, when trying to create the
 "stock.move.line" for C1, this incorrect lot is used.

opw-4576741
opw-4576004

Forward-Port-Of: odoo/odoo#205383
Forward-Port-Of: odoo/odoo#202979

Steps to reproduce the bug: - Go to inventory settings and enable dropshipping option -> the operation type: dropship in created - Disable the drop-shipping option in the settings -> The module is uninstalled, but the operation type is not archived so it can cause a traceback if using it. Problem: The best solution, is to remove completely the picking type, but as is linked to several other records, like rule or purchase order, it will be impossible to delete everything related, so the b

Steps to reproduce the bug:
- Go to inventory settings and enable dropshipping option -> the operation type: dropship in created

- Disable the drop-shipping option in the settings -> The module is uninstalled, but the operation type is not archived so it can cause a traceback if using it.

Problem:
The best solution, is to remove completely the picking type, but as is linked to several other records, like rule or purchase order, it will be impossible to delete everything related, so the best solution is to archive it, so we can limit the impact of the uninstallation.

opw-4690502

Forward-Port-Of: odoo/odoo#205391

No task ID. Forward-Port-Of: odoo/odoo#205926

No task ID.

Forward-Port-Of: odoo/odoo#205926

Add a placeholder for Peppol EAS field. task-4544834 (Part-of) Forward-Port-Of: odoo/odoo#206385

Add a placeholder for Peppol EAS field.

task-4544834 (Part-of)

Forward-Port-Of: odoo/odoo#206385

Steps to Reproduce : - Drag and drop a "Text" snippet. - Click on "Hide on desktop". - Toggle on the eye button to force its visibility. - Click on a text outside the snippet & press enter. - Bug: the invisible snippet disappears. The issue comes from the fact that when we press Enter, a new paragraph is created and a history rollback is triggered at that moment. So when we go back in the history because of that rollback, the invisible snippet loses the "o_snippet_override_invisible" c

Steps to Reproduce :

- Drag and drop a "Text" snippet.
- Click on "Hide on desktop".
- Toggle on the eye button to force its visibility.
- Click on a text outside the snippet & press enter.
- Bug: the invisible snippet disappears.

The issue comes from the fact that when we press Enter, a new paragraph is created and a history rollback is triggered at that moment. So when we go back in the history because of that rollback, the invisible snippet loses the "o_snippet_override_invisible" class that had just been applied.

Actually, adding and removing this class should not be inside the observer. This commit prevents that from happening.

task-4690318

Forward-Port-Of: odoo/odoo#206266

Steps: - install `pos_restaurant` - open pos restaurant - create new order - add two products - split the bill in two - 1 product per bill - pay for both of them - go to pos.order - the second bill does not have `pos_reference` When we split a bill in two, for example, we'll transform our order into two orders. This is done in `createSplittedOrder` via the method ` this.pos.createNewOrder()`. The `pos.order` is created in it and via `getNextOrderRefs` is called to set some values

Steps:
- install `pos_restaurant`
- open pos restaurant
- create new order
- add two products
- split the bill in two
- 1 product per bill
- pay for both of them
- go to pos.order
- the second bill does not have `pos_reference`

When we split a bill in two, for example, we'll transform our order into two orders. This is done in `createSplittedOrder` via the method ` this.pos.createNewOrder()`.

The `pos.order` is created in it and via `getNextOrderRefs` is called to set some values retrieved from the `get_next_order_refs` server, such as the `pos_reference`, `sequence_number` etc...

Except that `getNextOrderRefs` is an asynchronous function, as it emits an rpc call.

The problem is that in `createSplittedOrder` we never wait for this rpc call to finish before continuing, which causes our bug: the second order created contains no `pos_reference`.

The solution provided by this commit is to use the asynchronism of `getNextOrderRefs` by using an optional callback passed to `getNextOrderRefs.then()` to make sure we've received the information from the server before continuing. With this method we don't change `createNewOrder` => it will still returns an order and not a `Promise`


opw-4573422

Forward-Port-Of: odoo/odoo#199371

This reverts commit 4c7942e6bd0459fc9014d2af4a67a68c8334bca4. Steps to reproduce ================== - Install account_accountant - Go to accounting - Close the onboarding banner => TypeError: Cannot read properties of null (reading 'context') at _preprocessAction Cause of the issue ================== With commit 4c7942e6bd04, the response when calling the action changed ```diff - {"jsonrpc": "2.0", "id": 10} + {"jsonrpc": "2.0", "id": 10, result: null} ``` https:

This reverts commit 4c7942e6bd0459fc9014d2af4a67a68c8334bca4.

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

- Install account_accountant
- Go to accounting
- Close the onboarding banner

=> TypeError: Cannot read properties of null (reading 'context')
    at _preprocessAction

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

With commit 4c7942e6bd04, the response when calling the action changed

```diff
- {"jsonrpc": "2.0", "id": 10}
+ {"jsonrpc": "2.0", "id": 10, result: null}
```

https://github.com/odoo/odoo/blob/c412f11c028a8c7ff6e6c10da0e3f9dbc55e8e80/addons/web/static/src/views/view_hook.js#L86-L89

The condition `action !== undefined` is no longer met since the result is null.

Solution
========

Since this can happen anywhere we make an RPC call and there's no easy way to detect it, we revert the commit in stable.

Forward-Port-Of: odoo/odoo#206444

It doesn't seem to be of any use, and neither module depends on account. It happens to pass if enterprise is available because avatax is `auto_install=['payment']` and has a dependency on `account`, so you install a payment module which installs `payment` which auto_installs avatax which installs `account` and you have account's groups available for `account`'s test utilities to resolve. If you only have community tho, it blows up in your face. Which I guess is what happens in the single a

It doesn't seem to be of any use, and neither module depends on account.

It happens to pass if enterprise is available because avatax is `auto_install=['payment']` and has a dependency on `account`, so you install a payment module which installs `payment` which auto_installs avatax which installs `account` and you have account's groups available for `account`'s test utilities to resolve.

If you only have community tho, it blows up in your face. Which I guess is what happens in the single app tests.

https://runbot.odoo.com/odoo/error/163117

Forward-Port-Of: odoo/odoo#206337
Forward-Port-Of: odoo/odoo#206079

Similar to #206050, sale_mrp has a bunch of forms which try to set the `product_id` on a bom without product variants being enabled, in which case the field is invisible and setting it fails. Since they don't seem to really care for variants, and the products are not created with variants, as in #206050 just don't set `product_id`. https://runbot.odoo.com/odoo/error/163112 Forward-Port-Of: odoo/odoo#206437

Similar to #206050, sale_mrp has a bunch of forms which try to set the `product_id` on a bom without product variants being enabled, in which case the field is invisible and setting it fails.

Since they don't seem to really care for variants, and the products are not created with variants, as in #206050 just don't set `product_id`.

https://runbot.odoo.com/odoo/error/163112

Forward-Port-Of: odoo/odoo#206437

Looping on self, but updating self. As this method is generally called on a singleton recordset no error has been reported but better safe than sorry. Forward-Port-Of: odoo/odoo#206465

Looping on self, but updating self. As this method is generally called on a singleton recordset no error has been reported but better safe than sorry.

Forward-Port-Of: odoo/odoo#206465

The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/odoo#206423 Forward-Port-Of: odoo/odoo#205900

The percentage sign is missing on the tax line
in the invoice report

opw-4661577

Forward-Port-Of: odoo/odoo#206423
Forward-Port-Of: odoo/odoo#205900

The commercial partner country field is required for later improvements namely filtering or reports related ones. --- task-4725240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205952

The commercial partner country field is required for later improvements namely filtering or reports related ones.

---

task-4725240

---

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

Forward-Port-Of: odoo/odoo#205952

Steps: - Install `project` - Open a task - Create a subtask - Try to access chatter - It works on desktop, because you have the expand button - It doesn't work on mobile This commit adds this button on mobile too opw-4631478 Forward-Port-Of: odoo/odoo#205843

Steps:
- Install `project`
- Open a task
- Create a subtask
- Try to access chatter
  - It works on desktop, because you have the expand button
  - It doesn't work on mobile

This commit adds this button on mobile too
opw-4631478

Forward-Port-Of: odoo/odoo#205843

Steps: - Sales/rental app > New/select order - Add a 'Deliverable' product and confirm order - Click on 'Delivery' stat button. - Cog menu > print > picking operations Issue: - when there is no packaging selected for product or units are same, quantity gets printed 2 times in the picking operations print. Cause: - There is no check added for comparing 'uom' of product & packaging. Fix: - checking similarity between product uom & packaging uom before printing solves the issue.

Steps:
- Sales/rental app > New/select order
- Add a 'Deliverable' product and confirm order
- Click on 'Delivery'  stat button.
- Cog menu > print > picking operations

Issue:
- when there is no packaging selected for product or units are same, quantity gets printed 2 times
  in the picking operations print.

Cause:
- There is no check added for comparing 'uom' of product & packaging.

Fix:
- checking similarity between product uom & packaging uom before printing solves the issue.

opw-4661359

Forward-Port-Of: odoo/odoo#204245

This PR fixes two behavior on the lipe xml export in Italy. --- The first one linked to this fix: https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc . It makes sure the options are gathered the right way depending on whether we export the xml from the report or from the closing entry. --- The second one makes sure the closing entry move is posted when the xml export is done pressing the "Post" button on it. --- no-task Forward-Port-Of: odoo/ente

This PR fixes two behavior on the lipe xml export in Italy.

---

The first one linked to this fix: https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc . It makes sure the options are gathered the right way depending on whether we export the xml from the report or from the closing entry.

---

The second one makes sure the closing entry move is posted when the xml export is done pressing the "Post" button on it.

---

no-task

Forward-Port-Of: odoo/enterprise#83628
Forward-Port-Of: odoo/enterprise#83503

`_test_send_invoice_and_credit_note` and `_test_send_invoiced_stock_moves` try to create sale orders, but don't check that the group is set on the user. https://runbot.odoo.com/odoo/error/163637 Forward-Port-Of: odoo/enterprise#83691

`_test_send_invoice_and_credit_note` and
`_test_send_invoiced_stock_moves` try to create sale orders, but don't check that the group is set on the user.

https://runbot.odoo.com/odoo/error/163637

Forward-Port-Of: odoo/enterprise#83691

Currently a traceback is occurring when the user tries to create an invoice payment with referrer in invoice. <b>To reproduce this issue:</b> 1) Install partner_commission without demo 2) Create a commission plan from crm with a rule containing category and rate 3) Create a product with the same category used in the above commission rule 4) Create a contact with commission plan and partner level in partner assignment 5) Create a confirmed customer invoice with line as above product

Currently a traceback is occurring when the user tries to create an invoice payment with referrer in invoice.

<b>To reproduce this issue:</b>

1) Install partner_commission without demo
2) Create a commission plan from crm with a rule containing category and rate 
3) Create a product with the same category used in the above commission rule 
4) Create a contact with commission plan and partner level in partner assignment 
5) Create a confirmed customer invoice with line as above product and referrer as
     above contact and register a payment.

<b>Error:- </b>
```
AttributeError: 'bool' object has no attribute 'partner_id'
```

The above traceback is occurring because we are trying to get the partner_id value from `_get_sales_representative` method.
https://github.com/odoo/enterprise/blob/313593cf176271060878dda5ebc677fa44b519db/partner_commission/models/account_move.py#L124-L125

But the above method tries to get the user_id from the sale order. Here in this case, we don't have any SO, so we the above method will return False.

https://github.com/odoo/enterprise/blob/313593cf176271060878dda5ebc677fa44b519db/partner_commission/models/account_move.py#L26-L27

This leads to the above traceback when parter_id is retrieved from the method.

<b>Solution:-</b>

Take the value of partner_id from purchase. Since the partner_id value is getting from move.referrer_id in purchase.

https://github.com/odoo/enterprise/blob/313593cf176271060878dda5ebc677fa44b519db/partner_commission/models/account_move.py#L46-L50

opw-4676967

Forward-Port-Of: odoo/enterprise#83482

Followup to #83427 as I missed a second issue in the test: `action_validate` can only be performed by a time off officer. So set that on the current user. Also `self.Requests.env.user` is the same as `self.env.user` so don't bother with the unnecessary indirection. https://runbot.odoo.com/odoo/error/164047 Forward-Port-Of: odoo/enterprise#83579

Followup to #83427 as I missed a second issue in the test: `action_validate` can only be performed by a time off officer.

So set that on the current user. Also `self.Requests.env.user` is the same as `self.env.user` so don't bother with the unnecessary indirection.

https://runbot.odoo.com/odoo/error/164047

Forward-Port-Of: odoo/enterprise#83579

`(stock.picking).move_ids_without_package.lot_ids` is gated on `stock.group_production_lot`, if the user doesn't have this group, the field is unavailable and trying to set it via the form fails. https://runbot.odoo.com/odoo/error/163100 Forward-Port-Of: odoo/enterprise#83588

`(stock.picking).move_ids_without_package.lot_ids` is gated on `stock.group_production_lot`, if the user doesn't have this group, the field is unavailable and trying to set it via the form fails.

https://runbot.odoo.com/odoo/error/163100

Forward-Port-Of: odoo/enterprise#83588

The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/enterprise#83596 Forward-Port-Of: odoo/enterprise#83497

The percentage sign is missing on the tax line
in the invoice report

opw-4661577

Forward-Port-Of: odoo/enterprise#83596
Forward-Port-Of: odoo/enterprise#83497

**Problem:** When doing a scrap from the barcode app, the source location field is not accessible. The default source location of the scrap will be the one of the stock move, this could be a problem if the product is located in a child location. For instance if confirming a sale order for product A (which is stored in WH/stock/Shelf 1), the pick generated by the sale order will be from WH/Stock to WH/Output (default pick values). In the barcode app, if doing a scrap from this picking, the

**Problem:**
When doing a scrap from the barcode app, the source location field is not accessible.
The default source location of the scrap will be the one of the stock move, this could be a problem
if the product is located in a child location.
For instance if confirming a sale order for product A (which is stored in WH/stock/Shelf 1), the pick generated by the sale order
will be from WH/Stock to WH/Output (default pick values).
In the barcode app, if doing a scrap from this picking, the source location will be WH/stock and the client will not be able
to change that because the field does not appear.

**Steps to reproduce:**
- From the inventory app dashboard select "internal transfer"
- Create a new internal transfer
- Enter a storable product
- Set a demand quantity
- Click on "Mark as Todo"
- Open the barcode app
- Click on operations
- Select "Internal Operations"
- Select the transfer you just created
- Click on the gear icon on the top right and select "scrap"

**Current Behavior:**
The source location field is not visible

**Expected Behavior:**
The source location field should be visible and editable

**Cause of the issue:**
The source location field is not in the view
https://github.com/odoo/enterprise/blob/a9334bb551606d0151d8fc7a8f3393c3a6e312b9/stock_barcode/views/stock_scrap_views.xml#L68

**Fix:**
I added the source location field in the view

opw-4489401

Forward-Port-Of: odoo/enterprise#83434
Forward-Port-Of: odoo/enterprise#82174

Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454 Forward-Port-Of: odoo/enterprise#83490 Forward-Port-Of: odoo/enterprise#81018

Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454

Forward-Port-Of: odoo/enterprise#83490
Forward-Port-Of: odoo/enterprise#81018

This PR follows the new format of the pairing code introduced in the internal PR https://github.com/odoo/internal/pull/3462/ It removes the spaces around the introduced pairing code and makes all leters uppercase before sending them to odoo iot proxy Forward-Port-Of: odoo/enterprise#82905

This PR follows the new format of the pairing code introduced in the internal PR https://github.com/odoo/internal/pull/3462/ 
It removes the spaces around the introduced pairing code and makes all leters uppercase before sending them to odoo iot proxy

Forward-Port-Of: odoo/enterprise#82905

In [1] we added a compute on wa_account_id in stead of a default to allow for a smarter default. We forgot to mark the field readonly in the process. This prevents the import of existing templates, or of templates from different accounts. task-4734669 Correction for: task-4369979 [1]: 7a593a4aa5040998dc12468dec12dca62f573030 Forward-Port-Of: odoo/enterprise#83562

In [1] we added a compute on wa_account_id in stead of a default to allow for a smarter default.

We forgot to mark the field readonly in the process. This prevents the import of existing templates, or of templates from different accounts.

task-4734669

Correction for:
task-4369979

[1]: 7a593a4aa5040998dc12468dec12dca62f573030

Forward-Port-Of: odoo/enterprise#83562