### 1) Refresh Token & Cron

Intervat API's provide use both access & refresh tokens. As long as
we keep a valid refresh token, we can keep the connection opened by
requesting a new refresh token.

Currently, we force the connection to close after 4 hours, but it's
too short.

This commit goes to the opposite way, and keep the connection opened
as long as the user wants.

As we need to keep a valid refresh token, we add a cron who execute once each 2 days
to fetch new refresh tokens.

Also, to prevent being stuck, add a new button in res settings to
manually close the connection.

### 2) Accounting firm

When submitting vat return to Intervat API, we have 2 situations:
1. The user submit his own declaration
2. An accounting firm submit the declaration for the client

The current implementation works nicely with situation 1, but not 2. The problem is
when starting the authentication proccess, we give Intervat a company number, the current
company number. But when an accounting firm is set on the company, we should use the
VAT number of the firm instead of the current company, as it will be an accountant from
the accounting firm who will submit the return.

So this commit try to find the accounting firm VAT before the current company VAT for
the authentication proccess. Also, add a new settings in Intervat settings to change the
accounting firm from there.

### 3) Small fixes

Small fixes done for corner cases, see commits messages.

task-5420287,5500052,5495079

This reverts commit https://github.com/odoo/odoo/commit/0ffb96dedc776552564cec28140340ec38dee9d1.

The commit was incomplete and while it prevented the crash, the resulting table
did not match the expected layout.

Original issue:

Problem:
The grid conversion logic only finalized a row when iterating through the
last column in the input list. If a row reached exactly 12 grid spans
while more columns remained (e.g., a `col-12` in the middle), the logic
did not start a new row. As a result, remaining columns overflowed the
current row visually.

Cause:
In a single row, if a column had a size 12 and was followed by another column of
any size, it would crash because the algorithm did not reset the index to the
start of the next row.

Steps to reproduce:
- Add a Marketing block.
- Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" />
- Save.
- Traceback.

Solution:
This more thorough fix properly handles all problematic aspects:
- filter conflicting `col-x` instructions on a single element to keep only one
  size
- ensure that a gridIndex of 12 does not cause a crash in the algo
- properly add all effective `td` in a row in all circumstances (there where
  cases where the final row could be omitted)

opw-5439481

Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Thomas Josse <thjo@odoo.com>
Co-authored-by: Walid Sahli <wasa@odoo.com>

**Steps to reproduce:**
- Make a rounding method, put 1.00 as the value and nearest as the method
- Make a product without tax, the price should be 16.50
- Go to the PoS, order that product
- On the payment screen, click Cash, the value is rounded to 17
- Input "20" to change the payment line's value
- The change is "-4", which doesn't make sense as the price to pay was 17

**Why the fix:**
Before this commit, we used the round function, which is symmetric, meaning that as round(1.23) with a
precision of 0.1 and UP method will return 1.3, the same with round(-1.23) will return -1.3, meaning the rounding method will return the same number and just change the sign depending on if the input is positive and negative.

This causes inconsitencies, because clicking Cash would set the price to pay to 17, but paying 20 would set the change to -4.

With an assymetric rounding we prevent this problem, as it inverts the rounding method if the value is negative. In our case, this means that the change will be rounded DOWN, to -3.

opw-5476694

Issue
-----
Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means

`d['rateType'] == rating_result['actualRateType']`

