An error occurs when confirming a purchase order linked to multiple sales orders.

Steps to reproduce:
1) Install sale_stock & sale_management and enable dropshipping. 
2) Create a vendor with group_rfq 'always'.
3) Create a product with dropship route and add that vendor.
4) Create a Quotation with that product, confirm it, duplicate and confirm.
5) From the magic button go to Purchase Orders and confirm the PO.

Reference video for steps : https://drive.google.com/file/d/1xglkuZAWNxcz0WSj_49Hemjkxx4KjSqv/view?usp=sharing

Error:
`ValueError: Wrong value for stock.picking.sale_id: sale.order(26, 27)`

Root Cause:
The computed field `sale_id` receives multiple `sale.order` records from `move_ids.sale_line_id.order_id` (see [1]). Since `sale_id` is a Many2one field, it can only accept one record or False. Assigning multiple records causes the error.

Fix:
* Create only one sale order per purchase order for drop-shipping picking types.
  For existing databases, set the value to the first available sale_id, or False
  if none exists.

[1]- https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/sale_stock/models/stock.py#L175-L179

opw-5344535

Forward-Port-Of: odoo/odoo#237945

Currently, an error occurs when a user creates an inherited view.

**Steps to Reproduce:**
  - Go to `Settings > Technical > User Interface > Views`.
 - Create a new view by entering `name` and selecting any `inherited view`.
 - In the `Architecture`, enter the below code:
```
        <xpath position="replace">
            <field name="name"/>
        </xpath>
```
 - Now save the view.

`TypeError: Argument must be bytes or unicode, got 'NoneType'`

Cause:

As we can see, when the user enters an xpath without the expr attribute, and when it goes to find the inherited node [1]. Since the expr is missing, its value becomes None [2]. Passing this None as an argument [3] causes the error.

This commit ensures that when a user creates or edits a view with an xpath that is missing the expr attribute, a ValidationError is raised indicating that the expr attribute is missing in the XPath.

[1]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L145

[2]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L76

[3]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L78

[4]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/addons/base/models/ir_ui_view.py#L377-L384

sentry-7161414430


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

Forward-Port-Of: odoo/odoo#242203

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

When a leave is linked to a refused allocation and
the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs.

Steps to reproduce the error:
- Install ``hr_holidays`` without demo data
- Create a new Time Off Type > Time Off Requests, Approval: No Validation >
  Allow Negative Cap: True > Maximum Excess Amount: 2
- Create an Accrual Plan using default values
- Create a New Allocation
     - Allocation Type: Accrual Allocation
     - Set the Time Off Type and Accrual Plan created above
     - Allocation: 1 day > Approve
- Create a new Time Off in the near future (in the current month) and select the Time Off Type created above
- Go back to the Allocation > Refuse
- Run the cron ``Time Off: Cancel invalid leaves``

Traceback:
``IndexError: list index out of range``

https://github.com/odoo/odoo/blob/bc5f24195a486112574900015ecbcf0e3ba32145/addons/hr_holidays/models/hr_leave.py#L1535-L1536
Here, ``leave_type_data`` becomes ``defaultdict(<class 'list'>, {})``
because when the allocation is refused and the cron runs,
the ``get_allocation_data`` method returns an empty defaultdict.
As a result, accessing the index leads to the above traceback.

sentry-6874651972

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

Forward-Port-Of: odoo/odoo#243505
Forward-Port-Of: odoo/odoo#227201

## Issue
When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere.

## Steps to reproduce
1. Install the *Barcode* app (`stock_barcode`)
2. In the *Barcode* app, click *Count Inventory*
3. Add a product and set a quantity for it
4. Click *Confirm* (do not scan to confirm)
5. Write an *Inventory Reason* and click *Apply Now*
6. Go to Inventory > Reporting > Moves History
    - **The _Inventory Reason_ given in step 5 does not appear anywhere**

If the inventory adjustment is done through Inventory > Operations > Physical Inventory, the user can also provide an *Inventory Reason*, but this time, it will appear in the *Moves History* in the *Reference* (`stock.move.line.reference`) column.

## Cause
Since https://github.com/odoo/enterprise/commit/3efea75a88120519ef4be1a41c8faa7278bc332c, the value provided by the user is never passed to the Python side.

opw-5423934

Forward-Port-Of: odoo/enterprise#104763

**Commit 1:** 
[FIX] account_reports: translation of account returns states
Steps to reproduce:
 - Open the tax returns
 - Set an account opening date to generate some returns
 - Add another language to the database and select it

 -> The states of the returns (the little bubble in the
 kanban cards) aren't translated even though the translation
 is present in the pot and po files.

