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

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

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

In **l10n_ec**, negative lines are not accepted in the XML.
They must be dispatched as discounts on positive lines.
The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased.

## Steps to reproduce

With **l10n_ec**:
1. Change the decimal accuracy to 6 digits.
2. Set the rounding method to *global rounding*.
3. Create an invoice with the following lines:

| Quantity | Price    | Taxes     |
|-----------|----------|-----------|
| 20        | 1.4235   | VAT 0% G  |
| 20        | 1.6425   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.4235   | VAT 0% G  |
| 6         | 3.747768 | VAT 15% G |
| 6         | 3.747768 | VAT 15% G |


In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`.

This happens due to rounding differences in how the `descuento` is computed in the
`common_details_info_template` from **l10n_ec_edi**:

format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount'])

where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere.

This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**.
Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed.

opw-5128612

Forward-Port-Of: odoo/enterprise#104659
Forward-Port-Of: odoo/enterprise#97337

Description of the issue/feature this PR addresses:
- A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode
- This is because the `applied_on` field is missing on the `product.pricelist.item` form view.

Current behavior before PR:
- Install `sale_management`
- Enable "Pricelist" setting
- Go to Sales - Products - Pricelists and create a new "Sample" Pricelist.
- Create 3 rules for the same product (template), one with price at 6666, a second one at 6667 and the last one at 3333 <img width="1416" height="649" alt="image" src="https://github.com/user-attachments/assets/1d50499e-cb49-4341-971c-5a2a5111b9ca" />
- Next step, edit 2 first rules for price 6666 and 6667 to set a variant **BUT before starting editing, open the form in expanded mode using two-arrows button** <img width="1416" height="889" alt="image" src="https://github.com/user-attachments/assets/056cb862-3dc6-4868-b6d3-a0917f3e7242" />
- Set the variant to the first price rule (as you can see, the rule name is immediately updated with "Variant: [REF] Product name" <img width="1421" height="428" alt="image" src="https://github.com/user-attachments/assets/168ad5fb-902b-494f-888a-419983324607" />
- Save the price rule (_note that the display name incorrectly resets to default_) <img width="634" height="370" alt="image" src="https://github.com/user-attachments/assets/ec915985-b1a3-4a69-9153-7384abdb190d" />
- Same thing for second rule  <img width="695" height="375" alt="image" src="https://github.com/user-attachments/assets/69b9ae62-493c-4f0e-ae87-438975e1bceb" /> <img width="621" height="369" alt="image" src="https://github.com/user-attachments/assets/e1dc0342-7b87-42df-bf7d-6a3aace61253" />
- Create a new sale quotation with pricelist set to our "Sample"
- Add product [6666] <img width="1207" height="420" alt="image" src="https://github.com/user-attachments/assets/07d4fb94-03b3-45ae-aeb4-feca4fee9c2c" />
- Add product [6667] <img width="1209" height="431" alt="image" src="https://github.com/user-attachments/assets/03e3a76a-2bb1-44e9-a819-ce3ca35703c7" />
- Incorrect prices in sale order <img width="1415" height="828" alt="image" src="https://github.com/user-attachments/assets/3626028d-31d0-4687-b09d-094c0212042a" />


Desired behavior after PR is merged:
- Each variant must have its own price.
- The added test simply edit the pricelist item using its own form.
- The `applied_on` field is added to the pricelist item form to ensure that its value is saved.
- If we edit the rule without expanded mode, it works fine only because the `applied_on` field exists in the list view as an invisible column.

_Note 1_: `applied_on` is updated by `_onchange_rule_content` using `update` instead of `write` (for caching ?).
But if the `applied_on` field is not on the form, then its value is never sent to low level `_write_multi`.

_Note 2_: to clear the field value with the Form test component, we must set `=self.env["product.product"]` instead of `=False` ....

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

Forward-Port-Of: odoo/odoo#245603
Forward-Port-Of: odoo/odoo#245444

Steps to reproduce:
-------------------
1. Install pos_settle_due and accountant
2. In Accounting settings, enable "Sales Credit Limit"
3. Create a new customer, enable its "Partner Limit" and set it to 100
4. Open PoS, select that partner, and select products such that the total exceeds 100

Notice that even though we have exceeded that partner's limit of 100, there are no indicators on the customer button (orange background on hover), nor there are warnings on the partners list modal nor on the payment page.

Why the bug
-----------
In `getPartnerCredit`, we are using `order.amount_total` to get the current ordre amount, however, this field is `undefined` for a new order and it's been assigned a value in `setOrderPrices`, which since [9538698](https://github.com/odoo/odoo/commit/9538698), is only called before sending the order to the backend.

The fix
-------
Now we read the total amount from the getter `order.priceIncl`, and round it as we would do in `setOrderPrices`.

opw-5489975

Forward-Port-Of: odoo/enterprise#104591

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

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

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

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

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

### Issue:
On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled
In this situation, an online payment could be initiated, but a silent error occurred during move validation:
the transaction was created, but the payment was never recorded, and no error appeared in the portal or the SO chatter

### Cause:
The CFDI validation error is raised internally but never surfaced to the user
https://github.com/odoo/enterprise/pull/91655
The PO (MIAL) recommended automatically enabling `CFDI to Public` when the partner address is incomplete,
forcing the user to complete the data This also ensures that the payment can be confirmed properly

### Steps to reproduce:
- Install `l10n_mx_edi_sale` and switch to the MX company
- Configure a Payment Provider and Payment Method (e.g., demo)
- Create a customer without ZIP or country
- Create a Sale Order for that customer
- In Other Info, set Online Payment to 100%
- Send the quotation and open the link in a private window
- Sign and Pay

Before the fix: the transaction is created, but no payment is recorded, and no error is shown

opw-5023724

Forward-Port-Of: odoo/enterprise#101881

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

Forward-Port-Of: odoo/enterprise#105587

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

Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being called as many times as there are open tabs. This used to be particularly annoying with the ringtone, which would play in unison. To solve this problem, we decided that only the "main tab" should be responsible for playing the ringtone. Since there can only be one main tab at a time, there can only be one ringtone at a time. Problem solved. This seemed to be an easy and effective solution.

However, we were informed that sometimes the call wouldn't ring at all 🤬
This called the reliability of the system into question. What would happen if:
- The main tab loses the WebSocket connection?
- The main tab is throttled?
- The main tab was never interacted with, preventing us from playing audio?
 - The notification arrives after the main tab is killed and before a new main tab is elected?

This commit attempts a new approach ⋆✴︎˚｡⋆
All tabs receiving incoming call notifications will now send a message to a central authority—The _SharedWorker_ 🙀—along with information about whether or not they can play audio. The SharedWorker then selects the first tab that can play audio and assigns it the task of playing the incoming ringtone.

This is expected to solve the problems mentioned above, as it guarantees that the "player tab" is a tab that:
- effectively received the incoming call notification
- is allowed to play audio

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

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

In this PR, we add the possibility to create and manage a complete CSRD/VSME report, integrated with AI, knowledge, survey and HR.

The Corporate Sustainability Reporting Directive (CSRD) is a legal framework in the EU that requires companies to report on their sustainability performance. It aims to standardize ESG reporting across the EU and make the information more comparable and reliable for investors and other stakeholders.
On the other hand, the Voluntary Sustainability Reporting for Micro and Small Enterprises (VSME) is a framework designed to support smaller companies in reporting on their sustainability performance. It encourages clear, comparable, and meaningful ESG disclosures while remaining proportionate to the size and capacity of the business.
Our reporting feature facilitates the steps involved in preparing a CSRD/VSME report by using the data we already have in Odoo, such as emissions (Scope 1, 2, 3), employee data, supplier and client information, or fleet metrics. As well as using AI to make suggestions, and integrating knowledge articles and surveys.

More precisely, the feature is composed of two main models:

- A new model (`esg.metric)` that is only used if the CSRD reporting is enabled (and only used in the context of CSRD reporting).
  It is linked to an ESRS data point (either Environmental, Social or Governance category) and can be of different types (Positive/Negative Impact, Risk or Opportunity).
  It is used to assess if a topic is material or not (Double Materiality Assessment), depending on the impact severity and financial severity scores. As well as scores obtained from the stakeholder reviews (we get those scores from surveys that have been completed, the surveys are sent with the action "Stakeholder Review").
  To help the user to create relevant metrics, we added an AI feature allowing to generate suggestions of metrics. Provided that the user gives a description of the company (size, revenues, activity, etc) to give as much context as possible to the AI prompt (see action "AI Suggest").

- A new model (`esg.report`) where you can specify the type of the report (CSRD or VSME), the dates (reporting date and base reference date), and additional information about the company.
  Once created, the report is linked to a knowledge article that contains the template of a complete CSRD/VSME report that you can edit, fold/unfold sections, add content, etc.
  When printing it to PDF, a lot of information is automatically filled in (data about your employees, accounting data, etc), including the carbon report, dynamic tables. That is done by replacing placeholders from the knowledge article when generating the PDF (an appendix includes all available placeholders with a small explanation for each).
  For CSRD reports only, there is the ability to automatically fold/unfold the ESRS sections of the articles depending on whether the data points we get from the metrics are material or not (see action "Update Materiality").
  For VSME reports only, there is a "Basic Module + Comprehensive Module" type that will include additional sections (C1-C9). Note that you can also load them manually from the root article with the "Load Template" action.

task-5172829

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

In **l10n_ec**, negative lines are not accepted in the XML.
They must be dispatched as discounts on positive lines.
The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased.

## Steps to reproduce

With **l10n_ec**:
1. Change the decimal accuracy to 6 digits.
2. Set the rounding method to *global rounding*.
3. Create an invoice with the following lines:

| Quantity | Price    | Taxes     |
|-----------|----------|-----------|
| 20        | 1.4235   | VAT 0% G  |
| 20        | 1.6425   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.4235   | VAT 0% G  |
| 6         | 3.747768 | VAT 15% G |
| 6         | 3.747768 | VAT 15% G |


In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`.

