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

Situation
-----
When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1054

because of the `m.location_id == move.location_final_id` part being false in

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1090-L1097

This is because, during the merge, `location_final_id` is not propagated to the new MO

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L2416-L2424

so when the new MO's `move_finished_id` gets computed

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L822

it gets the MO's `location_final_id`

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L1202

which is false. This leads to to the move getting the warehouse's default stock location thanks to

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/mrp/models/stock_move.py#L456-L457

This is problematic for complex use cases with multi-locations and custom routes.

It should be safe to propagate the `location_final_id` of the merged MOs if they all share the same one.

Use case example
-----
<details>
<summary>Full use case</summary>

- Enable multi-step routes
- Create location "WH/Stock/L1"
- Create location "WH/Stock/L2"

- Create Operation Type "MO child"
	- Type of Operation: Manufacturing
	- Sequence Prefix: MOCHILD
	- Source Location: L1
	- Destination Location: L2
- Create Operation Type "Push Transfer"
	- Type of Operation: Internal Transfer
	- Sequence Prefix: L2L1
	- Source Location: L2
	- Destination Location: L1
- Create Route "MO child"
	- Create Rule "Manufacture"
		- Action: Manufacture
		- Operation Type: MO child
		- Source Location: False
		- Destination Location: Stock
- Create Route "2-step"
	- Warehouse: Main WH
	- Create Rule "L1 -> Virtual/Production"
		- Action: Pull from
		- Operation Type: MO child
		- Source Location: L1
		- Destination Location: Virtual/Production
	- Create Rule "Push: L2 -> L1"
		- Action: Push To
		- Operation Type: Push Transfer
		- Source Location: L2
		- Destination Location: L1
- Unarchive MTO
- Edit MTO route
	- Create Rule "L1 -> Virtual/production (MTO)"
		- Action: Pull
		- Operation Type: "My Company: Manufacturing"
		- Source Location: L1
		- Destination Location: Virtual/Production
		- Supply Method: Trigger another rule
- Create product "Main product"
- Create product "Child product"
	- Routes: "MO child" & MTO
- Create product "Material" (consumable)
- Create BOM
	- Product: "Main product"
	- Component: "Child product"
- Create BOM
	- Product: "Child product"
	- Component: "Material"
- Create MO for "Main product"
	- Misc/Component Location set to L1
- Duplicate the MO
- Merge child MOs & produce
- Validate merged MO transfer to L1
- Go back to one of the "Main product" MO

> Component quantity is 0
</details>

-----
Ticket:
opw-5144196

Forward-Port-Of: odoo/odoo#242373
Forward-Port-Of: odoo/odoo#240695

In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type.

While trying to parse such content in Odoo, it causes issues with the standard CPython email library, as no standard handler exists for '*/*' content-types:

Example error:
```
File "/usr/lib/python3.13/email/contentmanager.py", line 25, in get_content
raise KeyError(content_type)
KeyError: '*/*'
```

This is not compliant with valid MIME types defined in RFC2046/section-3, but in real life scenarios, blocking the processing of an incoming email in Odoo because of this might be excessive.

While not a perfect solution, we will assume that attachments falsly reported as `*/*` are to be processed as 'application/octet-stream' content types. This should cover most use-cases, and if it still fails, we will consider that it's up to the original email sender to be RFC compliant.

OPW-5425093

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

Forward-Port-Of: odoo/odoo#242193

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

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

Issue:
Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id

Step to reproduce:
- Activate analytic accounting
- Go to Accounting Report -> General Ledger -> Options
- Activate "Analytic Group By"
- Create an invoice
- add a line with an analytic account
- Confirm the Invoice
- Duplicate the invoice
- Confirm the second invoice
- Go to the General Ledger
- Group By the analytic account you used

Current Behavior:
General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger.
Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry.

Expected behavior:
- "View Journal Entry" should send to the right entry

Proposed Solution:
To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id.

However, lines are merged into only one single line.

opw-5267981

Forward-Port-Of: odoo/enterprise#103169

In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type.

While trying to parse such content in Odoo, it causes issues with the standard CPython email library, as no standard handler exists for '*/*' content-types:

Example error:
```
File "/usr/lib/python3.13/email/contentmanager.py", line 25, in get_content
raise KeyError(content_type)
KeyError: '*/*'
```

This is not compliant with valid MIME types defined in RFC2046/section-3, but in real life scenarios, blocking the processing of an incoming email in Odoo because of this might be excessive.