**Commit 2:**
[FIX] account_reports: translation of date in returns title
Steps to reproduce:
 - Have 2 languages on the db
 - Generate the tax returns by going to Accounting/Tax Returns and set the opening date
 - Switch to the second language

 -> The period displayed in the name of each return isn't translated

**Commit 3:**
[FIX] account_reports: translate account returns name after lang installation

Steps to reproduce:
 - Generate the tax returns by going to Accounting/Tax Returns and
   set the opening date
 - Install another language

 -> The names of the returns aren't translated in the new language.

Solution: When installing a new language, generates the translation
 of the title for all existing returns

task-5421659

Forward-Port-Of: odoo/enterprise#102559

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

## [FIX] website: add versioning for GallerySlider interaction
    
    The GallerySlider interaction (and its edit mode counterpart) is not up
    to date: the logic is still written for old snippets (before [9042b1c],
    so before 18.0).
    
    In the meantime, the pagination for the indicators was lost, meaning
    that if you add too many images, the indicators will have less and less
    space.
    
    Steps to reproduce:
    - Drop an Image Gallery snippet
    - Set the indicators to squared or rounded miniatures
    - Add 15 or more images
    => All the indicators are crammed into the same line.
    
    With this commit, we deprecate the old `GallerySlider` interaction and
    create a `GallerySlider001` for the snippets dropped since 18.0.
    For the indicators, instead of a pagination, we now use a horizontal
    scrolling container which centers on the active indicator.
    
[9042b1c]: https://github.com/odoo/odoo/commit/9042b1c 

## [FIX] website: preload available carousel images
    
    As images are lazy loaded, it means that in the context of a carousel or
    an image gallery, they only start loading once the user clicks either on
    its indicator or on the previous / next button (or after completing an
    auto-slide). While Chrome seems to optimize that to make it seemless, on
    Firefox this causes the carousel slide to appear blank for a moment
    before the image suddenly pops up, as the sliding animation arrives to
    its end.
    In effect, this causes a flicker and a feeling that the carousels, and
    especially the gallery, is extremely laggy.
    
    To mitigate that while trying to keep the advantages of image lazy
    loading, this commit partially backports [08d837e], which loads the
    images of the next and the previous carousel items.
    
    Additionally, we prefetch the target images on pointerdown / keydown on
    an indicator. That may seem like too small of a difference to be
    interesting, but it actually gives a little bit of time between the
    pointerdown and pointerup (which triggers the slide event) to start
    loading the images, which with a correct connexion already goes a long
    way towards mitigating the laggy feeling.
    
[08d837e]: https://github.com/odoo/odoo/commit/08d837e70f28a84a9bd97974f5d15d387a42b7c0
    
task-5245513

Forward-Port-Of: odoo/odoo#245144
Forward-Port-Of: odoo/odoo#232147

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

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

**Behavior:**
Behavior:
When logged in as a user with group_user access (member), trying to generate the next few serial numbers for a tracked product from receipts will cause an access error.

This happens because there is a write operation on the ir.sequence linked to the serial number at the end of the process that happens only when the 'New' button was previously pressed.
And since access rights to ir.sequence are dependant on the base group of the user, changing the user Inventory rights to admin will not resolve the issue.

A test has been created to ensure no access error is created when generating sequence numbers as a lower access user, this test would pass without the fix since it is focused on the python function.

**Steps to reproduce:**
- Create a product that is tracked by serial number
- Log in as a user with group_user access (member role)
- Go to Inventory -> Operations -> Receipts
- Create a new picking and add the product
- After clicking on Mark as Todo you'll see Details pop up in the product line
- After clicking Details, select Generate Serial/Lots
- Click New, then Generate, and you'll get an access error for ir.Sequence

opw-5368553

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