This happens due to rounding differences in how the `descuento` is computed in the
`common_details_info_template` from **l10n_ec_edi**:

format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount'])

where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere.

This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**.
Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed.

opw-5128612

Forward-Port-Of: odoo/enterprise#104659
Forward-Port-Of: odoo/enterprise#97337

Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being called as many times as there are open tabs. This used to be particularly annoying with the ringtone, which would play in unison. To solve this problem, we decided that only the "main tab" should be responsible for playing the ringtone. Since there can only be one main tab at a time, there can only be one ringtone at a time. Problem solved. This seemed to be an easy and effective solution.

However, we were informed that sometimes the call wouldn't ring at all 🤬
This called the reliability of the system into question. What would happen if:
- The main tab loses the WebSocket connection?
- The main tab is throttled?
- The main tab was never interacted with, preventing us from playing audio?
 - The notification arrives after the main tab is killed and before a new main tab is elected?

This commit attempts a new approach ⋆✴︎˚｡⋆
All tabs receiving incoming call notifications will now send a message to a central authority—The _SharedWorker_ 🙀—along with information about whether or not they can play audio. The SharedWorker then selects the first tab that can play audio and assigns it the task of playing the incoming ringtone.

This is expected to solve the problems mentioned above, as it guarantees that the "player tab" is a tab that:
- effectively received the incoming call notification
- is allowed to play audio

