Issue
-----
When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency.

Example:
	Sale in EUR, Company in USD and 1.5 EUR = 1 USD rate.
	Sell for 15 EUR of products => the delivery picking shows 10 EUR

Steps to reproduce
-----
- Activate EUR currency at 1.5 EUR = 1 USD rate
- Setup company in USD
- Setup INTL FEDEX delivery method
- Create a dummy product with a 10 USD sale price
- Create a pricelist using the EUR currency
- Create a sale for some INTL client
	- set pricelist to EUR
	- add dummy product
	- add INTL FEDEX shipping
	- confirm the sale
- Confirm the linked delivery

> Message in chatter shows a price of 10 EUR instead of 15 EUR

Cause
-----
The problem is with the `carrier_price` field of `stock.picking`.

https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L21

The value is set by

https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L155

which gets its' value from the response of

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/delivery_fedex.py#L157

We then go through

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L382

where we call

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L484

The problem is that in `_decode_pricing` we take the first line matching the `rateType` with no regard to the currency of the rate

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L594-L598

we should also filter to ensure the rate matches the order's specified currency.

-----
Ticket:
opw-5419724

Forward-Port-Of: odoo/enterprise#103737
Forward-Port-Of: odoo/enterprise#103232

**PROBLEM**
When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one.

**STEP TO REPRODUCE**
According to the DIAN documentation, the GetNumberRange service is only available in the production environment. So i'm not sure if we can safely test this. The repro steps would be something like:
1. Request a range.
2. Exhaust all number from this range by sending invoices to DIAN.
3. Request a new range.
4. sync with DIAN. (notice the range selected is still the old one).
5. Try sending a new invoice to DIAN and notice there is an error.

**CAUSE**
In `l10n_co_dian/models/account_journal.py` the function `_l10n_co_dian_get_journal_values()` loops on all the xml `NumberRangeResponse` node and store the last range values encountered for each prefix. We don't  check if the this last range is still valid, if it's the newest created (could be checked with the xml field `ResolutionDate`, but the date could be the same if the range were created the same day), if it's the latest in term of number range (DIAN start with range 1-100, then 101-something etc.).

Forward-Port-Of: odoo/enterprise#103943

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/0364f563a [REL] 18.4.24 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/b456055e0 [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782)
https://github.com/odoo/o-spreadsheet/commit/cfc56f825 [FIX] demo: add import osheet [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/060d8d456 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885)
https://github.com/odoo/o-spreadsheet/commit/efe0d5b6f [FIX] Composer: Capture the correct selection on `F2` [Task: 5462713](https://www.odoo.com/odoo/2328/tasks/5462713)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. 

Have a ir cron action with the following code:

	time.sleep(MIN_TIME_PER_JOB)
	self.env['ir.cron']._commit_progress(remaining=1)
	return

The code looks stupid, but we tracked down a bug we had in the autovacuum cron in 18.3, and the minimum code to reproduce the problem is that above line of code.

Since there are remaining stuff to do, the cron worker should report a `PARTIALLY_DONE` status, and reschedule to call the cron action asap. But the system currently determine a `FULLY_DONE` status and reschedule the cron action *later* (next day for a cron with an interval of 1 day).

It is pretty bad for the autovacuum cron in 18.3

We used the opportunity to rework the `status` computation to one big match-case, for extra readability.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

**PROBLEM**
When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one.

**STEP TO REPRODUCE**
According to the DIAN documentation, the GetNumberRange service is only available in the production environment. So i'm not sure if we can safely test this. The repro steps would be something like:
1. Request a range.
2. Exhaust all number from this range by sending invoices to DIAN.
3. Request a new range.
4. sync with DIAN. (notice the range selected is still the old one).
5. Try sending a new invoice to DIAN and notice there is an error.

