The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the BNB now provides rates against EUR.

This caused the error "Your main currency (EUR) is not supported by this exchange rate provider" when Bulgarian companies with EUR as their main currency tried to sync exchange rates.

refs:

We can compare the data here from 31 December using the WayBackMachine:
https://web.archive.org/web/20251231193558/https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm

Compared to today:
https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm

And see the comparison used to be to BGN but is now for EUR

Steps To Reproduce:
1. Create a company for Bulgaria with EUR as the main currency.
2. Go to Accounting Settings -> Automatic Currency Rates.
3. Select "[BG] Bulgaria National Bank" as the service provider.
4. Click the sync button.
5. Error appears: "Your main currency (EUR) is not supported by this exchange rate provider. Please choose another one."

The fix updates the base currency from BGN to EUR, matching the current BNB XML format which now provides rates against EUR.

Note: Companies with BGN as main currency will now get the same error, which is expected since the BNB no longer provides BGN-based rates. This behavior was discussed and confirmed with the PO.

Ticket [link](https://www.odoo.com/odoo/project.task/5483771)
opw-5483771

Forward-Port-Of: odoo/enterprise#105074

Error message
-----
```
FAIL: TestTourMrpOrder.test_mrp_multi_step_product_catalog_component_transfer
Traceback (most recent call last):
  File "/data/build/odoo/addons/mrp/tests/test_order.py", line 5433, in test_mrp_multi_step_product_catalog_component_transfer
    self.assertEqual(component_transfer.product_uom_qty, 2)
AssertionError: 1.0 != 2
```

Cause
-----
It looks like somehow one of the 2 clicks on the product is either not registered, or the update of the POL's quantity isn't triggered / doesn't happen fast enough, so the tour ends with a quantity of 1 for the product. I see 2 possible causes for this:

1. The product is visible in the initial view. So when the view updates (because of the filtering step), the next step - clicking on the product - the clicks can already be triggered, which might lead to an inconsistent state.
2. There is some synchronicity issue with the quantity update's debounce
https://github.com/odoo/odoo/blob/11292070870ef22663364eda5a4b243dea68856a/addons/product/static/src/product_catalog/kanban_record.js#L16-L18

Solution
-----
Add extra steps to wait for filtering to be applied. Also add extra steps to ensure correct update of the POL's quantity.

-----
Runbot error 237956

**PROBLEM**
1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model.
2. There is an issue with the cache of the field `l10n_mx_edi_global_invoice_sequence_id`. (this is why problem can sometimes resolves itself on restarting the odoo instance).

 **STEP TO REPRODUCE**
1. Create 1 invoice with CFDI to public checked.
2. Goes to the list view for invoices, select the invoice, and apply the action "create global invoice" to it.
4. A access error may appear (depending on cache value).

**CAUSE**
1. In `_get_global_invoice_cfdi_sequence()`, we get or create the ir.sequence used for global invoices. We are creating it with sudo(), so a user without sudo privilege can write to it. But, when we are retrieving a ir.sequence record that already exist, when don't use sudo(), this causes an access error for user without sudo privilege.
2. In `_get_global_invoice_cfdi_sequence()`, we try to get the computed field `l10n_mx_edi_global_invoice_sequence_id`. If it doesn't exist, we create a ir.sequence, but we forget to assign it to the field. Because we already trigger the compute method of the field by trying to access it, there is a None value in cache for it. This means we will always create a ir.sequence, despite one already existing for the company until the cache expires or the compute method is re-triggered.

opw-5472552

Forward-Port-Of: odoo/enterprise#104181