Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city).

**Steps to Reproduce:**
1. Install and configure the **Envia Shipping** module.
2. Create a partner without an address (only name + phone).
3. Create quotation for that partner with a deliverable product (e.g; Conference Chair).
4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**".

**Error:**
`TypeError - quote_from_bytes() expected bytes`

**Cause:**
At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised.

**Fix:**
This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2]

[1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593
[2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624

sentry-7063870478

Forward-Port-Of: odoo/enterprise#100734

Before this commit, when downgrading from 19.1 to 19.0 with chat hub data from 19.1, i.e. chat windows or bubbles that are open, loading web client would crash with following error:

```
KeyError: 'thread_model'
```

This happens because of mismatch of format of chat hub data in 19.0 and 19.1:

- 19.0 identifies channels with model "discuss.channel" and id
- 19.1 identifies channels with just id

When downgrading from 19.1 to 19.0, it attempts to getOrFetch a thread to server by providing channel id but without passing a model. The getOrFetch of 19.0 looks at thread level, so it cannot guess providing just id means a channel, therefore it crashes due to missing model to provide.

This commit fixes the issue by dropping the chathub local storage data if the format of chathub data in local storage is invalid, i.e. the identifying data of opened / closed should necessarily have id and model. If no model is provided like with downgrade from 19.1 to 19.0, then it drops local storage and assumes no chat window or bubbles is open.

Task-5223650

In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]

To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#101275
Forward-Port-Of: odoo/enterprise#99871

When importing a bank statements xlsx in a bank journal, the wizard would
not match the "Cumulative Balance", not even proposing it for manual setup.

Steps to reproduce:
- Go to the accounting dashboard
- On a bank journal tile, in the right corner menu "New > Import File"
- Upload a file (there is one attached to the ticket)
- Cumulative Balance is not matched

This commit adds module.init() that is skipped in the "onWillStart"
override (it's present in the parent onWillStart). This has for consequence
that the "bank_stmt_import" key is now present in the context when
get_fields_tree() from Base_ImportImport is called, allowing the addition
of missing field.
See https://github.com/odoo/enterprise/blob/19.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L18

This commit also adds a check to only add debit & credit in the added
field list if they are not actual field on the bst line model (see:
https://github.com/odoo/enterprise/commit/af863c5a53d0ab50fe67cb9ea910391d4a1979dd)
This commit also checks that those fields are only added when the model
is account bank statement line (only useful in this case).

opw-5222326

Calling Avatax without lines results in an error and blocks flows:

```
Odoo could not fetch the taxes related to MXXX - SOXXX/XXX.
Please check the status of `Sales Order XXX` in the AvaTax portal.
Transactions must have at least one line.
```

There are various cases this can happen:

1/ if `industry_fsm_stock` is installed, empty orders are confirmed [1],
2/ if you put the `end_date` of a subscription before the `next_invoice_date`,
   then none of the lines are considered invoiceable [2] and you get the
   error when viewing the subscription in the portal

This commit filters out orders without lines.

It's also possible to filter this on the level of the models by doing it in `_get_and_set_external_taxes_on_eligible_records()`. However, this means doing it separately for each model, and requires every implementer do it manually.

[1] https://github.com/odoo/enterprise/blob/703e7fd413e93a8287da98286aa93b9699ae3e96/industry_fsm_stock/models/project_task.py#L159
[2] https://github.com/odoo/enterprise/blob/c7bf4367a9bf6757a36a9f34a872a6e35a19a3a5/sale_subscription/models/sale_order_line.py#L475

opw-5214609
opw-5247727
opw-5311132
opw-5385960

Forward-Port-Of: odoo/enterprise#101643

**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).

**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line

**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').

opw-4948696

Forward-Port-Of: odoo/enterprise#95329