[Task-5411760](https://www.odoo.com/odoo/project.task/5411760)
Backport of https://github.com/odoo/enterprise/pull/104885

Opening the Shop Floor via the replenishment/forecast flow can
raise a js traceback.

**Steps to produce:**
- Install `mrp` module.
- Enable `multi-step routes` from the settings.
- Inventory > Configuration > Warehouse Management > Routes.
- In Manufacture route, make sure route is Applicable On `products`.
- Inventory > Products > Products > New.
- Click on forcasted button on product > Click on replenish button > Confirm.
- Click the Manufacturing Order shown in the notification.
- Confirm the MO and click Shop Floor.

**Issue:**
A JavaScript error occurs: `TypeError: Cannot read properties of null.`

**Root cause:**
The Shop Floor view relies on the menu service to determine the current
 application name by calling `this.menu.getCurrentApp().name`. When the
 Shop Floor is opened from the replenishment/forecast flow,
 the navigation occurs through action-based triggers rather than through
 the main menu. As a result, no menu selection is performed and
 `setCurrentMenu()`[1] is not executed beforehand.This leaves the current
 application undefined, causing `menu.getCurrentApp()` to return undefined
 and leading to a js traceback when `.name` is accessed.

[1]: https://github.com/odoo/odoo/blob/c646cb61d0752250b2600413d6d63deabd1d3e6d/addons/web/static/src/webclient/menus/menu_service.js#L57-L64

simillar fix : https://github.com/odoo/enterprise/pull/93043

Note: A tour is possible but unnecessary for this small use-case.

opw-5462965
---

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

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

Steps to reproduce the bug

- Create a storable product P1:
  - Tracking: Serial Number
- Log in as Marc Demo
- Create a sales order with 1 unit of P1
- Validate the delivery using serial number SN1
- Log in as Mitchell Admin
- Go to Settings:
  - Manage Users
    - Mitchell Admin
      - Sales: User: own documents only
- Go to the Serial Numbers list view:
  - Try to open SN1

**Problem:**
An access error is triggered:

```
Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Mitchell Admin (id=2) doesn't have 'read' access to:
- Sales Order Line, S00025 - P1 (Deco Addict) (sale.order.line: 51)

Blame the following rules:
- Personal Order Lines
```

When clicking on SN1, the `stock.lot` form view.
it's contains the field "sale_order_count", which is a computed field that needs to access all `sale.order` records using the serial number in order to compute the count.

Since Mitchell Admin is restricted to his own sales orders only, an access error is raised during the computation.

There is also a many2many view widget that triggers an access errors. This widget can be removed since the smart button is now available. The widget has already been removed in v19.

**Solution:**
In this view, any stock user, admin or not, must be able to see how many sales orders use a given serial number, regardless of whether those sales orders belong to them or not.

opw-5400731

**Steps to reproduce:**
1. Install modules `sale_management` and `l10n_din5008_sale`
2. Go to Settings, Configure Document Layout and set layout to DIN 5008
3. Create a new Sale Order
4. Set a customer, add a product, and fill in the Delivery Date (Other Info)
5. Click on Print and Preview

**Issue:**
The Delivery Date (commitment_date) is not displayed on:
- The DIN 5008 sale order report
- The sale order preview (portal view)

Functional experts confirmed that the Delivery Date must be visible when using the DIN 5008 layout.

**Cause:**
The `commitment_date` field was not included in the DIN 5008 sale order report template nor in the preview view.

**Solution:**
This commit adds the Delivery Date information to:
- The DIN 5008 sale order report template
- The sale order portal/preview view

**opw-5490651**

**Before:**
<img width="560" height="145" alt="image" src="https://github.com/user-attachments/assets/fb29cda1-d668-4682-aa04-12c613f248d8" />
<img width="861" height="268" alt="image" src="https://github.com/user-attachments/assets/615f259f-e0ff-4fb5-9852-1fdd75cda4c9" />

**After:**
<img width="589" height="145" alt="image" src="https://github.com/user-attachments/assets/3f1a8d25-783a-4600-b07e-11b547bb326b" />
<img width="824" height="271" alt="image" src="https://github.com/user-attachments/assets/46b37469-5c72-4556-95e2-eaea0824c166" />

Issue:

When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.

Cause:

A previous change (#237235) added the `abs` function so the `TotalTaxesWithheld` would be always with positive value. But this also affects the calculation of taxes `TotalTaxOutputs` in some cases, such as if the invoice line has negative values.

Steps to reproduce:

- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous

A correct invoice should be for example:

```
Product        Price       Taxes       Amount
---------------------------------------------
PRODUCT-A       1000    21%VAT 15%WHI    1000
Discount        -100    21%VAT 15%WHI    -100
---------------------------------------------
                       Untaxed amount     900
                      Withholding 15%    -135
                              VAT 21%     189
                      -----------------------
                                 TOTAL    954
```

This PR replaces #240808 

---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-pr

### Issue:
On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled
In this situation, an online payment could be initiated, but a silent error occurred during move validation:
the transaction was created, but the payment was never recorded, and no error appeared in the portal or the SO chatter

### Cause:
The CFDI validation error is raised internally but never surfaced to the user
https://github.com/odoo/enterprise/pull/91655
The PO (MIAL) recommended automatically enabling `CFDI to Public` when the partner address is incomplete,
forcing the user to complete the data This also ensures that the payment can be confirmed properly

### Steps to reproduce:
- Install `l10n_mx_edi_sale` and switch to the MX company
- Configure a Payment Provider and Payment Method (e.g., demo)
- Create a customer without ZIP or country
- Create a Sale Order for that customer
- In Other Info, set Online Payment to 100%
- Send the quotation and open the link in a private window
- Sign and Pay

Before the fix: the transaction is created, but no payment is recorded, and no error is shown

opw-5023724

The "Not Sent" filter in Payments list view was not returning the expected records. This was due to an incorrect domain condition in the search view.

This commit updates the filter logic to properly identify payments that haven't been processed or sent, ensuring the filter displays the correct records to the user.

**Description of the issue/feature this PR addresses:**
This PR fixes a bug in the "Not Sent" search filter within the Payment views (Account Payments). Currently, the filter fails to accurately identify and display records that have not been sent, leading to an empty or incorrect list of results regardless of the sending payment's actual status.

**Current behavior before PR:**
When a user applies the "Not Sent" filter in the Payments list view (including both Customer and Vendor payments), the system returns incorrect records or no records at all. This is caused by an inconsistent domain definition that doesn't align with the internal field tracking the "sent" status of the payment.

**Desired behavior after PR is merged:**
The "Not Sent" filter will correctly filter the list to show only those payments where the "Sent" status is not True. This will provide users with an accurate view of pending actions for both Customer and Vendor payments, ensuring consistency across the accounting module.

**Steps to reproduce:**
1. Navigate to the Accounting (or Invoicing) module.
2. Go to Vendors > Payments or Customers > Payments (the issue is global).
3. Ensure there are several payments in the list, some marked as "Sent" and others not yet sent.
4. Click on the Filters dropdown menu in the search bar.
5. Select the "Not Sent" filter.
6. Observe the results: Notice that the list either becomes empty or continues to show records that do not match the "Not Sent" criteria, failing to filter the data correctly.

**video**
https://drive.google.com/file/d/1NTKQ1tHWyZWfs3CPolfDTOMrqaDD9OcN/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

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