Odoo Changelog — 2026-01-06

Tuesday, January 6, 2026

9 changes · saas-18.2

Bug Fixes(9)

Resolved issues and error corrections

[FIX] l10n_din5008: print incoterms on DIN5008 invoice layout

PR #242027

Coresaas-18.2l10n_din5008Medium

This update fixes an issue where DIN5008 invoices weren't showing Incoterm information. The fix adds the necessary logic to include Incoterm data in the report, ensuring compliance with DIN5008 standards. This ensures accurate invoice reporting for international transactions.

Original PR description

**Steps to reproduce:**

1. Install the modules account and l10n_din5008.
2. Go to Settings and set DIN5008 as the default invoice report template.
3. Navigate to Configuration → Settings and set a default Incoterm.
4. Create a new customer invoice.
5. Print the DIN5008 Invoice Report.

**Issue:**
The DIN5008 invoice report did not display the Incoterms, while other invoice layouts printed them correctly.

**Cause:**
This was due to missing logic in l10n_din5008 report to include Incoterm data. Confirmed with TSB that the DIN5008 layout should display Incoterms.

**Fix:**
This commit adds the Incoterm information to the DIN5008 template data:
- Always include the Incoterm code
- If an Incoterm location is set, display it as `CODE - LOCATION`

**opw-5349267**

Forward-Port-Of: odoo/odoo#240688
Forward-Port-Of: odoo/odoo#238682

#invoice#incoterms#din5008

[FIX] payment_stripe: enable stripe connect for french territories

PR #242104

Coresaas-18.2payment_stripeMedium

This update resolves an issue preventing customers in French territories (like La Réunion) from using Stripe Connect. The change adjusts how the system identifies country support for Stripe, aligning with Stripe's policies for these regions. This ensures all Odoo users, regardless of location, can utilize Stripe payments.

Original PR description

## Versions
17.0+

## Issue
Customers located in French territories (e.g. La Réunion) can't use Stripe Connect.

## Steps to reproduce
*Ensure Stripe payment provider is installed*
- From the Settings' app, access your company's data:
  - Change your company's country for "Réunion".
- Go to Payment Providers and open Stripe:
  - Try to enable Stripe via Stripe Connect;
  - A message tells you your country is not supported by Stripe.

## Cause
Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries).
This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow.

opw-5421185

Forward-Port-Of: odoo/odoo#241269

[FIX] l10n_ch_hr_payroll_elm_transmission: Fix retroactive update of snapshots

PR #103278

Enterprisesaas-18.2l10n_ch_hr_payrollMedium

This update allows payslips to accurately reflect employee data from previous years, resolving an issue where only current year snapshots were used. Enabling retroactive updates ensures correct payroll reporting and compliance with Swiss regulations. This change impacts the HR Payroll module.

Original PR description

Currently employee data only updates current year snapshots, which can be an issue
when generating payslips for previous years, in this PR we enable retroactive updates
by changing the mecanism. The new mecanism updates snapshots of the payslip years, making
a reference date usage possible.

Forward-Port-Of: odoo/enterprise#103147

#payroll#reporting#Switzerland#HR

[FIX] pos_sale: Manage products paid on ecommerce in the POS

PR #233851

Coresaas-18.2pos_saleMedium

This update ensures that payments made on the website for ecommerce orders are correctly reflected in the POS. Now, the POS automatically recognizes and accounts for previously paid amounts, preventing duplicate payments and simplifying the checkout process. Fully paid orders will no longer appear in the POS, allowing invoices to be created through the standard Odoo Sale app.

Original PR description

Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the…

Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment.

Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices).

Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo.

Task-5187602
Original Task-5138081

Backport-[#230809](https://github.com/odoo/odoo/pull/230809)

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

Forward-Port-Of: odoo/odoo#232841

[FIX] pos_sale: Manage products paid on ecommerce in the POS

PR #98498

Enterprisesaas-18.2pos_saleMedium

This update fixes a problem where payments made on the website weren't correctly reflected in the POS. Now, the POS automatically recognizes and accounts for payments made through ecommerce, creating down payment lines and preventing duplicate payments. This ensures accurate order totals and simplifies the payment process for users.

Original PR description

Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the…

Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment.

Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices).

Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo.