While not a perfect solution, we will assume that attachments falsly reported as `*/*` are to be processed as 'application/octet-stream' content types. This should cover most use-cases, and if it still fails, we will consider that it's up to the original email sender to be RFC compliant.

OPW-5425093

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

Forward-Port-Of: odoo/odoo#242193

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

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

…me tokens greedily.

Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033

This is a hard to reproduce bug because it depends in what order the FORMULA_ALLOWED_TOKENS set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this:

There might be taxes that do a different calculation depending on the base. So for example, we might need to do a formula like this:

(base >= 100) and (base * 0.05) or (base * 0.07)

<img width="1302" height="651" alt="Captura de pantalla 2025-12-26 a la(s) 11 17 02" src="https://github.com/user-attachments/assets/7ce16272-56a4-452b-8eba-e797442f68c2" />

This formula multiplies the base by a certain value depending on whether the base is greater or equal than 100.

This formula will work sometimes, but sometimes, it will fail with this error.

<img width="1302" height="615" alt="Captura de pantalla 2025-12-26 a la(s) 11 18 48" src="https://github.com/user-attachments/assets/5527ff5d-6747-4221-b54f-085e0603aa5a" />

The position of the error is the '=', because the '=' is not a valid token in this list:

https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L10.

The formula is not using just the '=' token in this formula. The formula is using the '>=' token and '>=' is an allowed token. So why this error  appears sometimes?

So here is the important thing and why this bug appears only sometimes: FORMULA_ALLOWED_TOKENS is not a tuple. It is a set. And sets iterate randomly (it is an unordered list). So the loop in this line:

https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L127

sometimes sees the token '>=' first, and sometimes sees the token '>' first in its cycle.

When the '>=' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>=' first so it advances 2 positions. In this scenario, the validation does not fail.

But when the '>' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>' first so it advances 1 position. It has consumed only the '>' of '>='. Now, it will try to match the lone '=' to any of it tokens in the set of allowed tokens, but this '=' will not match any of the allowed tokens, so it will fail.

You can reproduce this bug using the above formula, and restarting Odoo if the error does not appear. Eventually, after restarting, the FORMULA_ALLOWED_TOKENS will have the '>' first and trigger the error.

The important part to understand here is that FORMULA_ALLOWED_TOKENS is unordered, so, the order of the loop is not guaranteed and sometimes this error is triggered and sometimes it is not, depending on the order the loop is done.

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

Forward-Port-Of: odoo/odoo#242661

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

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

## Dependent PR
https://github.com/odoo/enterprise/pull/98463

## Description of the issue/feature this PR addresses:
Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled.

## Current behavior before PR:
When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA.

However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because:

- Settlement orders do not contain any lines, so a new invoice cannot be generated.
- The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice.

Thus, the user cannot proceed with the settlement.

## Desired behavior after PR is merged:
After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment.

task-5144679

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

Forward-Port-Of: odoo/odoo#233769

## Description of the issue/feature this PR addresses:
The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation.

## Current behavior before PR:
When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True.

This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this.

## Desired behavior after PR is merged:
After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. 

task-id - 5144679

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

Forward-Port-Of: odoo/enterprise#98463

Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future

Observation:
--------------------------------
Traceback occurs:
```
  File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
    raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```

Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error

Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.

opw-5438500

…me tokens greedily.

Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033

This is a hard to reproduce bug because it depends in what order the FORMULA_ALLOWED_TOKENS set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this:

There might be taxes that do a different calculation depending on the base. So for example, we might need to do a formula like this:

(base >= 100) and (base * 0.05) or (base * 0.07)

<img width="1302" height="651" alt="Captura de pantalla 2025-12-26 a la(s) 11 17 02" src="https://github.com/user-attachments/assets/7ce16272-56a4-452b-8eba-e797442f68c2" />

This formula multiplies the base by a certain value depending on whether the base is greater or equal than 100.

This formula will work sometimes, but sometimes, it will fail with this error.

<img width="1302" height="615" alt="Captura de pantalla 2025-12-26 a la(s) 11 18 48" src="https://github.com/user-attachments/assets/5527ff5d-6747-4221-b54f-085e0603aa5a" />

The position of the error is the '=', because the '=' is not a valid token in this list:

https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L10.

The formula is not using just the '=' token in this formula. The formula is using the '>=' token and '>=' is an allowed token. So why this error  appears sometimes?