**CAUSE**
In `l10n_co_dian/models/account_journal.py` the function `_l10n_co_dian_get_journal_values()` loops on all the xml `NumberRangeResponse` node and store the last range values encountered for each prefix. We don't  check if the this last range is still valid, if it's the newest created (could be checked with the xml field `ResolutionDate`, but the date could be the same if the range were created the same day), if it's the latest in term of number range (DIAN start with range 1-100, then 101-something etc.).

Forward-Port-Of: odoo/enterprise#103943

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

**Problem**
Before this commit, the tour `test_03_snippets_all_drag_and_drop` could fail with the error `Element (:iframe .o_snippet_preview_wrap[data-snippet-id="s_popup"]) has not been found`. The failure was reproducible locally and appeared non-deterministically on runbot.

**Cause**
The tour steps could occasionally execute too quickly, leading to non-determinist behavior where snippets were dropped inside a popup that had been inserted but not yet closed. When the dropzone is inside an open popup, some snippets (e.g. `s_popup`) are excluded from the Snippet Viewer, resulting in the error reported above.

**Solution**
The tour flow is modified such that popup snippets are removed after being dropped, as already happens for every other snippet category. This completely removes the risk that new snippets are dropped into a popup.

**Note**
This bug was already fixed starting from version 19.0 by [1]. The performance boost indroduced by [2] made the same bug appear also on 18.4, thus the need for this commit.

[1]: https://github.com/odoo/odoo/pull/242231
[2]: https://github.com/odoo/odoo/pull/243102

runbot-233328

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/8d1d32160 [REL] 18.3.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3d2d2e6da [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782)
https://github.com/odoo/o-spreadsheet/commit/de60a1cd2 [FIX] demo: add import osheet [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/61bbf4ce1 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885)
https://github.com/odoo/o-spreadsheet/commit/42d525737 [FIX] Composer: Capture the correct selection on `F2` [Task: 5462713](https://www.odoo.com/odoo/2328/tasks/5462713)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Summary:
Refactor `preserveSelection()` to use a stack-based approach (`preservedCursors` array) instead of a single cursor reference. This allows nested calls to `preserveSelection()` to operate independently while keeping cursor updates synchronized across active contexts.

Problem:
Using a single stored cursor caused issues in nested calls to `preserveSelection()`:

1. **State overwrite:** Inner calls could overwrite or clear the outer cursor.
2. **Stale references:** If an inner function replaced a DOM node, the outer cursor could still point to a removed node and fail on restore.

Solution:
Use an array of cursor subscribers

- **Shared updates:** When calling `remapNode` on a cursor, it iterates over all active subscribers in the stack. This ensures node replacements performed in inner contexts also update outer cursor references.
- **Scoped cleanup:** `restore()` now removes only the corresponding cursor instance from the stack, ensuring proper lifecycle management.

Example:
The key improvement is that outer scopes receive updates performed by inner scopes.

```javascript
// Function A (outer)
function wrapperFunction() {
    const cursor = this.preserveSelection();
    replaceTextWithSpan();
    cursor.restore();
}

// Function B (inner)
function replaceTextWithSpan() {
    const innerCursor = this.preserveSelection();
    const oldNode = document.querySelector('text');
    const newNode = document.createElement('span');
    oldNode.replaceWith(newNode);
    innerCursor.remapNode(oldNode, newNode);
    innerCursor.restore();
}
```
opw-5386862

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

Forward-Port-Of: odoo/odoo#238989

**PROBLEM**
When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one.

**STEP TO REPRODUCE**
According to the DIAN documentation, the GetNumberRange service is only available in the production environment. So i'm not sure if we can safely test this. The repro steps would be something like:
1. Request a range.
2. Exhaust all number from this range by sending invoices to DIAN.
3. Request a new range.
4. sync with DIAN. (notice the range selected is still the old one).
5. Try sending a new invoice to DIAN and notice there is an error.

**CAUSE**
In `l10n_co_dian/models/account_journal.py` the function `_l10n_co_dian_get_journal_values()` loops on all the xml `NumberRangeResponse` node and store the last range values encountered for each prefix. We don't  check if the this last range is still valid, if it's the newest created (could be checked with the xml field `ResolutionDate`, but the date could be the same if the range were created the same day), if it's the latest in term of number range (DIAN start with range 1-100, then 101-something etc.).

