Adds easier management of foreign partners that are both suppliers and customers by automatically selecting the correct generic TIN if the one set on the partner is also a generic TIN. Also adds some logic that allows to tag a credit note as 'refund' if it matches some conditions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199150

Adds easier management of foreign partners that are both suppliers and customers by automatically selecting the correct generic TIN if the one set on the partner is also a generic TIN.

Also adds some logic that allows to tag a credit note as 'refund' if it matches some conditions.

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

Forward-Port-Of: odoo/odoo#199150

When sending an invoice to Viettel, we currently raise an error in Odoo if the address information of the customer is not set. If the VAT is not set, it is the api raising an error. In both case, the information is optional, and we should be able to invoice. For the address information the validation in Odoo is removed, and for the VAT the json will now contain '' if it is not set instead of False Also make sure that the json file is attached to the chatter if it has been generate

When sending an invoice to Viettel, we currently
raise an error in Odoo if the address information
of the customer is not set.
If the VAT is not set, it is the api raising an
error.

In both case, the information is optional, and
we should be able to invoice.
For the address information the validation in
Odoo is removed, and for the VAT the json will
now contain '' if it is not set instead of False

Also make sure that the json file is attached
to the chatter if it has been generated for audit
purpose

task-4405507

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

Forward-Port-Of: odoo/odoo#196547

Before this commit the test `test_access_my_profile_toolbar` was failing because there was no `action` available to the user in the toolbar. This commit changes the test to adapt to this situation. Runbot Error: https://runbot.odoo.com/odoo/error/159894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201108

Before this commit the test `test_access_my_profile_toolbar` was failing because there was no `action` available to the user in the toolbar. This commit changes the test to adapt to this situation.

Runbot Error: https://runbot.odoo.com/odoo/error/159894



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

Forward-Port-Of: odoo/odoo#201108

When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner. We extend WebsiteSale to add `computeCodiceFiscale`, which will be triggered when the input field VAT or the select field Country change in the Address form. The function fills the Codice Fi

When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner.

We extend WebsiteSale to add `computeCodiceFiscale`, which will be triggered when the input field VAT or the select field Country change in the Address form. The function fills the Codice Fiscale if the VAT field is filled, and it starts with 'IT' or the country selected is Italy.

Task [link](https://www.odoo.com/odoo/project/967/tasks/4596227)
task-4596227

Forward-Port-Of: odoo/odoo#201894
Forward-Port-Of: odoo/odoo#199876

Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is inconsistent, as having more access in Timesheets should not restrict access in Accounting. Steps to Reproduce: - Create an invoice with analytic distribution. - Go to Journal Items. - Export the journal item, including analytic lines fields Issue: The user will not be able to export the data from thes

Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines.
This is inconsistent, as having more access in Timesheets should not restrict access in Accounting.

Steps to Reproduce:
- Create an invoice with analytic distribution.
- Go to Journal Items.
- Export the journal item, including analytic lines fields

Issue: The user will not be able to export the data from these fields.

It occurs because timesheet users are restricted by ir-rules that allows access only to users owning the record or associated with a related project/task
https://github.com/odoo/odoo/blob/34947c01623a9fc753197bd55d6121d9c6fa682f/addons/hr_timesheet/security/hr_timesheet_security.xml#L52

Solution is to add an ir-rule in account to allow read access to read-only users

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4586096)
opw-4586096

Forward-Port-Of: odoo/odoo#202080
Forward-Port-Of: odoo/odoo#201365

### Steps to reproduce: - Create a storable product tracked by serial number available from the pos and with a set pos category. - Open a pos session and click on your product. > A dialog openns for you to register serial numbers. - Edit a first SN: SN001 and press enter > A new line can now be set to create a second one. - Edit a second SN: SN002 and press enter - Confirm the dialog #### > The quantity displayed on teh POS order line is 1 rather than 2. ### Cause of the issue: C

### Steps to reproduce:

- Create a storable product tracked by serial number available from the pos and with a set pos category.
- Open a pos session and click on your product.
> A dialog openns for you to register serial numbers.
- Edit a first SN: SN001 and press enter
> A new line can now be set to create a second one.
- Edit a second SN: SN002 and press enter
- Confirm the dialog
#### > The quantity displayed on teh POS order line is 1 rather than 2.

