Odoo Changelog — 2026-01-14

Wednesday, January 14, 2026

28 changes · saas-18.2

Bug Fixes(28)

Resolved issues and error corrections

[FIX] l10n_it_pos: allow printing receipt with multiple payment methods

Enterprisesaas-18.2l10n_it_posMEDIUM

This update resolves an issue preventing users in the l10n_it_pos module from printing receipts when multiple payment methods were used. The change backports a fix from another Odoo project, ensuring accurate receipt generation for Italian Point of Sale transactions. This improves the user experience and compliance with fiscal requirements.

Original PR description

Backports of https://github.com/odoo/enterprise/pull/96353.

References: See page 36 in the [official docs](https://download4.epson.biz/sec_pubs/bs/pdf/ePOS%20Fiscal%20Print%20Solution%20Development%20Guide%20Rev%20T.pdf).

Ticket [link](https://www.odoo.com/odoo/project.task/5376242)
opw-5376242

Forward-Port-Of: odoo/enterprise#103710

#pos#it#receipt#payment

[FIX] sale_shopee: fix testing environment API path

PR #104099

Enterprisesaas-18.2sale_shopeeMEDIUM

This update corrects a critical issue with the Odoo Enterprise system's testing environment for Shopee integration. Shopee recently altered their API paths, rendering the previous testing configurations invalid. This fix ensures the testing environment accurately reflects the current Shopee API, maintaining reliable testing and development.

Original PR description

Shopee has changed the API path and the original testing API paths are no longer valid.

Forward-Port-Of: odoo/enterprise#103939

#Shopee#API#Testing#Integration

[FIX] mrp: propagate location_final_id when merging MOs

PR #242348

Coresaas-18.2mrpMEDIUM

This update resolves an issue where the location of merged manufacturing orders wasn't correctly linked to subsequent transfer orders. The fix ensures that the final location of merged MOs is accurately propagated, preventing incorrect stock movements and improving the reliability of multi-location workflows. This primarily impacts complex manufacturing processes.

Original PR description

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…

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

#manufacturing#stock#merging

[FIX] web: close_on_report_download works when using a custom handler

PR #242045

Coresaas-18.2web

This update resolves an issue where printing reports using custom handlers (like IoT) didn't automatically close the associated wizard. Previously, the wizard remained open, leading to unexpected behavior. Now, the system correctly closes the wizard after a report download, regardless of the handler used.

Original PR description

Problem:
When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open.

Steps to Reproduce:
- Go to "Acoustic Bloc Screens" product and click "Print Labels"
- Select "ZPL labels" and confirm
- The report downloads and the wizard closes as expected
- Go to Settings > Technical > Reports and select "Product Label (ZPL)"
- Set an IoT device on the report
- "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes
- Refresh the page, and try printing again
- The wizard stays open (wrong) and the IoT toasts appear

Solution:
When returning from the custom handler, check if close_on_report_download and close the wizard.

opw-5153139

Forward-Port-Of: odoo/odoo#238247

#reporting#iot#wizard

[FIX] portal_rating, *: display rating card if it's requested

PR #243495

Coresaas-18.2portal_rating

This update ensures that rating cards are only shown in portal chatter when a module specifically requests them. Previously, rating cards were displayed even when a module didn't explicitly enable the feature, leading to a cluttered user experience. This change improves the portal's clarity and focus.

Original PR description

*: test_mail_full

Modules using portal rating can set an `data-display_rating` attribute when calling the portal chatter template to indicate whether they want the rating feature displayed. Currently, only two modules have this attribute set to true: ecommerce and elearning. For other modules that don't set this attribute, even if there is a rating, such as when rating a ticket in the helpdesk module, we don't want the rating card feature to be shown in portal chatter. This change ensures that the feature is only available if the module requests it.

task-5347848

Forward-Port-Of: odoo/odoo#243255

#portal#rating#user experience

[FIX] mail: handle wildcard content-type

PR #243680

Coresaas-18.2mail

This update resolves an issue where Odoo encountered errors when processing emails with attachment content types incorrectly identified as '*/*'. To ensure emails are processed smoothly, the system now defaults to 'application/octet-stream' for these cases, minimizing disruption. The change is a temporary workaround until email senders consistently adhere to standard MIME types.

Original PR description

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…

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

#email#attachments#compatibility

[FIX] portal: link preview triggering page view

PR #243625

Coresaas-18.2mailsale

This update resolves an issue where clicking a link in the Odoo portal triggered a false 'page view' event for customers. A simple change was made to the request headers to accurately track link clicks. This ensures that customer page views are recorded correctly, improving reporting and analytics.

Original PR description

When a link to the portal is sent from the chatter via message or log note, the preview of the link triggers that the page was viewed by customer.

As a solution a variable was added to the request headers coming from the previewer.

opw-5237785


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

Forward-Port-Of: odoo/odoo#243061

#portal#link tracking#customer analytics

[FIX] portal_rating: default options for admin users

PR #243314

Coresaas-18.2portal_ratingwebsite_slides

This update corrects a potential issue where admin users could inadvertently modify course ratings by editing or deleting other users' messages. The change ensures that default rating options remain consistent for admin users, maintaining the integrity of course evaluations. This prevents unintended alterations to course data.

Original PR description

*: website_slides

The default values for the admin user should not be changed by editing or deleting others' messages in courses.

task-5326273

Forward-Port-Of: odoo/odoo#236475

#ratings#course#admin

[FIX] account_reports: prevent crash on integer rounding with None value

PR #104198

Enterprisesaas-18.2account_reports

This update resolves an issue where enabling integer rounding on Aged Receivable reports would cause a crash. The fix prevents the system from attempting calculations with 'None' values, which were triggering an error. This ensures reports function correctly regardless of rounding settings.

Original PR description

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…

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

#reporting#accounting#stability

[FIX] account: invoice currency rate manually changed

PR #243126

Coresaas-18.2accountMEDIUM

This update resolves an issue where manually changed currency rates on invoices weren't correctly applied, leading to data loss. The fix now only recalculates rates if the user hasn't modified them, ensuring accurate invoice calculations and preventing data overwrites. This improves the reliability of financial reporting.

Original PR description

in case the user would enter manually a different rate than the default one, but does not fill the invoice date; odoo was setting today as the invoice date, which was changing the rate and recomputing all the lines... Effectively losing everything the user just encoded.

So now, we only recompute the rate and the lines if the user didn't change it.

Fix: https://github.com/odoo/odoo/pull/226124/changes/1b48d141d7260a262075555c4ab9cedc691d3551

Issue with Fix: Invoices posted on dates different from their creation date do not update their currency rates, even though they should.

Comparing `invoice_currency_rate` to the expected rate at creation is a better guess.

task-5477481


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

Forward-Port-Of: odoo/odoo#242800

#currency#invoice#rates#accounting

[FIX] pos_l10n_se: fix saving blackbox details to order

PR #104218

Enterprisesaas-18.2pos_l10n_se

This update resolves a technical problem preventing the correct saving of order details (blackbox data) for the Swedish point-of-sale system. The fix ensures that this critical data is properly recorded in the database, improving data accuracy and reporting. It also includes updates for compatibility with new IoT box images.

Original PR description

In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB.

This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image.

opw-5253585

Forward-Port-Of: odoo/enterprise#104180

#POS#Sweden#Data Integrity

[FIX] l10n_sa_edi_pos: skip forced zatca invoice for settlement due

PR #243604

Coresaas-18.2l10n_sa_edi_pospoint_of_saleMEDIUM

This update resolves an issue where users were blocked from settling customer balances in Point of Sale when ZATCA integration was active. The fix removes the forced invoice requirement for settlement orders, allowing users to complete payments without generating unnecessary e-invoices to ZATCA.

Original PR description

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

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

#ZATCA#POS#Settlement#Invoice

[FIX] pos_settle_due: reset is_settling_account on settlement cancel

PR #104197

Enterprisesaas-18.2posMEDIUM

This update resolves an issue where the 'is_settling_account' flag remained true after a Point of Sale user cancelled a 'Settle Due' payment. This prevented normal sales from being processed correctly, potentially causing errors and bypassing important accounting rules. The fix now ensures the flag is reset to false, allowing for proper order processing.

Original PR description

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

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

#pos#settlement#order processing

[FIX] l10n_hr_edi: Incorrect credentials error handling

PR #243715

Coresaas-18.2l10n_hr_edi

This update fixes a problem where incorrect credentials caused misleading error messages when sending invoices. The change adds a test to ensure the correct error is displayed, improving the user experience and preventing confusion. This ensures invoices are processed correctly and reduces potential delays.

Original PR description

Fixing incorrect error display that occurred while trying to send an invoice to MER with incorrect credentials set up.
(no task/error ID)

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

Forward-Port-Of: odoo/odoo#243489

#invoice#error handling#credentials

[FIX] hr_payroll: prevent traceback on payroll rule parameter

PR #102924

Enterprisesaas-18.2hr_payroll

This update resolves an issue where creating payroll rule parameters with future dates could trigger an error. The fix initializes computed fields to a default value, ensuring correct calculations regardless of the date used. This prevents unexpected compute errors and improves the stability of payroll processing.

Original PR description

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…

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

#payroll#configuration#rule parameters

[FIX] account_tax_python: fix _check_formula because it doesn't consu…

PR #242761

Coresaas-18.2account_tax_python

This update resolves a sporadic error in tax calculations that stemmed from how Odoo processes formulas. The issue was caused by the random order in which a set of allowed tokens is iterated, leading to inconsistent formula evaluation. This fix ensures more reliable tax calculations.

Original PR description

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

…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

#tax#calculation#bug fix

[FIX] pos_loyalty: allow pricelist restriction on loyalty programs

PR #243627

Coresaas-18.2pos_loyaltyMEDIUM

This update fixes an issue where loyalty programs with pricelist restrictions weren't properly considered during POS transactions. Previously, if a POS session's pricelist didn't match a loyalty program's restrictions, the loyalty program would still be applied. Now, the system correctly checks pricelist compatibility, ensuring loyalty programs are only applied when the session's pricing aligns with the program's rules.

Original PR description

Before this commit, if a loyalty program had pricelist restrictions, the POS would not consider them when loading the applicable loyalty programs. This could lead to scenarios where a loyalty program was applied in a POS session even if the session's pricelist was not allowed by the program. This happened when the pricelist was also not available in the POS configuration and program.pricelist_ids was empty.

opw-5467990

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

Forward-Port-Of: odoo/odoo#242279

#loyalty programs#pricing#POS

[FIX] l10n_co_dian: use the latest number range

PR #104044

Enterprisesaas-18.2l10n_co_dianMEDIUM

This update fixes an issue where the system was incorrectly using outdated number ranges when syncing data with DIAN. Previously, the system didn't properly check for the latest available ranges, leading to errors when clients requested new ranges. This ensures accurate DIAN data synchronization for our Colombian clients.

Original PR description

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

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

#DIAN#number_range#co-dian

[FIX] mail: remove correspondent for group type channels

PR #243628

Coresaas-18.2mail

This update resolves an issue where group channels (DMs with fewer than 3 members) were displaying incorrect information, such as a 'back on' banner and an IM status. The fix prevents the system from incorrectly identifying these channels, resulting in a more accurate and consistent user experience.

Original PR description

Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members.

This would lead to various confusing behaviours, including:
1. The "back on" banner being shown.
2. The chat bubble showing an IM status.
3. The notification item not showing the message author's name.

This commit fixes the issues by not computing `correspondent` for channels of type group.

task-5462395

Forward-Port-Of: odoo/odoo#242058

#discuss#messaging

[FIX] hr_recruitment: fix demo data

PR #243691

Coresaas-18.2hr_recruitment

This update resolves a technical issue where demo data for the recruitment module was incorrectly referencing user records instead of partner records. This fix ensures the demo data accurately reflects the expected data structure, improving the usability and reliability of the recruitment demo.

Original PR description

author_id expects a res.partner record.

In this commit:
  Replace the user record with the corresponding partner record to avoid passing an incorrect recordset in demo data.

Forward-Port-Of: odoo/odoo#241260

#demo#recruitment#data

[FIX] hr_attendance: Bug with officer group when try to change employee for attendance

PR #243692

Coresaas-18.2hr_attendanceMEDIUM

This update resolves an issue where users could incorrectly save attendance records after attempting to change the associated employee. The fix ensures that only authorized users can update attendance records, improving data integrity and preventing potential errors. Test coverage has been added to confirm this change.

Original PR description

Closes [odoo/odoo#226007](https://github.com/odoo/odoo/issues/226007).

Description of the issue/feature this PR addresses:
Prevents a user from updating their attendance record by changing the employee to the one whose attendance is not managed by the current user.

Current behavior before PR:
- Assign the Officer Group of Attendance group to a user.
- Assign the user as the attendance manager of itself.
- Login with that user.
- Create an attendance record for the employee and save it.
- Try to change the employee and save; an error will be thrown as expected.
- Go to the Attendance menu; the record will still be saved.

Desired behavior after PR is merged:
This commit ensures that un-allowed write does not take place + test coverage added.



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

Forward-Port-Of: odoo/odoo#243573
Forward-Port-Of: odoo/odoo#226335

#attendance#employee management

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #243756

Coresaas-18.2spreadsheet

This pull request updates the core spreadsheet component within Odoo. It addresses several minor bugs and improves performance related to calculations and sheet selection, ensuring a smoother user experience. This update was made by a team of developers to maintain the stability and functionality of the spreadsheet feature.

Original PR description

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

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

#spreadsheet#performance#stability

[FIX] website: only update menu on page creation if the menu has no page

PR #243592

Coresaas-18.2website

This update fixes an issue where menu entries were incorrectly updating across multiple pages with the same name. Now, menu entries are only updated when a new page is created, preventing confusion and ensuring accurate page linking. This improves the consistency of the website navigation.

Original PR description

With commit 19302cd40347065fcd937bd54e6dce27fe4940cc, when a page is created, menu entries with a url corresponding to the created page are updated to set their `page_id` to the new page.

The update may also be triggered when creating several pages with the same name in a row.

This commit updates a menu entry on page creation only if no page were already associated to the menu.

Steps to reproduce:
- Create a new page, call it "test" (will be available on `/test`)
- Create a new page, call it "test" (will be available on `/test-1`)
- Go to editor menu
- Bug: both entries point to `/test-1`
- Create a new page, call it "test" (will be available on `/test-2`)
- Go to editor menu
- Bug: the first one (and the new one) is pointing now to `/test-2`

task-5186653

Forward-Port-Of: odoo/odoo#243312

#website#navigation#pages

[FIX] l10n_ch_hr_payroll_elm_transmission: Use reference_date when locking period

PR #104271

Enterprisesaas-18.2l10n_ch_hr_payrollMEDIUM

This update corrects a potential issue with the transmission of Swiss payroll data (ELM) by ensuring the correct reference date is used when locking payroll periods. This improves the accuracy of data sent to tax authorities, reducing the risk of errors and potential delays in processing. The change is a technical fix focused on data integrity.

Original PR description

Forward-Port-Of: odoo/enterprise#104269

#payroll#Switzerland#ELM#tax

[FIX] account: fix invoice_origin missed in reverse move

PR #243644

Coresaas-18.2accountMEDIUM

This update resolves an issue where the 'Source Document' field was missing when reversing invoices. This meant critical information about the original invoice wasn't accurately reflected in the reversed transaction. The fix ensures that the 'Source Document' field correctly displays the original invoice details during reverse moves, improving data accuracy and reporting.

Original PR description

### Issue:
Reverse moves miss `invoice_origin` field.

#### To reproduce:
1- Create a SO.
2- Create an invoice and confirm.
3- In invoice list view make the `Source Document` visible.
4- Create a credit note and reverse the move.

From invoice list view, you can observe that `Source Document` is empty for reverse move.

### Cause:

This is a regression introduced by #236656.

opw-5362055

Forward-Port-Of: odoo/odoo#240439

#invoice#reverse#accounting

[FIX] account_followup: followup_status checks amount_residual

PR #104229

Enterprisesaas-18.2account_followupMEDIUM

This update corrects a bug where customer statements incorrectly showed no outstanding amounts after partial invoice payments. The fix ensures the system accurately considers both reconciled and unreconciled balances when determining follow-up actions for invoices. This improves the accuracy of customer statements and reporting.

Original PR description

**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…

**Steps to Reproduce:**

1. Create an invoice with a due date 20 days prior and an amount of $100
2. Create a payment of 120$
3. Create an invoice of 100$
4. Reconcile the second invoice with the payment
5. Go to the customer record.
6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed".

[Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing)

**Cause:**
- The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404)
- In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due.

**Solution:**
Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679)

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

Forward-Port-Of: odoo/enterprise#101874

#accounting#customer statements#follow-up

[FIX] mrp_subcontracting_purchase: use invoice currency when computing price difference on subcontracted products

PR #243801

Coresaas-18.2mrp_subcontracting_purchaseMEDIUM

This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. Now, the system automatically converts component costs to the invoice currency, ensuring accurate price difference calculations and preventing erroneous invoice lines.

Original PR description

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…

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

Forward-Port-Of: odoo/odoo#238428

#subcontracting#price difference#currency

[IMP] l10n_co_dian, l10n_mx_edi: Modifications for Self-Billing backport

PR #103788

Enterprisesaas-18.2l10n_co_dianl10n_mx_edi

This update simplifies the process of generating UBL invoices for Colombia and Mexico by streamlining internal code. Specifically, the order of customer and supplier information in vendor bills has been automatically corrected, and the underlying code has been refactored for easier future modifications. This ensures consistent and accurate UBL invoice generation.

Original PR description

For the Self-billing backport, we made two modifications which entail a small change in the l10n_co_dian and l10n_mx_edi code:

- `_check_move_constrains` has been refactored to call a new `_get_move_constraints` method, which is more easily extensible. We perform the same modification in l10n_mx_edi. Note `_check_move_constrains` is still there, so any overrides will still work.
- The customer and supplier are now swapped by default when exporting a vendor bill UBL, so it's no longer needed to do this specifically for the DIAN UBL.

Community PR: https://github.com/odoo/odoo/pull/232548
Backport of https://github.com/odoo/enterprise/pull/92205

task-5153851

Forward-Port-Of: odoo/enterprise#97803

#ubl#dian#edi#invoice