Forward-Port-Of: odoo/enterprise#103943

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/755a787c4 [REL] 18.2.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/2322bd78f [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782)
https://github.com/odoo/o-spreadsheet/commit/2783ff635 [FIX] demo: add import osheet [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/673dd2ee7 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885)
https://github.com/odoo/o-spreadsheet/commit/ef7b40f5c [FIX] Composer: Capture the correct selection on `F2` [Task: 5462713](https://www.odoo.com/odoo/2328/tasks/5462713)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

# Current State Overview
<details><summary>$${\color{red}Deferred}$$ Backend/Python</summary>
<p>
Deferred: decoding doesn't make sense in the backend, and manufacturing isn't ready for EPC write automation, such that encoding isn't a priority.

Encode & Decode :

- sgtin-96
- sgtin-198
- sscc-96
- sgln-96
- sgln-195

TODO :
- Replace compute by explicit calls : more efficient and less complicated
- Implement logical segment bit count at scheme template level

Simple test :
```
# model: Electronic Product Code Scheme, gs1.epc.scheme

vals = [
    #SGTIN
    {'uri_tag': "urn:epc:tag:sgtin-96:3.0614141.812345.6789"},
    {'raw_value': 0X3074257bf7194e4000001a85},
    {'uri_tag': "urn:epc:tag:sgtin-198:3.0614141.812345.6789"},
    {'raw_value': 0X3674257bf7194e5b3770e4000000000000000000000000000000},    
    {'uri_tag': "urn:epc:tag:sgtin-198:3.0614141.712345.32a%2Fb"},
    {'raw_value': 0X3674257bf6b7a659b2c2bf100000000000000000000000000000},
    #Others
    {'uri_tag': "urn:epc:tag:sscc-96:3.0614141.1234567890"},
    {'raw_value': 0X3174257bf4499602d2000000},
    {'uri_tag': "urn:epc:tag:sgln-96:3.0614141.12345.5678"},
    {'raw_value': 0X3274257bf46072000000162e},
    {'uri_tag': "urn:epc:tag:sgln-195:3.0614141.12345.32a%2Fb"},
    {'raw_value': 0X3974257bf46072cd9615f8800000000000000000000000000000},
]

schemes = model.create(vals)
message = []
for scheme in schemes:
    message.append(f"Uri : {scheme.uri_tag}\nHex : {scheme.hex_value}\n") # Bit : {scheme.raw_value:b}\n
log('\n'.join(message))
```

Result :
```
Uri : urn:epc:tag:sgtin-96:3.0614141.812345.6789
Hex : 3074257bf7194e4000001a85

Uri : urn:epc:tag:sgtin-96:3.0614141.812345.6789
Hex : 3074257bf7194e4000001a85

Uri : urn:epc:tag:sgtin-198:3.0614141.812345.6789
Hex : 3674257bf7194e5b3770e4000000000000000000000000000000

Uri : urn:epc:tag:sgtin-198:3.0614141.812345.6789
Hex : 3674257bf7194e5b3770e4000000000000000000000000000000

Uri : urn:epc:tag:sgtin-198:3.0614141.712345.32a%2Fb
Hex : 3674257bf6b7a659b2c2bf100000000000000000000000000000

Uri : urn:epc:tag:sgtin-198:3.0614141.712345.32a%2Fb
Hex : 3674257bf6b7a659b2c2bf100000000000000000000000000000

Uri : urn:epc:tag:sscc-96:3.0614141.1234567890
Hex : 3174257bf4499602d2000000

Uri : urn:epc:tag:sscc-96:3.0614141.1234567890
Hex : 3174257bf4499602d2000000

Uri : urn:epc:tag:sgln-96:3.0614141.12345.5678
Hex : 3274257bf46072000000162e

Uri : urn:epc:tag:sgln-96:3.0614141.12345.5678
Hex : 3274257bf46072000000162e

Uri : urn:epc:tag:sgln-195:3.0614141.12345.32a%2Fb
Hex : 3974257bf46072cd9615f8800000000000000000000000000000

Uri : urn:epc:tag:sgln-195:3.0614141.12345.32a%2Fb
Hex : 3974257bf46072cd9615f8800000000000000000000000000000
```
</p>
</details> 