### Cause of the issue:

Clicking on the product card from the pos will trigger a call of the `AddProductToCurrentOrder` that will add a quantity of the product set via the options:
https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/pos_store.js#L1965-L1978 However, the `getAddProductOptions` call sets a quantity to add of 1 no matter if you added multiple or even removed multiple registered SN. https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L180 On the other hand, since at the moment of this call we do not have the info of the lines that were removed in the dialog it is not possible to always provide the correct (possibly negative) quantity to add to the line for the qty to be correctly handledby the posorder line. However, just as when you edit the line dirrectly this can be achieved by updating the quantity based on the relevant lots present on the line: https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L570-L572

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

Forward-Port-Of: odoo/odoo#199127

Since https://github.com/odoo/odoo/pull/103510 , _read_group raises a StopIteration error if there are duplicate groupby specifications. This is because `groupby_terms` has become a `dict` which doesn't allow duplication but we are still looping on the `groupby` list to retrieve columns, leading to raise a StopIteration error when we try to retrieve the last column. Fix this by creating `groupby_terms` with `groupby` instead of values from the dict. Forward-Port-Of: odoo/odoo#202115

Since https://github.com/odoo/odoo/pull/103510 , _read_group raises a StopIteration error if there are duplicate groupby specifications. This is because `groupby_terms` has become a `dict` which doesn't allow duplication but we are still looping on the `groupby` list to retrieve columns, leading to raise a StopIteration error when we try to retrieve the last column.

Fix this by creating `groupby_terms` with `groupby` instead of values from the dict.

Forward-Port-Of: odoo/odoo#202115

When producing a MO with components and the components don't have any available quantity, there are no direct link between the MO and the stock move lines of its move_raw_ids. This causes issues when filtering on MO in the Moves History report. This is because the link is only done at the reservation of the SMLs, which can't happen without available qty. This fix ensures that the MO is added at the SML creation. opw-4545828 --- I confirm I have signed the CLA and read the PR guideli

When producing a MO with components and the components don't have any available quantity, there are no direct link between the MO and the stock move lines of its move_raw_ids. This causes issues when filtering on MO in the Moves History report.

This is because the link is only done at the reservation of the SMLs, which can't happen without available qty.

This fix ensures that the MO is added at the SML creation.

opw-4545828

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

Forward-Port-Of: odoo/odoo#202055

Steps to reproduce: - Go to Accounting > Customers > Invoices - Insert the list into a spreadsheet - in any cell, type `=ODOO.LIST(1,1,"company_currency_id")` => the currency is not displayed. The reason is that the `company_currency_id` is fetched as part of a monetary field. When the new `=ODOO.LIST(1,1,"company_currency_id")` is typed, the list data source thinks it has the data, but actually the `dislay_name` is missing. Task: 4633078 --- I confirm I have signed the CLA and

Steps to reproduce:

- Go to Accounting > Customers > Invoices
- Insert the list into a spreadsheet
- in any cell, type `=ODOO.LIST(1,1,"company_currency_id")`

=> the currency is not displayed.

The reason is that the `company_currency_id` is fetched as part of a monetary field. When the new `=ODOO.LIST(1,1,"company_currency_id")` is typed, the list data source thinks it has the data, but actually the `dislay_name` is missing.

Task: 4633078

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

Forward-Port-Of: odoo/odoo#200663

When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view. Steps: - Activate routes & by-product in the main settings - Activate manufacturing in 3 steps on the warehouse - Create manufacturing order for a product and add a by-product with a positi

When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view.

Steps:
- Activate routes & by-product in the main settings
- Activate manufacturing in 3 steps on the warehouse
- Create manufacturing order for a product and add a by-product with a positive quantity
- Confirm manufacturing order
- Pick components
- Produce & close MO

opw-4620008

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

Forward-Port-Of: odoo/odoo#202054
Forward-Port-Of: odoo/odoo#201619

- Create an invoice and set its delivery date to a date other than today. - Generate the cii facturx xml. Under <ram:ActualDeliverySupplyChainEvent>, the date is incorrectly set to today instead of the invoice's delivery date. This commit applies the same treatment as https://github.com/odoo/odoo/commit/dda560005b2372ed8f6fa0cf3fd6c6f7ca0d1fe3 but for account_edi_xml_cii_facturx. opw-4531928 Description of the issue/feature this PR addresses: Current behavior before PR: Desi

