Previously, when no EDI proxy user existed, in some case when the handle_demo ran, it was erronously deducing that the EDI mode was not demo, while it was. This commit fixes and simplifies the deduction of the EDI mode: We check the company in the env, if there is a related Peppol proxy user we take his mode, else we fallback on the dedicated system parameter. task-no Forward-Port-Of: odoo/odoo#190077

Previously, when no EDI proxy user existed, in some case when the handle_demo ran, it was erronously deducing that the EDI mode was not demo, while it was. This commit fixes and simplifies the deduction of the EDI mode: We check the company in the env, if there is a related Peppol proxy user we take his mode, else we fallback on the dedicated system parameter.

task-no

Forward-Port-Of: odoo/odoo#190077

Description of the issue/feature this PR addresses: - The last update on Mexican banks was five years ago. Since then, several new banks have emerged, while others have closed. Current behavior before PR: - 3 banks in our data no longer exist in real life. - 3 banks have outdated names. - 15 new banks aren't included, since they emerged after our bank data was updated. Desired behavior after PR is merged: - To align the bank list with those specified by the SAT (_Servicio de Administr

Description of the issue/feature this PR addresses:
- The last update on Mexican banks was five years ago. Since then, several new banks have emerged, while others have closed.

Current behavior before PR:
- 3 banks in our data no longer exist in real life.
- 3 banks have outdated names.
- 15 new banks aren't included, since they emerged after our bank data was updated.