<details><summary>$${\color{orange}In \space Progress}$$ Frontend/Javascript</summary>
<p>
Decode Only :

- sgtin-96
</p>
</details>

To compare and test :
- https://www.gs1.org/services/epc-encoderdecoder
- TDS 2.1, part E.3 (https://ref.gs1.org/standards/tds/2.1.0/, p.242)

[Task #4256189](https://www.odoo.com/odoo/project.task/4256189)

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/e5cbf1807 [REL] 19.2.0-alpha.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c206f46b4 [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782)
https://github.com/odoo/o-spreadsheet/commit/c1c00f4d9 [IMP] pivots: implement pivot table styles [Task: 4552232](https://www.odoo.com/odoo/2328/tasks/4552232)
https://github.com/odoo/o-spreadsheet/commit/fcdef4757 [IMP] renderer: draw cell background over grid lines [Task: 4552232](https://www.odoo.com/odoo/2328/tasks/4552232)
https://github.com/odoo/o-spreadsheet/commit/a865dbf2c [IMP] style: add `skipCellGridLines` style option [Task: 4552232](https://www.odoo.com/odoo/2328/tasks/4552232)
https://github.com/odoo/o-spreadsheet/commit/86856abfd [REF] table style: add `bold` to table style presets [Task: 4552232](https://www.odoo.com/odoo/2328/tasks/4552232)
https://github.com/odoo/o-spreadsheet/commit/351919f8f [REF] subtotal: extract SUBTOTAL tracking to generic plugin [Task: 4552232](https://www.odoo.com/odoo/2328/tasks/4552232)
https://github.com/odoo/o-spreadsheet/commit/4dee81dbe [IMP] Added some shortcuts [Task: 5231802](https://www.odoo.com/odoo/2328/tasks/5231802)
https://github.com/odoo/o-spreadsheet/commit/c7180d1f7 [FIX] tests: fix useless shortcuts tests [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/a30272f1f [IMP] Autocompletion of curly brackets {} [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/21e3d6155 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885)
https://github.com/odoo/o-spreadsheet/commit/20ee28aac [IMP] figure: add data-type attribute to figure carousel tabs [Task: 5447027](https://www.odoo.com/odoo/2328/tasks/5447027)
https://github.com/odoo/o-spreadsheet/commit/abb24152c [FIX] Style: UPDATE_CELL overwrites the cell style [Task: 5441149](https://www.odoo.com/odoo/2328/tasks/5441149)
https://github.com/odoo/o-spreadsheet/commit/a4792e26f [FIX] tests: fix network serialization in mock [Task: 5441149](https://www.odoo.com/odoo/2328/tasks/5441149)
https://github.com/odoo/o-spreadsheet/commit/ea607f07d [IMP] formulas: add spilled range operator [Task: 5365642](https://www.odoo.com/odoo/2328/tasks/5365642)
https://github.com/odoo/o-spreadsheet/commit/3b6e45921 [IMP] style: check if default but faster [Task: 5431688](https://www.odoo.com/odoo/2328/tasks/5431688)
https://github.com/odoo/o-spreadsheet/commit/abeea3e5d [FIX] Composer: Capture the correct selection on `F2` [Task: 5462713](https://www.odoo.com/odoo/2328/tasks/5462713)
https://github.com/odoo/o-spreadsheet/commit/7c556a916 [REF] lint: enforce braces for all control statements [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None.

Steps to reproduce:
1) Install 'account_reports' module with demo data and enable developer mode. 
2) Navigate to Accounting > Reporting> Partner Reports > Aged Receivable.
3) Click on 'gear icon' to navigate advance options. 
4) Click on the Options tab and set Integer Rounding to 'Nearest', click save
   and close adv options.