So here is the important thing and why this bug appears only sometimes: FORMULA_ALLOWED_TOKENS is not a tuple. It is a set. And sets iterate randomly (it is an unordered list). So the loop in this line:

https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L127

sometimes sees the token '>=' first, and sometimes sees the token '>' first in its cycle.

When the '>=' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>=' first so it advances 2 positions. In this scenario, the validation does not fail.

But when the '>' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>' first so it advances 1 position. It has consumed only the '>' of '>='. Now, it will try to match the lone '=' to any of it tokens in the set of allowed tokens, but this '=' will not match any of the allowed tokens, so it will fail.

You can reproduce this bug using the above formula, and restarting Odoo if the error does not appear. Eventually, after restarting, the FORMULA_ALLOWED_TOKENS will have the '>' first and trigger the error.

The important part to understand here is that FORMULA_ALLOWED_TOKENS is unordered, so, the order of the loop is not guaranteed and sometimes this error is triggered and sometimes it is not, depending on the order the loop is done.

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

Forward-Port-Of: odoo/odoo#242661

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

In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type.

While trying to parse such content in Odoo, it causes issues with the standard CPython email library, as no standard handler exists for '*/*' content-types:

Example error:
```
File "/usr/lib/python3.13/email/contentmanager.py", line 25, in get_content
raise KeyError(content_type)
KeyError: '*/*'
```

This is not compliant with valid MIME types defined in RFC2046/section-3, but in real life scenarios, blocking the processing of an incoming email in Odoo because of this might be excessive.

While not a perfect solution, we will assume that attachments falsly reported as `*/*` are to be processed as 'application/octet-stream' content types. This should cover most use-cases, and if it still fails, we will consider that it's up to the original email sender to be RFC compliant.

OPW-5425093

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

Forward-Port-Of: odoo/odoo#242193

Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos.

Steps to reproduce:
-------------------
* Set max closing difference as 0
* Have 1 admin user and 1 pos user
* Have 2 employees
* Set admin user and employee 1 as advanced employees of the pos
* Set pos user and employee 2 as basic employees

Steps with admin:
* Make sure you are logged as the admin in the database
* Open pos (could be a session opened by other user)
* Log in with Admin user
* Try to close the pos with a difference of 10 -> You can, ok
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You ca but shouldn't