- Create an invoice and set its delivery date to a date other than today.

- Generate the cii facturx xml.

Under <ram:ActualDeliverySupplyChainEvent>, the date is incorrectly set to today instead of the invoice's delivery date.

This commit applies the same treatment as https://github.com/odoo/odoo/commit/dda560005b2372ed8f6fa0cf3fd6c6f7ca0d1fe3 but for account_edi_xml_cii_facturx.

opw-4531928

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

…versalCommunication Our facturx XML are not correct, they are raising "/rsm:CrossIndustryInvoice[1]/rsm:SupplyChainTradeTransaction[1] /ram:ApplicableHeaderTradeAgreement[1]/ram:BuyerTradeParty[1]/ ram:DefinedTradeContact[1]/ram:EmailURIUniversalCommunication[1]/ram:URIID[1]" "Attribute @schemeID' marked as not used in the given context." errors (for both `BuyerTradeParty`and `SellerTradeParty`). Which in other words means the parameter `@shemeID` should not be there in the tag EmailURIU

…versalCommunication

Our facturx XML are not correct, they are raising
"/rsm:CrossIndustryInvoice[1]/rsm:SupplyChainTradeTransaction[1] /ram:ApplicableHeaderTradeAgreement[1]/ram:BuyerTradeParty[1]/ ram:DefinedTradeContact[1]/ram:EmailURIUniversalCommunication[1]/ram:URIID[1]" "Attribute @schemeID' marked as not used in the given context." errors (for both `BuyerTradeParty`and `SellerTradeParty`).

Which in other words means the parameter `@shemeID` should not be there in the tag EmailURIUniversalCommunication.