5) Expand a partner line.

Error:
`TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'`

Root Cause:
When integer rounding is enabled, the system iterates over formula results to round them using `float_round`(see[1]). However, specific report columns (such as totals for empty periods) may return None. The `float_round` function attempts to perform arithmetic on this value, failing because it cannot divide NoneType.

FIX:
Skip the rounding if the value received at [1] is None.

[1]- https://github.com/odoo/enterprise/blob/9b517564d95424836da1e8368f6b5dc52ae45d1a/account_reports/models/account_report.py#L3329

opw-5392883

Forward-Port-Of: odoo/enterprise#102417

**PROBLEM**
When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one.

**STEP TO REPRODUCE**
According to the DIAN documentation, the GetNumberRange service is only available in the production environment. So i'm not sure if we can safely test this. The repro steps would be something like:
1. Request a range.
2. Exhaust all number from this range by sending invoices to DIAN.
3. Request a new range.
4. sync with DIAN. (notice the range selected is still the old one).
5. Try sending a new invoice to DIAN and notice there is an error.

**CAUSE**
In `l10n_co_dian/models/account_journal.py` the function `_l10n_co_dian_get_journal_values()` loops on all the xml `NumberRangeResponse` node and store the last range values encountered for each prefix. We don't  check if the this last range is still valid, if it's the newest created (could be checked with the xml field `ResolutionDate`, but the date could be the same if the range were created the same day), if it's the latest in term of number range (DIAN start with range 1-100, then 101-something etc.).

Forward-Port-Of: odoo/enterprise#103943

Previously, when a user had multiple tabs open and received a call, each tab created its own call record in the database and managed the call state independently. This led to inconsistencies: for example, with two tabs open, accepting a call in one tab would create two call records—one marked as ongoing and the other as missed.

This change fixes these issues and addresses several related concurrency and call state management problems.

### Key changes

- **Single call creation per incoming call**
On an incoming call, only one call record is created. The Call-ID from the SIP INVITE is now used to coordinate and ensure a single call is created in the database.

- **Improved handling of concurrent tabs**
Each tab still manages the call state from its own perspective, but it now uses the Reason header from SIP CANCEL requests (when present) to avoid marking a call as missed if it was answered in another tab (see “Heterogeneous Error Response Forking Problem” on the web).

- **Server-side call state validation**
Call state transitions are now validated server-side, allowing proper reconciliation of the different “points of view” coming from multiple tabs.

### Refactoring and architectural improvements

- The Session class is now solely responsible for managing the SIP session (as defined in SIP.js). SIP sessions should no longer be accessed directly from outside this class.

- Call creation and call state management can now fail without preventing communication. As a result, many components now rely on information from the session rather than the call object (with partner_id remaining on the call).

- Active, main, and transfer session changes are now handled by UserAgent and applied immediately when the session state changes. We no longer wait for a call state update to trigger these changes.

**Notes**

- The Session class could not extend Reactive due to failing SIP.js tests caused by object reference issues. Instead, an event bus is used to notify core VoIP components of session changes.

- This work prepares the system for server-side call handling without tab interference (Task 4917399).

- When a tab attempts to update a call state, the operation may succeed or fail. In all cases, the server returns the current call state, which may be temporarily inaccurate due to concurrent updates. As a result, a tab’s local view of the call state may be transiently incorrect.

task-2810301

Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>

**Steps to reproduce**
On a local DB, with demo data:
- Change your machine's time to a late part of the day (e.g. 6pm)
- Install `mrp_workorder`
- Set the "Standard 40 hours/week" (used by a workcenter) as flexible.
- From the Shop Floor, start the "WH/MO/00003 - Manual Assembly"
workorder.

"Validation Error: The start date of the time off must be earlier than
the end date."