Steps with pos user
* Now log in the database as pos user
* Open pos (could be a session opened by other user
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You cannot, ok
* Log in with Admin user
* Try to close the pos with a difference of 10 -> you cannot but should

Why the fix:
------------
Employees that have no linked user should not ba able to override the max difference.

Employees who have a connected user should only be able to override the max difference if their user is admin of the pos.

opw-5184041

Forward-Port-Of: odoo/odoo#241151
Forward-Port-Of: odoo/odoo#235356

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

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

# Bug 1:
## Steps to reproduce:
- Create an overtime ruleset and add rules.
- Disable "Pay extra hours" on all rules in the ruleset.
- Assign this ruleset to an employee.
- Create an attendance that normally generates overtime.
- Navigate to the work entries in payroll.
- Overtime work entries are created!

This fix will skip generating work entries when their will be no `paid` rules in
a ruleset.

# Bug 2:
## Steps to reproduce:
- Create attendances with overtime for multiple consecutive days.
- Navigate to Work Entries in Payroll.
- Click on Reset->"Regenerate Work Entries” on the same period for
bulk regeneration.
- Observe that attendance and overtime hours are shifted between days.

### Fix:
In `_get_overtime_intervals`, the overtime list was recreated inside
the per-day loop, causing previously computed overtime intervals to be lost
when multiple days were involved.
Overtime intervals are now accumulated per resource across all days in the
requested range before building the final Intervals.

task - [5189151](https://www.odoo.com/odoo/project/1251/tasks/5189151)

Situation
-----
When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1054

because of the `m.location_id == move.location_final_id` part being false in

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1090-L1097

This is because, during the merge, `location_final_id` is not propagated to the new MO

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L2416-L2424

so when the new MO's `move_finished_id` gets computed

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L822

it gets the MO's `location_final_id`

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L1202

which is false. This leads to to the move getting the warehouse's default stock location thanks to

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/mrp/models/stock_move.py#L456-L457

This is problematic for complex use cases with multi-locations and custom routes.

It should be safe to propagate the `location_final_id` of the merged MOs if they all share the same one.

Use case example
-----
<details>
<summary>Full use case</summary>

- Enable multi-step routes
- Create location "WH/Stock/L1"
- Create location "WH/Stock/L2"

- Create Operation Type "MO child"
	- Type of Operation: Manufacturing
	- Sequence Prefix: MOCHILD
	- Source Location: L1
	- Destination Location: L2
- Create Operation Type "Push Transfer"
	- Type of Operation: Internal Transfer
	- Sequence Prefix: L2L1
	- Source Location: L2
	- Destination Location: L1
- Create Route "MO child"
	- Create Rule "Manufacture"
		- Action: Manufacture
		- Operation Type: MO child
		- Source Location: False
		- Destination Location: Stock
- Create Route "2-step"
	- Warehouse: Main WH
	- Create Rule "L1 -> Virtual/Production"
		- Action: Pull from
		- Operation Type: MO child
		- Source Location: L1
		- Destination Location: Virtual/Production
	- Create Rule "Push: L2 -> L1"
		- Action: Push To
		- Operation Type: Push Transfer
		- Source Location: L2
		- Destination Location: L1
- Unarchive MTO
- Edit MTO route
	- Create Rule "L1 -> Virtual/production (MTO)"
		- Action: Pull
		- Operation Type: "My Company: Manufacturing"
		- Source Location: L1
		- Destination Location: Virtual/Production
		- Supply Method: Trigger another rule
- Create product "Main product"
- Create product "Child product"
	- Routes: "MO child" & MTO
- Create product "Material" (consumable)
- Create BOM
	- Product: "Main product"
	- Component: "Child product"
- Create BOM
	- Product: "Child product"
	- Component: "Material"
- Create MO for "Main product"
	- Misc/Component Location set to L1
- Duplicate the MO
- Merge child MOs & produce
- Validate merged MO transfer to L1
- Go back to one of the "Main product" MO

> Component quantity is 0
</details>

-----
Ticket:
opw-5144196

Forward-Port-Of: odoo/odoo#242373
Forward-Port-Of: odoo/odoo#240695

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

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

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 computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines.

Solution:
We will convert the component cost to the invoice currency when computing price difference.

Steps to reproduce (runbot 18):
- Product with
	- Standard price auto
	- BoM: sbc, one component with nonzero value (e.g. $1)
	- Nonzero value (e.g. $5)
- Another currency
1. Create a PO for the subcontracted product
2. Set the Invoice currency to something other than the company default
3. Confirm the PO and validate the sbc and receipt
4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency)

A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference.

opw-5232917

## How to reproduce:
- Enable Wave transfert in setting
- Go to the Receipt Operation type:
    - Create Backorder: always
    - Automatic Batches: Enabled
    - Wave Grouping: Products
- Create and confirm (don't validate) 2 Receipts for 10 units of a storable product P
- The 2 receipt should have been added to a new wave transfer with 2 lines for P
- On the first line, set the quantity to 0
- On the second line, set the quantity to 1
- Try to validate the wave transfer ==>> UserError "The following transfers cannot be added to batch transfer WAVE/XXXX. Please check their states and operation types."

## Issue:
Backorders are generated before the current batch is marked 'done' (it waits for empty pickings to be detached). The auto-batch logic incorrectly identifies the current 'in_progress' batch as a candidate for the new backorders, attempting a merge that violates validation constraints.

## Solution:
Exclude the current wave/batch from the auto_wave search domain using a context variable passed during validation.

OPW-5413921

---

Test result before fix:
```
2026-01-13 10:37:26,541 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: Starting TestAutoWaving.test_auto_wave_skip_current_batch ... 
2026-01-13 10:37:26,820 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ====================================================================== 
2026-01-13 10:37:26,820 27952 ERROR oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ERROR: TestAutoWaving.test_auto_wave_skip_current_batch
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/tests/test_auto_waving.py", line 440, in test_auto_wave_skip_current_batch
    wave.action_done()
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 264, in action_done
    return pickings.with_context(**context).button_validate()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 145, in button_validate
    res = super().button_validate()
          ^^^^^^^^^^^^^^^^^^^^^^^^^
...
  File "/home/odoo/Odoo/src/18.0/odoo/odoo/fields.py", line 1418, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 112, in write
    self.batch_id._sanity_check()
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 323, in _sanity_check
    raise UserError(_(
odoo.exceptions.UserError: The following transfers cannot be added to batch transfer WAVE/00012. Please check their states and operation types.
```

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

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>