### Before
![image](https://github.com/user-attachments/assets/e8ac837f-ab54-4b45-95a0-ba5ae1f1a668)

### After
![image](https://github.com/user-attachments/assets/2f72c1a9-6e5f-4aa9-9ef8-90864826d37f)

Tested on Ecosio with ZUGFeRD 2.3.2 EXTENDED, that is the same as FacturX 1.07.2.

opw-4571664

Forward-Port-Of: odoo/odoo#201623

Versions -------- - 16.0+ Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign them as salesperson to a sales order with two lines; 3. create an draft invoice for one line; 4. assign admin as salesperson on the invoice; 5. as user, create a draft invoice for the other line (optional); 6. as user, cancel the sales order. Issue ----- If no second draft invoice was created, there's no warning displayed that a draft invoice exists. If one was creat

Versions
--------
- 16.0+

Steps
-----
1. Have a internal user with only Sales: Own Documents access;
2. assign them as salesperson to a sales order with two lines;
3. create an draft invoice for one line;
4. assign admin as salesperson on the invoice;
5. as user, create a draft invoice for the other line (optional);
6. as user, cancel the sales order.

Issue
-----
If no second draft invoice was created, there's no warning displayed that a draft invoice exists.

If one was created, trying to cancel will say you're not allowed to read journal entries.

You are supposed to get an error when trying to modify journal entries.

Cause
-----
The cancel wizard doesn't check the order's invoices using sudo.

Solution
--------
Check the order's invoices using sudo.

opw-4554639

Forward-Port-Of: odoo/odoo#201785

Steps to reproduce: - Go to accounting > configuration > payment terms > NEW - Create a new payment terms with Early Discount checked > confirm - Go to customer > invoices > NEW - Create a new invoice with the payment terms selected > confirm. - When clicking "Restiger Payment" to manually pay, the modal will display the early discount informations if the invoice is eligible. - Click on Preview (short cut to access to the invoice through the portal) - Assuming the invoice is eligible for

Steps to reproduce:
- Go to accounting > configuration > payment terms > NEW
- Create a new payment terms with Early Discount checked > confirm
- Go to customer > invoices > NEW
- Create a new invoice with the payment terms selected > confirm.
- When clicking "Restiger Payment" to manually pay, the modal will display the early discount informations if the invoice is eligible.
- Click on Preview (short cut to access to the invoice through the portal)
- Assuming the invoice is eligible for early payment discount, the informations are not displayed in the side bar.
- Click on pay > select a payment provider > confirm
- Notice how the full payment was registered in accounting chart of account.

Cause:
the early discount feature is not properly handled in the portal view.

Analysis:
When previewing the transaction, the context sent `amount` is not well computed (controller portal). This `amount` context is the one used when creating the transaction https://github.com/odoo/odoo/blob/3ef9310ec36f1d5abd3f55e92eedb2ac7133d97a/addons/account_payment/controllers/payment.py#L40-L42 Therefore, we need to make sure that the `amount` defined in the view is the discounted amount if early_payment and the full amount if not.

Solution:
Mainly backport from https://github.com/odoo/odoo/pull/177905/

XML:
- we keep the the `t-if="0"` to not break Xpath in stable
- `t-if="amount"` just to make sure it does not break for a credit note https://github.com/odoo/odoo/blob/17.0/addons/account_payment/controllers/portal.py#L14-L16

opw-3632594

Forward-Port-Of: odoo/odoo#184115

Some of our new deductible taxes were wrong, this commit fixes them. It also adds a new tax for deductiblility of 35% in the EU (which is more frequent), and one for deductibility of 35% in the case of delivery of goods already in Belgium by a foreign entity. task-none Forward-Port-Of: odoo/odoo#201782

Some of our new deductible taxes were wrong, this commit fixes them.

It also adds a new tax for deductiblility of 35% in the EU (which is more frequent), and one for deductibility of 35% in the case of delivery of goods already in Belgium by a foreign entity.

task-none

Forward-Port-Of: odoo/odoo#201782

Steps: - Install Ecommerce - Add some products to the cart - Remove them using the 'remove' option - Go to my/orders - select any order, then click on Order again - Click on the Add To Cart button - You'll see one confirmation dialog Issue: - By clicking on the add to cart button, that confirmation dialog should not be there as the cart is empty Cause: - Cart quantity does not update when the last product is removed Fix: - While removing the last product, set cart quantity in

Steps:
- Install Ecommerce
- Add some products to the cart
- Remove them using the 'remove' option
- Go to my/orders
- select any order, then click on Order again
- Click on the Add To Cart button
- You'll see one confirmation dialog

Issue:
- By clicking on the add to cart button, that confirmation dialog should not be there as the cart is empty

Cause:
- Cart quantity does not update when the last product is removed

Fix:
- While removing the last product, set cart quantity in sessionstorage to ensure that the last removal is recorded

affected version-17.0
opw-4566505

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

Forward-Port-Of: odoo/odoo#199921

Versions -------- - 17.0+ Steps ----- 1. Create an event with an attendee limit of 1; 2. publish the event; 3. add a ticket to you cart; 4. go through checkout until your reach the payment page; 5. open a incognito window or different browser; 6. add same ticket to cart; 7. go to the payment step; 8. click "Pay now" and wait for confirmation; 9. go to previous window, and click "Pay now". Issue ----- The payment gets confirmed, but you land on an internal server error due to

Versions
--------
- 17.0+

Steps
-----
1. Create an event with an attendee limit of 1;
2. publish the event;
3. add a ticket to you cart;
4. go through checkout until your reach the payment page;
5. open a incognito window or different browser;
6. add same ticket to cart;
7. go to the payment step;
8. click "Pay now" and wait for confirmation;
9. go to previous window, and click "Pay now".

Issue
-----
The payment gets confirmed, but you land on an internal server error due to a lack of available seats for the event.

Cause
-----
Commit ffc9026361beb added a check before payment to ensure the tickets still had seats available. The event itself however can have a separate seat limit that isn't currently being checked.

Solution
--------
Add a check on the event's seat availability to `_validate_transaction_for_order`.

Also, in case there's a lack of seats, display the correct number of lacking seats for the order instead of `-available_seats`.

opw-4453539

Forward-Port-Of: odoo/odoo#200400

Current behaviour: --- Mexican phone numbers are not managed correctly following the 2019 changes in Mexico. (Removing a 1 in phone numbers) Cause of the issue: --- The phonenumbers library removing support of mexican phone numbers starting with 1 in 8.13.38 The Whatsapp API still using the mexican phone numbers starting with 1 Fixes: --- Patched the phonenumbers library, removing 1 at the right place for mexican phone numbers. Similar to: https://github.com/odoo/odoo/commit/53885

Current behaviour:
---
Mexican phone numbers are not managed correctly following the 2019 changes in Mexico.
(Removing a 1 in phone numbers)

Cause of the issue:
---
The phonenumbers library removing support of mexican phone numbers starting with 1 in 8.13.38
The Whatsapp API still using the mexican phone numbers starting with 1

Fixes:
---
Patched the phonenumbers library, removing 1 at the right place for mexican phone numbers.
Similar to: https://github.com/odoo/odoo/commit/53885e41867653ad45ca3aef55886c280240b76a

Changed the forcing to international format when parsing, to make sure the patches are applied before detecting an issue. 
Similar to: https://github.com/odoo/odoo/commit/29a4de8e29a2e330b8e5993c9fde23c69a2eff5e

opw-4473528

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

Forward-Port-Of: odoo/odoo#197838

Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing. Since [1], opening a thread *always* result in a bus subscription being issued (the channel is added to the bus channels as a string). This is not required: bus subscriptions are based on user's channels (see `ir_websocket@_build_bus_channel_list`). When a new channel is added, the client subscribes again (see `toggleBusSubscription`). Channels should only be added explictly when a channe

Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing.

Since [1], opening a thread *always* result in a bus subscription being issued (the channel is added to the bus channels as a string). This is not required: bus subscriptions are based on user's channels (see `ir_websocket@_build_bus_channel_list`). When a new channel is added, the client subscribes again (see `toggleBusSubscription`).

Channels should only be added explictly when a channel the user is not a member of is opened. This addition causes a race condition between `toggleBusSubscription` and the explicit addition of the channel, resulting in a non deterministic behavior.

This PR fixes this issue: channel is only added when required, which is not the case in this test thus solving the issue.

fixes runbot-106895

[1]: https://github.com/odoo/odoo/pull/174473

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

Ensure unique line IDs when the same country appears in both sales and purchase sections of the OSS report. Steps to reproduce: - Create a Belgium company - Install OSS Reports - Update OSS Fiscal Position (Refresh tax mapping in settings) - Duplicate an OSS tax (e.g., 20.0% FR VAT) - Change its type to Purchase - Add it to the FR fiscal position - Create an invoice with a tax 20% FR VAT (Sales) - Create a bill with a tax 20% FR VAT (Purchase) - Try to open OSS Sales report in tax re

Ensure unique line IDs when the same country appears in both sales and purchase sections of the OSS report.

Steps to reproduce:
- Create a Belgium company
- Install OSS Reports
- Update OSS Fiscal Position (Refresh tax mapping in settings)
- Duplicate an OSS tax (e.g., 20.0% FR VAT)
- Change its type to Purchase
- Add it to the FR fiscal position
- Create an invoice with a tax 20% FR VAT (Sales)
- Create a bill with a tax 20% FR VAT (Purchase)
- Try to open OSS Sales report in tax return
- An error occurs due to duplicate line IDs

Issue originates from `append_country_and_taxes_lines`, which appends a new line with incorrect markup (using new line markup instead of the last line markup).

opw-4629989

Forward-Port-Of: odoo/enterprise#81641

Current behaviour: --- Mexican phone numbers are not managed correctly following the 2019 changes in Mexico. (Removing a 1 in phone numbers) Cause of the issue: --- The phonenumbers library removing support of mexican phone numbers starting with 1 in 8.13.38 The Whatsapp API still using the mexican phone numbers starting with 1 Fixes: --- See community commit Adding extra tests in test_whatsapp Similar to: https://github.com/odoo/enterprise/commit/a35a039e5fba569cd379b23d37ce512b

Current behaviour:
---
Mexican phone numbers are not managed correctly following the 2019 changes in Mexico.
(Removing a 1 in phone numbers)

Cause of the issue:
---
The phonenumbers library removing support of mexican phone numbers starting with 1 in 8.13.38
The Whatsapp API still using the mexican phone numbers starting with 1

Fixes:
---
See community commit
Adding extra tests in test_whatsapp
Similar to: https://github.com/odoo/enterprise/commit/a35a039e5fba569cd379b23d37ce512b5a23f7e2

opw-4473528

Forward-Port-Of: odoo/enterprise#79416

Steps to reproduce ================== - Install hr_timesheets - Go to Timesheets > All Timesheets - Use the week scale - Scroll to the bottom => Take note of the last record (e.g.: Walter Horton) - Now use a mobile viewport - Make sure the week scale is still applied - Scroll to the bottom => The last record is not the same one as the desktop view Cause of the issue ================== The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at th

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

- Install hr_timesheets
- Go to Timesheets > All Timesheets
- Use the week scale
- Scroll to the bottom => Take note of the last record (e.g.: Walter Horton)
- Now use a mobile viewport
- Make sure the week scale is still applied
- Scroll to the bottom => The last record is not the same one as the desktop view

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

The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at the same time. For this to work, we need a consistent row height.

On mobile, when grouping by x amount of fields, they are stacked on top of each other. When grouping by more than 2 fields, there wasn't enough space to display them all.

![image](https://github.com/user-attachments/assets/08f604e3-ae3e-4a73-86d9-41bd4dbfaf9a)

The `grid-template-rows` was set to auto on mobile in order to accomodate that case.

Using auto means we no longer have a consistent row height.

Solution
========

We restore the `gridTemplateRows` and allocate extra space when needed.

![image](https://github.com/user-attachments/assets/5254d7a6-0e32-4321-8e46-abcf0609dcaa)


opw-4208357

Forward-Port-Of: odoo/enterprise#80476

To reproduce the issue: 1) Install l10n_es_reports 2) Configure the taxes WHI 15% and IVA 21% purchase taxes to include analytic (checkbox on the form view) 3) Create an invoice with two lines of 100€, so that - both lines use both IVA21% and WHI 1% taxes - one of those lines defines an anlaytic distribution while the other doesn't 4) Open the generic tax report, and generate the VAT Record Books XLSX export ===> In that file, the amount of withholding is 15€. It should be 30€

To reproduce the issue:

1) Install l10n_es_reports
2) Configure the taxes WHI 15% and IVA 21% purchase taxes to include analytic (checkbox on the form view)
3) Create an invoice with two lines of 100€, so that
    - both lines use both IVA21% and WHI 1% taxes
    - one of those lines defines an anlaytic distribution while the other doesn't