**Cause**
`_calculate_date_finished` in mrp is calling `plan_hours` and under
certain conditions with a flexible resource, it is possible for
`plan_hours` to return a datetime before the `day_dt` parameter.
This happens because for flexible resources,
`_attendance_intervals_batch` can return attendance intervals with
start or end datetimes outside of the start_dt -> end_dt window.
For example, a flexible calendar with 8h/day will return the
8:00->16:00 interval, even if start_dt is later than 8:00.

**Change**
Don't return attendance intervals outside of the [start_dt, end_dt]
interval by shifting them if necessary.

opw-5123230

Forward-Port-Of: odoo/odoo#243213
Forward-Port-Of: odoo/odoo#233169

Issue
-----
When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency.

Example:
	Sale in EUR, Company in USD and 1.5 EUR = 1 USD rate.
	Sell for 15 EUR of products => the delivery picking shows 10 EUR

Steps to reproduce
-----
- Activate EUR currency at 1.5 EUR = 1 USD rate
- Setup company in USD
- Setup INTL FEDEX delivery method
- Create a dummy product with a 10 USD sale price
- Create a pricelist using the EUR currency
- Create a sale for some INTL client
	- set pricelist to EUR
	- add dummy product
	- add INTL FEDEX shipping
	- confirm the sale
- Confirm the linked delivery

> Message in chatter shows a price of 10 EUR instead of 15 EUR

Cause
-----
The problem is with the `carrier_price` field of `stock.picking`.

https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L21

The value is set by

https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L155

which gets its' value from the response of

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/delivery_fedex.py#L157

We then go through

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L382

where we call

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L484

The problem is that in `_decode_pricing` we take the first line matching the `rateType` with no regard to the currency of the rate

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L594-L598

we should also filter to ensure the rate matches the order's specified currency.

-----
Ticket:
opw-5419724

Forward-Port-Of: odoo/enterprise#103737
Forward-Port-Of: odoo/enterprise#103232

### Issue:
When creating a record rule on moves using partners, a traceback is raised when opening a contact.

### Steps to reproduce:
- Install 'account_followup' and 'contacts'
- In Settings > Technical > Security > Record Rules create a new rule
	- name: Test Rule
	- model: Journal Entry
	- definition: `[('partner_id.is_company', '!=', True)]`
- Open the Contact app and try to open a contact
- Traceback

### Cause:
The newly created rule is used in the query computed by `_compute_has_moves()`. To do this the tables 'account_move' and 'res_partner' are joined. Then `subselect()` simply adds the select element with the string it is given, resulting in:

```sql
SELECT commercial_partner_id
FROM "account_move"
LEFT JOIN "res_partner"
...
```

But both `account_move` and `res_partner` have a column named "commercial_partner_id" resulting in an ambiguous column reference traceback.

### Solution:
We need to add precision on which table should be used. `subselect()` cannot guess which one should be used. We cannot add the precision in the definition of `field_names` because it is not compatible with the domain used by `_search()`.

So we add `'account_move.'` to the field name before giving it to `subselect()`.

opw-5467608

Forward-Port-Of: odoo/enterprise#103792

### [FIX] purchase_mrp, mrp: correct BoM Kit valuation with nested kits

#### Issue:
When purchasing a BoM Kit (50/50) containing others BoM Kits (50/50), cost share was applied at each level (50% instead of 25%), leading to overvaluation (e.g., 200% total instead of 100%)

#### Cause:
`cost_share` was always applied fully during BoM explosion and as a portion of the full price on `_get_unit_price()`

#### Other bug fixed:
Fix `_get_cost_share()` to correctly return 0 when BoM total cost_share already equals 100%

#### Requirement:
AVCO (Average Cost) must be enabled on all components/BoMs