is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`.

Solution
-----
In the request we send, we hardcode

`'rateRequestType': ['PREFERRED']`

so we can look for a match using 'PREFERRED' as a prefix of `rateType`.

The Fedex API lists all possible values of the enum `rateType`

https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html

<details>
<summary>Enum values as per the API</summary>

"enum": [
	"INCENTIVE",
	"NEGOTIATED",
	"PAYOR_ACCOUNT_PACKAGE",
	"PAYOR_ACCOUNT_SHIPMENT",
	"PAYOR_CUSTOM_PACKAGE",
	"PAYOR_CUSTOM_SHIPMENT",
	"PAYOR_LIST_PACKAGE",
	"PAYOR_LIST_SHIPMENT",
	"PAYOR_RETAIL_PACKAGE",
	"PAYOR_RETAIL_SHIPMENT",
	"PREFERRED_ACCOUNT_PACKAGE",
	"PREFERRED_ACCOUNT_SHIPMENT",
	"PREFERRED_CUSTOM_PACKAGE",
	"PREFERRED_CUSTOM_SHIPMENT",
	"PREFERRED_INCENTIVE",
	"PREFERRED_LIST_PACKAGE",
	"PREFERRED_LIST_SHIPMENT",
	"PREFERRED_NEGOTIATED",
	"PREFERRED_RETAIL_PACKAGE",
	"PREFERRED_RETAIL_SHIPMENT",
	"RATED_ACCOUNT_PACKAGE",
	"RATED_ACCOUNT_SHIPMENT",
	"RATED_CUSTOM_PACKAGE",
	"RATED_CUSTOM_SHIPMENT",
	"RATED_LIST_PACKAGE",
	"RATED_LIST_SHIPMENT",
	"RATED_RETAIL_PACKAGE",
	"RATED_RETAIL_SHIPMENT",
	"UNKNOWN"
],

</details>

There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe.

-----
Ticket:
opw-5482949

Forward-Port-Of: odoo/enterprise#105156

**Issue**
When producing a large number of serial-tracked products, a RecursionError
can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture
  routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Produce the 100 units on the child MO of product C (100 backorders are created).
- On the main MO (product A), click on "Prepare MO".
- Attempt to produce product B.
→ RecursionError: maximum recursion depth exceeded.

**Cause**
While setting `move_finished_ids`:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806

the `deadline_date` of the final move is updated:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63

This deadline is then propagated to chained moves:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55
via:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61

This propagation retriggers the `move_finished_ids` setter recursively on other
moves. The recursion depth grows with the number of generated moves, eventually
exceeding Python's maximum recursion limit.

opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#239648

The Austrian tax report computes line 7 by subtracting the deductible input tax instead of adding it, leading to an overstated VAT payable or understated credit.

### **Steps to reproduce:**
- Install `Accounting` app with `l10n_at` localization and switch to AT Company.
- Create a customer invoice for some product with price 1000 and 20% Tax.
- Create a vendor bill for some product with price 100 and 20% Tax.
- Open the Austrian tax report for the corresponding period.

### **Observed behavior:**
section-7 shows `-220` instead of the correct amount `-180`. because value of,
section-4 = -200
section-5 = 20
section-6 = 0

Current calculation for **section-7 = section-4 - section-5 + section-6** which is equal to `-220`

### **Expected behavior:**
1) Section-4(VAT Computation (U1/U30))- negative value is correct as this is the amount of
sales tax which needs to pay to the tax office.

2) Section-5(Deductible input tax computation) and section-6(Other corrections) - are positive
values and are added to section-4 as this is the input tax which is get back from the tax office.

hence the correct calculation for **section-7 will be section(4+5+6).**
### **Root cause**
Since [commit](https://github.com/odoo/odoo/pull/224604/commits/06666fc55a7a3f569a0d15f0827ed8e2199cf51c), introduced a formula that subtracts the deductible input tax(section-5) in section-7, causing the
miscalculation.

### **Fix**
Update the section-7 aggregation formula to add deductible input tax instead of subtracting it.

**opw-5476604**

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

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

## [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#244823
Forward-Port-Of: odoo/odoo#232147

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs.

Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs.

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

## Steps to reproduce:

[Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing)
1. Navigate to Apps and install l10n_mx_edi.
2. Switch to any of the Mexican companies that appear.
3. Navigate to Accounting > Configuration > Currencies.
4. Click into the USD currency.
5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field).
6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible.

[Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing)
1. Navigate to Accounting > Customers > Invoices.
2. Select New to create a new invoice.
3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES).
4. Add the 45 day Payment terms. This should change the payment policy to PPD.
5. Change the currency to USD.
6. Add the product FURN_8220 (or any with the unspsc_code_id set).
7. Set the unit price of the product to 58968.29.
8. Confirm the invoice.
9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again.
10. Select Register Payment, then Confirm Payment.
11. Select the Update Payments smart button.
12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.

Forward-Port-Of: odoo/enterprise#105102
Forward-Port-Of: odoo/enterprise#102557