Steps to reproduce:
-------------------
1. Install l10n_au_hr_payroll.
2. Enable multi-company and switch to an AU company.
3. Change an existing employee’s company to the AU company
([employee created more than 28 days ago](https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/l10n_au_hr_payroll/data/hr_payroll_dashboard_warning_data.xml#L31)).
4. Under the payroll tab, set the TFN Status to:
"Employee applied for TFN but didn't receive it yet, less than 28 days ago".
5. Open Payroll.

Issue:
--------
A traceback occurred:
```
Error: NameError("name 'invalid_employees' is not defined")
```
Cause:
------
The evaluation code computes `warning_count` using
an undefined `invalid_employees` variable.

Solution:
---------
Define `invalid_employees` before using it to compute
`warning_count` and `warning_records`.

**NOTE:**
The [upgrade script](https://github.com/odoo/upgrade/blob/ed5bc3fd99ef6fba4bc7162934df36396ae9fc3f/migrations/l10n_au_hr_payroll/saas~18.4.1.0/end-migrate.py#L30) is already available from version 18 to 19.

opw-5459998

Forward-Port-Of: odoo/enterprise#103777

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

**Steps to reproduce:**
- Go to Appointment app
- Edit an appointment type
- Ensure its availability is on resources
- Set duration to 1 hour
- Add a schedule slot ending in 00:00
- Save and go to the website page of the appointment
- Last slot is not showing (23:00-00:00)

**Issue:**
When computing the appointment slots of a resource using time range,
the end of day is considered as an unavaibility resource slot with this interval
in `_get_unavailable_intervals`:
`i_start = 23:59:59.999999` `i_stop = 00:00`
this conflicts with the given range (23:00-00:00)
in `self._slot_availability_is_resource_available`

It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)`
is converted to `time.max` (23:59:59.999999) by:
`day_to = datetime.combine(day, float_to_time(attendance.hour_to))`
This introduces the microsecond unavaibility at the end of the day, which
blocks the booking.

(it's working properly for availability on users appointments)

**Fix:**
Changed the condition so that 23:59:59.999999 is considered as equal to 00:00.

opw-5163892

Forward-Port-Of: odoo/enterprise#104927
Forward-Port-Of: odoo/enterprise#100853

The aim of this commit is to make the automatic reconciliation works in
case of an obvious matching that was prevented because the reference of
the invoice was also it's payment reference.

It also modify a docstring of a test because it was lying about what it
was really testing. The usecase it says it forbid is actually enforced
by `test_matching_algorithm_for_multiple_invoices`.

### Before this commit:
- functionally:
  The obvious matching was denied and the accountant had to manually
  make the match.

- technically:
  The `aml.ref` and the `move.payment_reference` were the exact same and
  thus postgres regrouped the invoice (through aml) with itself as if
  there were 2 invoices matching the same word.

### After this commit:
- functionally:
  The obvious match is made.

- technically:
  The initial intend was to avoid having several invoices
  (proxy by amls) reported for a specific matching word preventing the
  system to take a difficult and arbitrary functional decision which
  might be wrong.
  In order to comply with that and to not block the match of an invoice
  that would be matched through several matching words, we don't gather
  twice the same aml for the same word.

task-id: None (The issue arose on odoo.com and was brought by APFA)

**Issue**
Users without 'Admin' Sign rights could in some cases not access the sample template.

**Steps to reproduce**
1. Go to 'Templates' and archive the existing one in order to have the 'Try our sample document' shown and click on it.
2. Add some sign items to the template, and send it for a signature request.
3. With an user having only 'User: Own Templates' Sign rights, go to 'Templates' and click 'Try our sample document'.

Access Error:
Blame the following rules:
- sign.item: group_sign_user: Create and manage template items

**Cause**
When the template has an associated sign request, it is copied.
The problem is that the user currently doesn't have enough rights
to create sign items for the copied template:
https://github.com/odoo/enterprise/blob/2e8fb2ca274a0cf15d7b78a663bffe9cbb700153/sign/security/security.xml#L92-L101

**Change**
Change the `user_id` of the new template to allow creating the sign items for it.

opw-5254566

Forward-Port-Of: odoo/enterprise#102227

**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