#### Steps to reproduce:
1. Recreate that hierarchy with AVCO Products
- A kit "Testing Kit Complete" containing:
-- "Component01", cost share 50%
-- A kit "Testing Kit 1", cost share 50%:
--- "Component02", cost share 50%
--- "Component03", cost share 50%
2. Create and validate a Purchase Order for "Testing Kit Complete" (unit price: 1000)
3. Receive the products
4. Go in Inventory > Reporting > Valuation and search for Component
5. All 3 components are set to 500, instead of Component01: 500 / Component02: 250/ Component03: 250

opw-4806023


### [FIX] purchase_mrp: correct BoM valuation with product variants or optional lines

#### Issue:
BoM valuation ignores variant-specific lines and does not skip lines with quantity 0

#### Cause:
The code only checks that the BoM adds up to 100%
But this can cause issues with variants that do not include all products or with optional lines
As a result, the total valuation may be incorrect

#### Steps to reproduce:
1. Recreate a kit hierarchy with AVCO products:
   - Kit "Variant Kit" (Variant Color: White and Wood) containing:
     -- "Component01", cost share 0%, only for variant White
     -- "Component02", cost share 0%
2. Create and confirm a Purchase Order for "Variant Kit" (variant: Wood, unit price: 1000)
3. Receive the products
4. Go to Inventory > Reporting > Valuation and search for the components
5. Only Component02 appears with 500$, so only half of the total value is shown

opw-4806023
opw-5085457

Forward-Port-Of: odoo/odoo#242316
Forward-Port-Of: odoo/odoo#218326

Processing a buy-receive-bill process in a foreign currency and with
an auto-standard product will lead to an incorrect valuation

To reproduce the issue:
(Company in USD)
1. Enable EUR and define the rates as followed:
   - Yesterday: 2
   - Today: 2.5
2. Create a product category:
   - Method: Standard
   - Valuation: Automated
3. Create a product P in that category
   - Cost: 10 USD
4. [Yesterday] Confirm a PO in EUR with 1 x P
5. [Yesterday] Receive it
6. Bill

Error: the stock valuation has two entries: one with 10 USD debit, the
receipt. Another one with 2 USD credit, the currency exchange rate
difference. The second one is a mistake, in a standard configuration,
the stock valuation should be impacted by nothing but the cost defined
on the product form.

Since [1], in some conditions the method `_get_exchange_account`
returns the stock valuation account. This is what happens here, but
it's a mistake since in the above case, we should stick with the
classic account (i.e. the `super` call). The conditions must be more
strict.

[1] https://github.com/odoo/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7

OPW-5380665

Forward-Port-Of: odoo/odoo#243094
Forward-Port-Of: odoo/odoo#243029

**PROBLEM**
When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one.

**STEP TO REPRODUCE**
According to the DIAN documentation, the GetNumberRange service is only available in the production environment. So i'm not sure if we can safely test this. The repro steps would be something like:
1. Request a range.
2. Exhaust all number from this range by sending invoices to DIAN.
3. Request a new range.
4. sync with DIAN. (notice the range selected is still the old one).
5. Try sending a new invoice to DIAN and notice there is an error.

**CAUSE**
In `l10n_co_dian/models/account_journal.py` the function `_l10n_co_dian_get_journal_values()` loops on all the xml `NumberRangeResponse` node and store the last range values encountered for each prefix. We don't  check if the this last range is still valid, if it's the newest created (could be checked with the xml field `ResolutionDate`, but the date could be the same if the range were created the same day), if it's the latest in term of number range (DIAN start with range 1-100, then 101-something etc.).

Forward-Port-Of: odoo/enterprise#103943

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

**For r+: Needs a few changes at 18.0 (hours per day of employee is retrieved differently for example)**

opw-4934391
opw-5226806

Forward-Port-Of: odoo/odoo#239836

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c0048a0b4 [REL] 18.0.54 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/de161dd1b [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782)
https://github.com/odoo/o-spreadsheet/commit/af49eeb25 [FIX] demo: add import osheet [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4080aaea2 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

- for more then one records having same code it's raising an singleton error at fetching the name

- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```

- OPW-5450360

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844