Task-5187602
Community PR-[#232841](https://github.com/odoo/odoo/pull/232841)

Backport-[#96876](#https://github.com/odoo/enterprise/pull/96876) Original Task-5138081

Forward-Port-Of: odoo/enterprise#98029

[FIX] mrp: unlink irrelevant move raws on bom update

PR #242093

Coresaas-18.2mrpMedium

This update fixes an issue where modifying a product's Bill of Materials (BOM) didn't properly remove associated move raw materials from the manufacturing order. The change ensures that move raw records are correctly updated and removed when the BOM is modified, preventing data inconsistencies in production planning. This improves the accuracy of inventory management.

Original PR description

### Steps to reproduce:

- Create a bom for a product with 2 component lines:
    - 1 x COMP1
    - 1 x COMP2
- Create an MO for your product (do not confirm it)
- Delete the second bom line of the bom
- On the draft MO, click on `update bom`
#### > This automatically modifies the `move_raws` of the MO but the un-linked move raws were neither deleted nor cancelled as shown by the move analysis

### Cause of the issue:

Clicking on `update bom` will launch a call of the `action_update_bom` which will itself call the `_link_bom` to update the record: https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418 Now the issue is that the `bom_id` is set to `False` before the value of the `move_raw_ids` and `workorder_ids` are stored to be unlinked in the `moves_to_unlink` and `workorders_to_unlink` variable. Now, the issue is that the `bom_id` is a dependency of both compute methods: https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L745-L746 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L563-L564 in particular, `moves_to_unlink` will always be an empty record set and the value of the `workorders_to_unlink` might be unreliable.

opw-5243203

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

Forward-Port-Of: odoo/odoo#239654

[FIX] pos_online_payment: prevent multiple online pm per POS config

PR #240343

Coresaas-18.2pos_online_paymentMedium

This update resolves a bug that prevented users from opening new POS sessions when multiple online payment methods were associated with a single POS configuration. The fix ensures only one online payment method can be linked to a POS config, preventing session conflicts and improving the user experience. A constraint was added to the payment method model to enforce this rule.

Original PR description

Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237)

---

There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are configured for the same POS config. However, from the `pos.payment.method` model, it is still possible to add multiple online payment methods to a single POS config, which then prevents opening a session.

In addition, if a session is already open, it is no longer possible to resolve the situation:

* From `pos.payment.method`: the POS session must be closed before removing the POS config from an online payment method.
* From `pos.config`: the payment methods field is read-only when there is an open session.

We had to delete one of the online payment methods from the database directly to be able to open the POS session again.

To prevent this inconsistent state, a constraint is added on `pos.payment.method` to ensure that each POS config has at most one online payment method.

[PERF] sale_subscription: fix memory error when running cron

PR #102699

Enterprisesaas-18.2saleaccountMedium

This update resolves a memory error that occurred when processing recurring invoices with a large number of subscriptions. By optimizing how the system retrieves data, the change significantly reduces memory consumption, preventing crashes and improving overall system stability. This results in faster invoice processing and a more reliable Odoo Enterprise experience.

Original PR description

A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the…

A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError.

This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets.

#### Benchmark

In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB.

<img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" />

<img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" />

Forward-Port-Of: odoo/enterprise#102364

[FIX] sale_pdf_quote_builder: allow extra documents on confirmed orders

PR #235778

Coresaas-18.2sale_pdf_quote_builderMedium

This update fixes an issue where product documents weren't being included in PDF quotes after they were confirmed. Previously, the system ignored these documents. Now, a new configuration setting allows users to ensure that all selected documents are always included in the PDF, regardless of whether the order is confirmed.

Original PR description

Versions
--------
- saas-18.2+

Steps
-----
1. Add product documents, headers or footers to a quotation;
2. confirm quotation;
3. print quotation.

Issue
-----
Extra documents aren't added to the PDF, even though they show up as selected in the quotation builder.

Cause
-----
As of commit b02f53d, any quotation documents linked to a sales order are simply ignored for confirmed orders.

Solution
--------
Add a `sale.always_include_selected_documents` config parameter, allowing users to keep including the selected documents on confirmed orders.

opw-5242743

#sales#quotes#pdf#documents

**Steps to reproduce:** 1. Install the modules account and l10n_din5008. 2. Go to Settings and set DIN5008 as the default invoice report template. 3. Navigate to Configuration → Settings and set a default Incoterm. 4. Create a new customer invoice. 5. Print the DIN5008 Invoice Report. **Issue:** The DIN5008 invoice report did not display the Incoterms, while other invoice layouts printed them correctly. **Cause:** This was due to missing logic in l10n_din5008 report to include Incoterm data. Confirmed with TSB that the DIN5008 layout should display Incoterms. **Fix:** This commit adds the Incoterm information to the DIN5008 template data: - Always include the Incoterm code - If an Incoterm location is set, display it as `CODE - LOCATION` **opw-5349267** Forward-Port-Of: odoo/odoo#240688 Forward-Port-Of: odoo/odoo#238682

## Versions 17.0+ ## Issue Customers located in French territories (e.g. La Réunion) can't use Stripe Connect. ## Steps to reproduce *Ensure Stripe payment provider is installed* - From the Settings' app, access your company's data: - Change your company's country for "Réunion". - Go to Payment Providers and open Stripe: - Try to enable Stripe via Stripe Connect; - A message tells you your country is not supported by Stripe. ## Cause Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries). This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow. opw-5421185 Forward-Port-Of: odoo/odoo#241269

Currently employee data only updates current year snapshots, which can be an issue when generating payslips for previous years, in this PR we enable retroactive updates by changing the mecanism. The new mecanism updates snapshots of the payslip years, making a reference date usage possible. Forward-Port-Of: odoo/enterprise#103147

Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5187602 Original Task-5138081 Backport-[#230809](https://github.com/odoo/odoo/pull/230809) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232841

Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5187602 Community PR-[#232841](https://github.com/odoo/odoo/pull/232841) Backport-[#96876](#https://github.com/odoo/enterprise/pull/96876) Original Task-5138081 Forward-Port-Of: odoo/enterprise#98029

### Steps to reproduce: - Create a bom for a product with 2 component lines: - 1 x COMP1 - 1 x COMP2 - Create an MO for your product (do not confirm it) - Delete the second bom line of the bom - On the draft MO, click on `update bom` #### > This automatically modifies the `move_raws` of the MO but the un-linked move raws were neither deleted nor cancelled as shown by the move analysis ### Cause of the issue: Clicking on `update bom` will launch a call of the `action_update_bom` which will itself call the `_link_bom` to update the record: https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418 Now the issue is that the `bom_id` is set to `False` before the value of the `move_raw_ids` and `workorder_ids` are stored to be unlinked in the `moves_to_unlink` and `workorders_to_unlink` variable. Now, the issue is that the `bom_id` is a dependency of both compute methods: https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L745-L746 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L563-L564 in particular, `moves_to_unlink` will always be an empty record set and the value of the `workorders_to_unlink` might be unreliable. opw-5243203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239654

Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237) --- There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are configured for the same POS config. However, from the `pos.payment.method` model, it is still possible to add multiple online payment methods to a single POS config, which then prevents opening a session. In addition, if a session is already open, it is no longer possible to resolve the situation: * From `pos.payment.method`: the POS session must be closed before removing the POS config from an online payment method. * From `pos.config`: the payment methods field is read-only when there is an open session. We had to delete one of the online payment methods from the database directly to be able to open the POS session again. To prevent this inconsistent state, a constraint is added on `pos.payment.method` to ensure that each POS config has at most one online payment method.

A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError. This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets. #### Benchmark In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB. <img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" /> <img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" /> Forward-Port-Of: odoo/enterprise#102364

Versions -------- - saas-18.2+ Steps ----- 1. Add product documents, headers or footers to a quotation; 2. confirm quotation; 3. print quotation. Issue ----- Extra documents aren't added to the PDF, even though they show up as selected in the quotation builder. Cause ----- As of commit b02f53d, any quotation documents linked to a sales order are simply ignored for confirmed orders. Solution -------- Add a `sale.always_include_selected_documents` config parameter, allowing users to keep including the selected documents on confirmed orders. opw-5242743