Before this PR:
During chart installation, the template sets `sgst_purchase_5` as the default purchase tax, which becomes the default supplier tax (supplier_taxes_id) for product_a. When creating the bill with partner_b, the [tax_map](https://github.com/odoo/odoo/blob/cade6bcf0d783a8b492f5e26afbd87f2a812303e/addons/account/models/partner.py#L47) field converts product_a.supplier_taxes_id to tax_purchase_b. Since tax_purchase_b is not referenced in account_fiscal_position_tax, unlink() succeeds.

After this PR:
Due to changes in this [PR](https://github.com/odoo/odoo/pull/242030), the template no longer sets default purchase tax. Test common.py runs before default taxes are set by `_inverse_l10n_in_is_gst_registered`, so tax_purchase_b becomes NULL. Later, when default taxes are set, product_a gets supplier_taxes_id = sgst_purchase_5. When creating the bill, it directly uses sgst_purchase_5, which is referenced in account_fiscal_position_tax. Attempting unlink() on sgst_purchase_5 causes a foreign key violation.

task-5456351

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

`*` = `l10n_xx_hr_payroll`, `hr_holidays_fleet`, `hr_contract_salary_payroll`, `hr_payroll_account_iso20022`

- renamed `hr.payroll.dashboard.warning` to `hr.payroll.warning`
    - changed every occurrences of `hr.payroll.dashboard.warning` to `hr.payroll.warning` in data records and references.
- removed specified warnings
    - removed specified warnings from `hr_payroll` and `hr_payroll_fleet`
- removed unused dashboard components
    - removed all the other dashboard components apart from the warning one, and removed their methods from `hr_payslip` and related tour and tests from `test_dasboard`
- reworked dashboard
    - added a mandatory onboarding process to obtain payrun related data
    - reworked Dashboard UI to show warnings with their deadlines
    - added some fields on `hr.payroll.warning` to compute warning deadline
    - added email alerts when warning overdue
    - now, user can choose from Python Code or Domain while creating a warning
    - also added new warnings

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

### Adjust tab entry layout
Prior to this PR, extra icons in recent entries could be truncated depending on the subtitle length.
This commit adapts the entry layout to ensure that extra icons are always fully visible.

This PR also moves the "Go to Call" and "Go to Activity" buttons into the "Go to" dropdown for a more predictable user experience.

### Adapt call suggestion separator
This PR updates the call suggestion separator to improve readability.

---

task-5413528

---

### Avoid extra icons truncation
| Before | After |
|--------|--------|
| <img width="367" height="63" alt="Capture d’écran 2026-01-16 à 12 04 26" src="https://github.com/user-attachments/assets/ec117119-7d90-4de0-87e2-c2bd5d8e3eab" /> | <img width="362" height="61" alt="Capture d’écran 2026-01-16 à 12 06 30" src="https://github.com/user-attachments/assets/caef103b-e324-4ed0-a180-22271f3efa0d" /> |

### Move Go to button
| Before | After |
|--------|--------|
| <img width="367" height="63" alt="Capture d’écran 2026-01-16 à 12 04 26" src="https://github.com/user-attachments/assets/ec117119-7d90-4de0-87e2-c2bd5d8e3eab" /> | <img width="364" height="380" alt="Capture d’écran 2026-01-16 à 12 07 50" src="https://github.com/user-attachments/assets/3ae631d0-0315-445f-b6f8-1d2ba2306d6d" /> |

### Adapt call suggestion separator
| Before | After |
|--------|--------|
| <img width="377" height="145" alt="Capture d’écran 2026-01-16 à 12 08 53" src="https://github.com/user-attachments/assets/0d92689f-31d7-40c1-9e98-23e894dbe94e" /> | <img width="379" height="133" alt="Capture d’écran 2026-01-16 à 12 09 06" src="https://github.com/user-attachments/assets/95640f67-0c15-4142-ae4d-c98e0ffaa093" /> |

[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export

Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data.

Steps to reproduce:
- Install `l10n_ma_reports` and switch to the MA company
- Create and confirm a bill:
	Bill Date: 10/01/2025
	Vendor: Azure Interior
	Invoice Lines: Price 100, Taxes 20% (S 140)
- Go to `Bank Reconciliation`
- Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo)
- Select the transaction and the invoice, then click Validate
- Open the Tax Return for November.
	Section D should show data linked to the created invoice
- Export the XML using the Gear → XML
	The created bill is missing in the XML and others may be present, showing inconsistent data

opw-5002779


[IMP] l10n_ma_reports: call the report to compute the prorata value

Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file.

Forward-Port-Of: odoo/enterprise#105106
Forward-Port-Of: odoo/enterprise#104619

### Issue:
The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders
This leads to fiscal inconsistencies, especially when invoices use the `PUE` payment policy, where this payment method is invalid

### Cause:
In the `_compute_l10n_mx_edi_payment_method_id` methods, the default value was always set to `Por Definir`

### Fix:
After discussion with the PO (MIAL), the chosen solution is to archive the payment method `99 – Por Definir`and remove it as a default value
All valid cases should already be handled explicitly, making it clear to the user that something is missing when the data is blank

### Steps to reproduce:
- Install `l10n_mx_edi` and switch to the MX company
- Create an invoice with today’s invoice date
- The payment policy is set to PUE
- Before the fix, the payment method is set to `Por Definir`

For Sale Order and POS Order tests, it's the default value as soon as you create an order

opw-5406038

Forward-Port-Of: odoo/enterprise#105344
Forward-Port-Of: odoo/enterprise#104164

1. Set "My US Company" state to California,
2. Go to Employees > Employees > Contract Templates,
3. Click New,
4. Fill in a name and save,
5. Invalid Operation: "The employee state filing status is empty..."

A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules.

This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee.

We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee.

The constraint will now only raise when loading a contract template on the employee or editing the field through the employee.

[1] odoo/enterprise#83136

opw-5458566

Forward-Port-Of: odoo/enterprise#104990

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

`force_create` must be `True` because there are fiscal positions being created that assume the existence of some Dutch accounts. If these accounts don't exist, the ORM will attempt to create fiscal positions with `NULL` values in columns that require `NOT NULL`.

I am still looking into why the fiscal positions are created, while accounts aren't, but I found that setting `force_create=True` solves the problem. Given the argumentation behind having it set to `False`:

> The goal is that we do not need to be more accurate on what we need to update when updating the CoA
(https://github.com/odoo/odoo/commit/a3c57b4f0198236b04486d336d56b25de74677b8)

I believe we can safely set it `True` in order to unblock numerous failing upgrades, for now.

Moreover, I suspect that further investigation into this issue will show that we shouldn't be setting `force_create=False`, ever, therefore rendering the newly introduced argument redundant.

Example traceback from [upg-2736856](https://upgrade.odoo.com/web#id=2736856&cids=1&model=upgrade.request&view_type=form&menu_id=107):
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1321, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-13>", line 2, in new
  File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 127, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 515, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 254, in migrate_module
    mod.migrate(self.cr, installed_version)
  File "/home/odoo/src/odoo/18.0/addons/l10n_nl/migrations/3.4/end-migrate.py", line 7, in migrate
    env['account.chart.template'].try_loading('nl', company, force_create=False)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 160, in try_loading
    return self._load(template_code, company, install_demo, force_create)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 227, in _load
    self._load_data(data)
  File "/tmp/tmpw4wedv5j/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 653, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals, ignore_duplicates=ignore_duplicates)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5489, in _load_records
    data['record']._load_records_write(data['values'])
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5407, in _load_records_write
    self.write(values)
  File "/home/odoo/src/odoo/18.0/addons/base_vat/models/account_fiscal_position.py", line 19, in write
    return super().write(vals)
  File "/home/odoo/src/odoo/18.0/addons/account/models/partner.py", line 196, in write
    return super(AccountFiscalPosition, self).write(vals)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4794, in write
    field.write(self, value)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 4508, in write
    self.write_batch([(records, value)])
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 4529, in write_batch
    self.write_real(records_commands_list, create)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 4725, in write_real
    flush()
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 4680, in flush
    comodel.create(to_create)
  File "<decorator-gen-120>", line 2, in create
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 496, in _model_create_multi
    return create(self, arg)
  File "/tmp/tmpw4wedv5j/migrations/util/orm.py", line 248, in wrapper
    return f(*args, **kwargs)
  File "/tmp/tmpw4wedv5j/migrations/base/0.0.0/pre-models-match_uniq.py", line 25, in create
    return super().create(vals_list)
  File "<decorator-gen-31>", line 2, in create
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 496, in _model_create_multi
    return create(self, arg)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5020, in create
    records = self._create(data_list)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5204, in _create
    cr.execute(SQL(
  File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 354, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "account_src_id" of relation "account_fiscal_position_account" violates not-null constraint
DETAIL:  Failing row contains (16, 4, 1, null, null, 1, 1, 2025-04-07 06:42:17.6166, 2025-04-07 06:42:17.6166).
```

Description of the issue/feature this PR addresses:
This issue occured because in the previous update we add a condition to restrict multiple tax groups excluding the STLG.
Apparently there is a case where some users create their own tax groups (for example for PPH) so when they want to print an efaktur it will raise an error.

Current behavior before PR:
If a user create their own tax with a new tax group (outside of the 6 groups defined in `l10n_id`) and use it in invoice line along with one of the 6 tax groups excluding the STLG then it will blocked the print efaktur because it will raise an error  

Desired behavior after PR is merged:
- The restriction in tax groups only applied for the 6 tax groups in l10n_id so if an invoice line
  has multiple tax groups as long as there no more than one of the 6 tax groups excluding the STLG then
  it should be able to print the efaktur.
- Also when building the efaktur coretax value, the new tax group should not be included in the regular_tax
  variable which will cause the value to be 11/12 of the original value.
- Add new condition to block the print efaktur if there is a tax inside the invoice but none of it
  belong to the 6 ppn tax groups (there is already a condition to block if no tax is given, but now since there
  are cases where they use tax group outside of the defined tax groups then it will print the efaktur)
- If an invoice line does not have any ppn_tax_groups but there are other line in the same invoice
  that has it then it will still be able to print the efaktur, but the line without the ppn tax will
  have the OtherTaxBase and VATRate set to zero which will calculate the VAT as 0 too.

[5434656](https://www.odoo.com/odoo/project.task/5434656)


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

Forward-Port-Of: odoo/odoo#241979

**Step to reproduce:**
1. Install `sale_management`
2. Open any email template (e.g., Sale: Order Confirmation).
3. Add an attachment to it
4. Create a Sale Order, confirm it, and click "Send by Email".
5. In the mail composer, remove the template attachment

**Issue:**
- The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails.

**Cause:**
- The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment.

**Solution:**
1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server.
2. In `onFileRemove`, check the `res_model` of the attachment.
3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink)
   and only remove it from the composer view.

opw-5163679

Steps:
- Install `pos_restaurant_loyalty`
- Create a discount for example: if 2 coca -> 10%
- Open a restaurant session
- Open another restaurant session with the same user in incognito
- Add 2 coca + sushi in session 1 and press "Order"
- In session 2 products are automatically added, in live
- Try to validate the order from session 2
- Traceback

Traceback is due to the fact that, in order to synchronize, session 1 must send data to the server, which in turn sends further data to all sessions.

The problem is that as coupons are only created once the order has been validated, they are not yet “really created” on the customer side. To avoid sending “invalid” records, we remove them from the data via an override of the `serialize` method in `Base`.

But since python doesn't receive coupons, it can't send coupons to other sessions, so if we try to pay with the session that didn't initially get the discount, it will cause a traceback.

The solution is to remove `is_reward_line` as well. Because it already makes no sense to have a `PosOrderLine` which is a reward line without a coupon, and then because it will regenerate the discounts in the new session.

opw-4892767

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

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

Forward-Port-Of: odoo/enterprise#104479

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:
-------------------
1. Install hr_employee
2. Open Working Schedules and select any record
3. Enable the Start Date or End Date optional column
4. Set a start or end date on one of the working hours

Issue:
------
The "Average hours per day" value changes unexpectedly after setting a start or end date on an attendance line.

Cause:
------
The `_compute_hours_per_day` method relies on `_get_global_attendances`,
which excludes attendances having `date_from` or `date_to`.
https://github.com/odoo/odoo/blob/67e4cd087de179a7b06c23321cfc4e6d5aa2a9dd/addons/resource/models/resource_calendar.py#L165-L169

Solution:
---------
Compute the `hours_per_day` independently of attendance `date_from` or `date_to`
by including all attendances in the computation, ensuring a consistent and correct value.

**NOTE:**
The `date_from` and `date_to` fields are removed from version 19.0.
related commit: 77f860f

opw-5417724




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

**Description of the issue/feature this PR addresses:**  
The `CopyClipboardField` widget previously relied on the `string` attribute inside `attributes` to determine the text of copy button. In Odoo 17+, the `string` attribute is no longer inside `attributes` but defined outside, causing the widget to break. Additionally, using `string` for copy text caused confusion between the field label and the text to copy (`copyText`). The correct approach is to use widget options for defining `copyText`, as intended in the project share link. In the Payment Wizard button, the widget was inherited and `extractProps` was overridden to handle the `string` attribute manually, which is no longer necessary with the new approach.

**Current behavior before PR:**  
- `CopyClipboardField.extractProps` reads the removed `string` attribute from `attributes`.  
- The copy text could be confused with the field label (`string`).  
- Project share link usage fails to read copy text correctly because the widget does not read options.  
- `PaymentWizardCopyClipboardButtonField` overrides `extractProps` unnecessarily to fix copy text handling.

**Desired behavior after PR is merged:**  
- `CopyClipboardField` reads `copyText` from widget options, no longer relying on the removed `string` attribute.  
- Copy text is clearly separated from field labels.  
- Project share link now works correctly using the new `copyText` option.  
- `PaymentWizardCopyClipboardButtonField` no longer needs to override `extractProps` and copy text is set directly in field options  

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

Backport of https://github.com/odoo/enterprise/pull/101643.

Original commit message for completeness:

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