Odoo Changelog — 2026-08-23

Sunday, August 23, 2026

3 changes · saas-19.2

Bug Fixes(3)

Resolved issues and error corrections

[FIX] website_sale: avoid confirming empty cart sale order

Coresaas-19.2website_saleMedium

This fixes an issue where portal users could accidentally confirm a sales order after removing all items from their online cart and visiting the payment validation page. It helps prevent invalid empty orders from entering the sales process and reduces cleanup for staff.

Original PR description

Calling `/shop/payment/validate` as a portal user with an empty cart confirms the empty sale order.

Steps to reproduce:
- Sign in as a portal user.
- Add a product to the cart.
- Remove the product.
- Go to `/shop/payment/validate`.
- The empty sale order is confirmed.

opw-6430637

Forward-Port-Of: odoo/odoo#282741
Forward-Port-Of: odoo/odoo#280924

#ecommerce#cart#orders#portal

[FIX] pos_sale: fix sale order invoicing after down payment refund

PR #283945

Coresaas-19.2pos_saleMedium

Fixes an issue where refunded point-of-sale down payments could be counted again when settling or invoicing a sales order. This prevents customers from being overcharged and keeps invoiced amounts accurate after refunds.

Original PR description

The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded. https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69…

The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded.
https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69

However, it does not handle the sale order line created for a refunded POS down payment. That line keeps `qty_invoiced` = -1, which causes the refunded amount to be included again when settling or invoicing the sale order.

Steps to reproduce:
- Create a sale order.
- Pay a down payment through the POS.
- Refund the down payment order from the POS.
- Settle the remaining amount from the POS or invoice the sale order from the backend.

Result:
- The generated invoice includes the sale order total plus the refunded down payment.
- Sale order `amount_invoiced` will be the down payment amount.

Fix:
- Delete the refunded downpayment to match the sale flow.
- Include refunded down payments in the amount_invoiced computation.

opw-6378891

Forward-Port-Of: odoo/odoo#283308
Forward-Port-Of: odoo/odoo#278011

[FIX] l10n_de_reports: handle 3-currency bank transactions

PR #128888

Enterprisesaas-19.2l10n_de_reportsMedium

German DATEV exports now handle bank reconciliations where the payer, bank journal, and company each use different currencies. The export splits these payments through the standard clearing account so each DATEV line uses only one foreign currency, preventing incorrect or unsupported export data.

Original PR description

Issue: - DATEV does not support multiple foreign currencies on a single journal line. - This can occur when reconciling a bank transaction where: - the payer uses one currency (C1), - the bank…

Issue:

- DATEV does not support multiple foreign currencies on a single journal line.
- This can occur when reconciling a bank transaction where:
  - the payer uses one currency (C1),
  - the bank journal is held in another currency (C2),
  - the company uses a third currency (C3).
- The existing export logic could not represent the bank liquidity and
  foreign AR/AP currencies separately in such cases.

Fix:

- Detect 3-currency cases from bank statement transactions and their
  liquidity line.
- Use the DATEV clearing account (1360 SKR03 / 1460 SKR04) to split the
  transaction into two logical legs:
  - Bank → Clearing (bank journal currency)
  - AR/AP → Clearing (payer currency)
- Emit the liquidity leg only once when multiple foreign AR/AP lines are
  reconciled against the same bank transaction.
- Keep regular 1- and 2-currency transactions on the existing export path.

Impact:

- Correctly represents 3-currency bank settlements in DATEV.
- Keeps each exported line in a single foreign currency.
- Leaves manual entries and payment transactions outside this specific
  handling, as the scenario is specific to the bank liquidity line.

taskID-5457547

Forward-Port-Of: odoo/enterprise#128876
Forward-Port-Of: odoo/enterprise#109010

Calling `/shop/payment/validate` as a portal user with an empty cart confirms the empty sale order. Steps to reproduce: - Sign in as a portal user. - Add a product to the cart. - Remove the product. - Go to `/shop/payment/validate`. - The empty sale order is confirmed. opw-6430637 Forward-Port-Of: odoo/odoo#282741 Forward-Port-Of: odoo/odoo#280924

The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded. https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69 However, it does not handle the sale order line created for a refunded POS down payment. That line keeps `qty_invoiced` = -1, which causes the refunded amount to be included again when settling or invoicing the sale order. Steps to reproduce: - Create a sale order. - Pay a down payment through the POS. - Refund the down payment order from the POS. - Settle the remaining amount from the POS or invoice the sale order from the backend. Result: - The generated invoice includes the sale order total plus the refunded down payment. - Sale order `amount_invoiced` will be the down payment amount. Fix: - Delete the refunded downpayment to match the sale flow. - Include refunded down payments in the amount_invoiced computation. opw-6378891 Forward-Port-Of: odoo/odoo#283308 Forward-Port-Of: odoo/odoo#278011

Issue: - DATEV does not support multiple foreign currencies on a single journal line. - This can occur when reconciling a bank transaction where: - the payer uses one currency (C1), - the bank journal is held in another currency (C2), - the company uses a third currency (C3). - The existing export logic could not represent the bank liquidity and foreign AR/AP currencies separately in such cases. Fix: - Detect 3-currency cases from bank statement transactions and their liquidity line. - Use the DATEV clearing account (1360 SKR03 / 1460 SKR04) to split the transaction into two logical legs: - Bank → Clearing (bank journal currency) - AR/AP → Clearing (payer currency) - Emit the liquidity leg only once when multiple foreign AR/AP lines are reconciled against the same bank transaction. - Keep regular 1- and 2-currency transactions on the existing export path. Impact: - Correctly represents 3-currency bank settlements in DATEV. - Keeps each exported line in a single foreign currency. - Leaves manual entries and payment transactions outside this specific handling, as the scenario is specific to the bank liquidity line. taskID-5457547 Forward-Port-Of: odoo/enterprise#128876 Forward-Port-Of: odoo/enterprise#109010