4) Open the generic tax report, and generate the VAT Record Books XLSX export

===> In that file, the amount of withholding is 15€. It should be 30€.

The same issue can be reproduced for surcharge taxes, in the same way.

This is due to the fact different analytic distributions between base lines will trigger the creation of different tax lines for the same tax (one for each distribution). The code handling the export "saw" both lines, but ovewrote the total instead of summing all the values.

opw-4471253

Forward-Port-Of: odoo/enterprise#81375

**Problem**: When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration. Ad

**Problem**:
When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration.

Additionally, there is another issue related to live synchronization in version 18.0. When clicking the "Order" button, the request is sent only if the file is linked to a preparation display see here https://github.com/odoo/enterprise/blob/18.0/pos_preparation_display/static/src/override/point_of_sale/pos_store.js#L37.

As a result, if the display is linked to an archived POS config, live synchronization will not function correctly.

- How to reproduce:
    * Assign one pos config to preparation display
    * Archive the assigned config
    * Open another pos config.
    * Kitchen display is not loaded

**Solution**:
Change the domain to include displays with no configs, or with no active config.

opw-4504623

Forward-Port-Of: odoo/enterprise#80117

### Issue: The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast. ### Steps to reproduce: - Create a storable product that can be rented put 100 units in stock. - Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week. - Create a rental order for 5 units of that product for a period ulterior to the deliv

### Issue:

The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast.

### Steps to reproduce:

- Create a storable product that can be rented put 100 units in stock.
- Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week.
- Create a rental order for 5 units of that product for a period ulterior to the delivery.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The forcasted quantity of a rental order line is based on the `qty_available` of the product:
https://github.com/odoo/enterprise/blob/01b6a70348ffa11a9ead2558571b1ccfa1dd3cbb/sale_stock_renting/models/sale_order_line.py#L115-L129 https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L31-L43 However, this quantity does not take the incoming and outgoing moves that are planned to happend prior or during the location. In case the renting period starts at an ultarior date than today, it should rather be based on the `virtual_available` quantity of the product:
https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L44-L55 (note that since we need to take into account each of the incoming and outgoing moves that could happen prior to the location, the `from_date` context key needs to be set to today).

opw-4552760

Forward-Port-Of: odoo/enterprise#81127