Desired behavior after PR is merged:
- To align the bank list with those specified by the SAT (_Servicio de Administración Tributaria_, Mexico's highest tax authority responsible for tax collection), you can refer to their [official documentation](http://omawww.sat.gob.mx/fichas_tematicas/buzon_tributario/Documents/catalogo_bancos.pdf).

opw-[4327242](https://www.odoo.com/odoo/project.task/project.task/4327242)

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

Forward-Port-Of: odoo/odoo#189387

### Current behavior before PR: While working on this https://github.com/odoo/enterprise/pull/74813/commits/337ea18baebdf4c896bc3e503448207fd9095991 we were overriding a method in VariantMixin but it was shadowed and not executed this was happening because of the order JS is loading the files when importing website_sale. ### Desired behavior after PR is merged: After discussing with XBO, we are removing the import of website_sale from variant_mixin.js and moving the overridden method to web

### Current behavior before PR:
While working on this https://github.com/odoo/enterprise/pull/74813/commits/337ea18baebdf4c896bc3e503448207fd9095991 we were overriding a method in VariantMixin but it was shadowed and not executed this was happening because of the order JS is loading the files when importing website_sale.

### Desired behavior after PR is merged:
After discussing with XBO, we are removing the import of website_sale from variant_mixin.js and moving the overridden method to website_sale.js to avoid having this problem in the future.

Forward-Port-Of: odoo/odoo#189038

--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190489

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

Forward-Port-Of: odoo/odoo#190489

When creating a supplier invoice for a provider of type "2nd category voucher issuer," the system incorrectly defaults the document type to 56 (Electronic Debit Note) instead of 71 (Electronic Fee Receipt). This results in additional manual corrections and risks errors if the document type is not updated before confirmation. This fix ensures the system automatically selects document type 71 for providers of this category, streamlining the process and reducing error potential. opw-4217228

When creating a supplier invoice for a provider of type "2nd category voucher issuer," the system incorrectly defaults the document type to 56 (Electronic Debit Note) instead of 71 (Electronic Fee Receipt). This results in additional manual corrections and risks errors if the document type is not updated before confirmation.

This fix ensures the system automatically selects document type 71 for providers of this category, streamlining the process and reducing error potential.

opw-4217228




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

Forward-Port-Of: odoo/odoo#188166

### Steps to reproduce: - Install "l10n_hu_edi" and switch to a Hungarian company - Create an invoice - Click "Send & Print", uncheck "NAV 3.0" and send it - Repeat step 3 - Error ### Cause: With l10n_hu_edi, Odoo is supposed to regenerate the invoices at each Send&Print. The way it was done is by overriding `_need_invoice_document` to not check anymore if `invoice.invoice_pdf_report_id` is empty. As the function `_prepare_invoice_pdf_report` from `account` is called when `_need_invoice

### Steps to reproduce:
- Install "l10n_hu_edi" and switch to a Hungarian company
- Create an invoice
- Click "Send & Print", uncheck "NAV 3.0" and send it
- Repeat step 3
- Error

### Cause:
With l10n_hu_edi, Odoo is supposed to regenerate the invoices at each Send&Print. The way it was done is by overriding `_need_invoice_document` to not check anymore if `invoice.invoice_pdf_report_id` is empty. As the function `_prepare_invoice_pdf_report` from `account` is called when `_need_invoice_document` returns True, it is always called. But this function checks again if `invoice.invoice_pdf_report_id` is empty (https://github.com/odoo/odoo/blob/17.0/addons/account/wizard/account_move_send.py#L394-L395). So `invoice_data` doesn't have the key 'pdf_attachment_values' and it crashes at this line: 
`pdf_values = invoice_data.get('pdf_attachment_values') or invoice_data['proforma_pdf_attachment_values']` 
because it tries reading 'proforma_pdf_attachment_values' but the key is not there either.

### Solution:
Extend `_prepare_invoice_pdf_report` to remove `invoice.invoice_pdf_report_id`.

opw-4363559

Forward-Port-Of: odoo/odoo#189442

When loading the Profit and Loss report with multiple analytic filters, loading times can be very slow on larger databases. Analytic filtering necessitates the creation of a temporary table which is used to merge the account_move_line and account_analytic_line tables. This process takes an enormous amount of time on large databases and is unnecessary. Since this table is created whenever the analytic filters are changed (it is dropped on commit), it is much faster to only copy the relevant lines

When loading the Profit and Loss report with multiple analytic filters, loading times can be very slow on larger databases. Analytic filtering necessitates the creation of a temporary table which is used to merge the account_move_line and account_analytic_line tables. This process takes an enormous amount of time on large databases and is unnecessary. Since this table is created whenever the analytic filters are changed (it is dropped on commit), it is much faster to only copy the relevant lines into the new table. This PR adds logic to identify the relevant analytic accounts for the given query, and changes the table-making query to only copy lines with the relevant analytic accounts attached to them.

Performance Benchmarks Pre:
| 100,000 lines | 250,000 lines| 500,000 lines|
|--------|--------|--------|
| 5.2s | 10.77s | 110s |
| 4.86s | 11.43s | 110s |
| 5.16s | 12.2s | 115s |

Performance Benchmarks Post:
| 100,000 lines | 250,000 lines | 500,000 lines |
|--------|--------|--------|
| 1.56s | 3.19s | 6.22s |
| 2.65s | 6.03s | 11.58s |
| 3.74s | 8.36s | 16.36s | 

OPW-4300365

Forward-Port-Of: odoo/enterprise#73769

### Issue: With commit odoo/enterprise@8a3e03841ac6e609a9fe882c10e547bd039d7fcc, changes were made in `_get_post_fix_tax_amounts_map` to cover more cases and fix cases that broke because of it. In 17.2, with similar code to the fix having no rounding, the tax and base amount are not rounded. This resulted in an issue for cases with multiple taxes, see test case in 18.0: `8% tax` with an amount of `1.196` and `16% tax` with an amount of `1.677`. Addition of both tax amounts is `2.873`, rou

### Issue:

With commit odoo/enterprise@8a3e03841ac6e609a9fe882c10e547bd039d7fcc, changes were made in `_get_post_fix_tax_amounts_map` to cover more cases and fix cases that broke because of it.
In 17.2, with similar code to the fix having no rounding, the tax and base amount are not rounded.
This resulted in an issue for cases with multiple taxes, see test case in 18.0:
`8% tax` with an amount of `1.196` and `16% tax` with an amount of `1.677`.
Addition of both tax amounts is `2.873`, rounded to `2.87`, but amounts are rounded separately to `1.20` and `1.68`, the sum of which is `2.88`.

In 17.0, where base and tax are rounded before being returned, there is no issue with multiple taxes.

### Fix:

In the same commit, total calculation was moved to the end of `_get_global_invoice_cfdi_values`, using subtotal and taxes totals after they were calculated. This allows for the calculation of `TotalImpuestosTrasladados` using rounded tax groups totals.

opw-4050778

Forward-Port-Of: odoo/enterprise#75370

Some users need to make invoices with 100% discount lines. If they try then will receive this UCFE error that does not let us to validate the invoice in DGI . > ERROR: CODE 31: Error: El contenido del elemento 'Item' en espacio de nombres 'http://cfe.dgi.gub.uy' está incompleto. Lista esperada de elementos posibles: 'SubDescuento, RecargoPct, RecargoMnt, SubRecargo, RetencPercep, MontoItem' en espacio de nombres 'http://cfe.dgi.gub.uy'.  In order to make it work we need to adapt the module

Some users need to make invoices with 100% discount lines. If they try then will receive this UCFE error that does not let us to validate the invoice in DGI .

> ERROR: CODE 31: Error: El contenido del elemento 'Item' en espacio de nombres 'http://cfe.dgi.gub.uy' está incompleto. Lista esperada de elementos posibles: 'SubDescuento, RecargoPct, RecargoMnt, SubRecargo, RetencPercep, MontoItem' en espacio de nombres 'http://cfe.dgi.gub.uy'. 

In order to make it work we need to adapt the module to accept this kind of lines that actually represent an "Entrega Gratuita" (Indicator 5 in Uruguay)

- We check if the line is a 100% discount, if it is then we marked as Entrega Gratuita when we are creating XML (Indicator 5)
- Now that we can have lines and also invoices with total value 0.0 we need to adapt our XML because if value 0.0 then some tags were not added to the final XML - it was interpreted as False and the result was and invalid XML becasue we were missing a mandatory tag. Now we can tags that have 0.0 value to the final XML.
- Now that we can have lines 0.0 total amount, and also invoices 0.0 total amount, if we are using foreign currency then we need to avoid error computing the currency rate (division by zero). Now we detect this cases and use the date rate. Also, the rate is only been computed when actually we are going to use it.

LATAM 1296 / ADHOC Ticket 83295

Forward-Port-Of: odoo/enterprise#73956

This reverts commit 261181bd5ab84418d51310ba7bfa52061ffc893e. Shouldn't touch py files in this module and the change isn't neccesary in this case anyways since in the context of this error, customers will be in the config window. Hopefully they will be able to figure out the correct setting to switch to. Forward-Port-Of: odoo/enterprise#75363 Forward-Port-Of: odoo/enterprise#75113

This reverts commit 261181bd5ab84418d51310ba7bfa52061ffc893e.

Shouldn't touch py files in this module and the change isn't neccesary in this case anyways since in the context of this error, customers will be in the config window. Hopefully they will be able to figure out the correct setting to switch to.

Forward-Port-Of: odoo/enterprise#75363
Forward-Port-Of: odoo/enterprise#75113

Currently when receiving incoming calls, it's possible that all opened tabs will play the ringtone. To reduce the chaos, we now only play the incoming ringtone on the master tab. Task-4402909 Forward-Port-Of: odoo/enterprise#75534

Currently when receiving incoming calls, it's possible that all opened tabs will play the ringtone. To reduce the chaos, we now only play the incoming ringtone on the master tab.

Task-4402909

Forward-Port-Of: odoo/enterprise#75534

### Steps to reproduce: - Create a subscription product with two or more plans and two or more variants - Go to the product's page on eCommerce - Choose another plan than the default one - Add it to the cart - Notice the default plan is the one added to the cart ### Current behavior before PR: This is happening because if the product has variants the pricing select will get re-rendered before we get the selected plan_id https://github.com/odoo/odoo/blob/17.0/addons/website_sale/sta

### Steps to reproduce:
	- Create a subscription product with two or more plans and two or more variants
	- Go to the product's page on eCommerce
	- Choose another plan than the default one
	- Add it to the cart
	- Notice the default plan is the one added to the cart

### Current behavior before PR:
This is happening because if the product has variants the pricing select will get re-rendered before we get the selected plan_id https://github.com/odoo/odoo/blob/17.0/addons/website_sale/static/src/js/website_sale.js#L444:L456 so when getting the plan_id after this render of the <select> it will be the default plan.


**### Desired behavior after PR is merged:**
We are passing the selected plan_id to the call of get_combination_info so when re-render the <select> we will set the one that was selected as the default one.

opw-4296527

Forward-Port-Of: odoo/enterprise#74813