Odoo Changelog — 2026-05-22

Friday, May 22, 2026

4 changes · 17.0

Bug Fixes(4)

Resolved issues and error corrections

[FIX] l10n_ke_edi_oscu: fix sending invoice having line w/ long descr.

Enterprise17.0l10n_ke_edi_oscuMEDIUM

This update resolves an issue where invoices with excessively long item descriptions were being rejected by the eTIMS system. The fix truncates descriptions to meet the 200-character limit specified by eTIMS, ensuring successful invoice submission and avoiding delays in customs processing. This improves compliance with eTIMS regulations.

Original PR description

The eTIMs specification limit the `itemNm` to 200 characters, so truncate the invoice line description to that limit to ensure that the invoice can be correctly submitted eTIMS server. Otherwise it will be rejected with:

```
Error sending to the KRA:
- Request parameter error[<ItemList><itemNm>: length must be
  between 0 and 200]
```

Task-Id: 5220129

#eTIMS#invoice#Kenya

[FIX] website_sale: allow payment on branch shop with parent provider

PR #263869

Core17.0website_saleMEDIUM

This update resolves an issue preventing orders from being confirmed on branch company websites after payment. The fix addresses a conflict between company affiliations within the payment system, ensuring orders are properly processed and reflected in the backend, even after manual confirmation.

Original PR description

Version:
---
17.0+

Issue:
---
Due to this issue, the orders are never confirmed on branch company website once payment is done.

### Steps to reproduce:
1- Create a branch company.
2- Add a website to the branch company.
3- Enable a payment provider in the parent company. (The reason why the payment provider is set on the parent company is because due to limitation caused by account journal which requires branches to use the payment provider from the parent: b093786714e9e8567cf75abf78ac3d954a3d89b2
In another PR #257622, we are going to restrict users from being able to create a payment provider for the branch company)
4- Navigate to the branch website using incognito mode, and add a product to the cart.
5- Checkout and pay.

On version 17.0:
You will get a blocking error:
```
Incompatible companies on records:
- False belongs to company 'YourCompany' and 'Customer/Vendor'
(partner_id: 'Public user for Branch') belongs to another company.
```

On 18.0+:
You can only see the error if debug mode is on.
However, after payment, in the backend you can find the SO is never confirmed. Even if you confirm the order manually in the backend, then a cron will be initiated to register the payment in the journal and fail at every try.

Cause:
---
The _check_company() method enforces a strict constraint preventing relational fields from another company.
Here in this case we have a `account.payment` record with a `partner_id` from parent company, which violates the constraint.

As mentioned, in branch companies we are required to use the payment provider from parent company. So we would need to create a `account.payment` record inside parent company's journal with current partner which has `compnay_id` set to branch company.

Fix:
---
We could avoid the issue by not setting the website.company_id on the created partner on the website.

related: #257622

opw-6013978

#payments#branch#website

[FIX] packaging: bump Windows PostgreSQL version

PR #265134

Core17.0baseMEDIUM

This update replaces the older PostgreSQL 12 installer with version 16, addressing end-of-life support for the previous version. Additionally, the installer now uses a dedicated Odoo user for database connections, enhancing security and stability.

Original PR description

The Windows installer installs PostgreSQL 12. That version was chosen for its small size, but now in 2026 the size doesn't matter as much anymore. Also, version 12 is no longer supported, so it's time to bump to version 16.

While at it, this commit adds an Odoo user for the PostgreSQL connection instead of using the superuser.

#database#security#upgrade

[FIX] account: restore liquidity transfer matching

PR #265653

Core17.0accountMEDIUM

This update corrects a recent change that was preventing users from properly reconciling multi-step bank transfers (like payouts to internal accounts and then to destination banks). The fix focuses the matching filter to receivable and payable accounts, restoring the expected behavior for liquidity transfer reconciliation flows. This ensures accurate bank statement matching and avoids incorrect flagging of transactions.

Original PR description

Commit e2a9f3bfbb8a excludes from the bank statement matching domain any AML whose source statement line is already reconciled, to prevent false-positive label matches on past manual counterparts.

However, the filter is applied to every account type, which breaks legitimate multi-step reconciliation flows on liquidity / transfer accounts (e.g. payout -> internal transfer account -> destination bank). After the first statement line is reconciled, the transfer-account AML is no longer offered as a candidate for the destination bank line; the line falls back to the suspense account and the AML is also invisible in "Match Existing Entries".

Scope the new filter to receivable / payable accounts only, which is the case the original commit was actually guarding against.


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

#bank statements#reconciliation#transfers

The eTIMs specification limit the `itemNm` to 200 characters, so truncate the invoice line description to that limit to ensure that the invoice can be correctly submitted eTIMS server. Otherwise it will be rejected with: ``` Error sending to the KRA: - Request parameter error[<ItemList><itemNm>: length must be between 0 and 200] ``` Task-Id: 5220129

Version: --- 17.0+ Issue: --- Due to this issue, the orders are never confirmed on branch company website once payment is done. ### Steps to reproduce: 1- Create a branch company. 2- Add a website to the branch company. 3- Enable a payment provider in the parent company. (The reason why the payment provider is set on the parent company is because due to limitation caused by account journal which requires branches to use the payment provider from the parent: b093786714e9e8567cf75abf78ac3d954a3d89b2 In another PR #257622, we are going to restrict users from being able to create a payment provider for the branch company) 4- Navigate to the branch website using incognito mode, and add a product to the cart. 5- Checkout and pay. On version 17.0: You will get a blocking error: ``` Incompatible companies on records: - False belongs to company 'YourCompany' and 'Customer/Vendor' (partner_id: 'Public user for Branch') belongs to another company. ``` On 18.0+: You can only see the error if debug mode is on. However, after payment, in the backend you can find the SO is never confirmed. Even if you confirm the order manually in the backend, then a cron will be initiated to register the payment in the journal and fail at every try. Cause: --- The _check_company() method enforces a strict constraint preventing relational fields from another company. Here in this case we have a `account.payment` record with a `partner_id` from parent company, which violates the constraint. As mentioned, in branch companies we are required to use the payment provider from parent company. So we would need to create a `account.payment` record inside parent company's journal with current partner which has `compnay_id` set to branch company. Fix: --- We could avoid the issue by not setting the website.company_id on the created partner on the website. related: #257622 opw-6013978

The Windows installer installs PostgreSQL 12. That version was chosen for its small size, but now in 2026 the size doesn't matter as much anymore. Also, version 12 is no longer supported, so it's time to bump to version 16. While at it, this commit adds an Odoo user for the PostgreSQL connection instead of using the superuser.

Commit e2a9f3bfbb8a excludes from the bank statement matching domain any AML whose source statement line is already reconciled, to prevent false-positive label matches on past manual counterparts. However, the filter is applied to every account type, which breaks legitimate multi-step reconciliation flows on liquidity / transfer accounts (e.g. payout -> internal transfer account -> destination bank). After the first statement line is reconciled, the transfer-account AML is no longer offered as a candidate for the destination bank line; the line falls back to the suspense account and the AML is also invisible in "Match Existing Entries". Scope the new filter to receivable / payable accounts only, which is the case the original commit was actually guarding against. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr