Odoo Changelog — 2026-08-04

Tuesday, August 4, 2026

3 changes · saas-18.3

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_it_xml_export: LIPE only for VAT return

Enterprisesaas-18.3l10n_it_xml_exportMedium

Italian withholding tax returns submitted in quarterly months were incorrectly treated as periodic VAT returns, which could open the wrong export wizard, cause errors, or attach the wrong file. The update ensures the LIPE export is only offered for actual VAT returns, improving reliability for Italian tax filing workflows.

Original PR description

In Italy the periodic VAT return (LIPE) is filed quarterly, so `is_quarter_month` gates the XML export wizard on March, June, September and December. That field only looks at the date, never at the kind of return, so every Italian return locked on a quarter month was treated as a LIPE.

Submitting the withholding tax return therefore opened the LIPE export wizard. Depending on the record the wizard receives, it either crashes while reading the VP lines missing from the withholding report, or silently generates a LIPE file and attaches it to another return.

Add an `is_lipe_return` field telling whether the return actually produces the LIPE.

Steps to reproduce:
- Install `l10n_it_xml_export` and `l10n_it_edi_withholding_reports` on an Italian company with monthly returns
- Open Accounting > Reporting > Tax Return
- Review and submit the withholding returns up to February
- Review then submit the March withholding return --> The LIPE export wizard opens, and the export fails on the withholding report.

opw-6255016

#Italy#VAT#LIPE#tax returns#withholding tax

[FIX] pos_urban_piper: compute correct unit price for tax-included orders

PR #126585

Enterprisesaas-18.3pos_urban_piperMedium

UrbanPiper online orders with tax-included products now calculate the unit price correctly when customers order more than one item. This prevents inflated POS order totals and helps keep sales, tax, and reporting figures accurate.

Original PR description

Steps to reproduce:
---
- Configure a Point of Sale with UrbanPiper credentials.
- Create a product priced at 100 with a 5% GST (Tax Included).
- Sync the product with UrbanPiper.
- Place an online order with a quantity greater than 1.

Issue:
---
- `total_with_tax` was incorrectly treated as the unit price for multi-quantity tax-included orders.

Fix:
---
- Calculate the unit price by dividing `total_with_tax` by the ordered quantity before creating the POS order line.

task-6427634

Forward-Port-Of: odoo/enterprise#125989

#UrbanPiper#Point of Sale#tax-included pricing#online orders

[FIX] approvals: onchange crash in request_status compute method

PR #125374

Enterprisesaas-18.3approvalsMedium

This fixes a crash that could happen when approval requests were linked through Studio fields and a form recalculated after a change. The system now avoids trying to send notifications from temporary records, improving reliability when working with approved or refused requests.

Original PR description

**Before this change**
We have the potential to attempt to send a notification email from virtual records created by our `BaseModel.new()` method. This can happen during an `onchange` request, given that we'll be working with a virtual "snapshot" record to recompute potentially changed values for our origin record after a change to one or more values.

This issue manifests when using Studio to attach a many2many field to a form view, where the related model is "Approval Request". If an approval request record in either the "Approved" or "Refused" state is attached to our record via this new Studio field, any `onchange` requests will trigger this bug. This is because we can't send messages on a virtual record.

**After this change**
Prevent the creation and sending of a message if we are computing the request status of a virtual `approval.request()` record. The field `request_status` on this model is computed and stored, but the fact that it is a computed field means that it must be recomputed for a virtual record, even if the origin record already has a stored `request_status`. Thus, we may need to compute a `request_status` value for an ephemeral "snapshot" record.

Though the issue only manifests for the "Approved" and "Refused" states, this PR expands on a test that covers every approval request state.

opw-6390453

In Italy the periodic VAT return (LIPE) is filed quarterly, so `is_quarter_month` gates the XML export wizard on March, June, September and December. That field only looks at the date, never at the kind of return, so every Italian return locked on a quarter month was treated as a LIPE. Submitting the withholding tax return therefore opened the LIPE export wizard. Depending on the record the wizard receives, it either crashes while reading the VP lines missing from the withholding report, or silently generates a LIPE file and attaches it to another return. Add an `is_lipe_return` field telling whether the return actually produces the LIPE. Steps to reproduce: - Install `l10n_it_xml_export` and `l10n_it_edi_withholding_reports` on an Italian company with monthly returns - Open Accounting > Reporting > Tax Return - Review and submit the withholding returns up to February - Review then submit the March withholding return --> The LIPE export wizard opens, and the export fails on the withholding report. opw-6255016

Steps to reproduce: --- - Configure a Point of Sale with UrbanPiper credentials. - Create a product priced at 100 with a 5% GST (Tax Included). - Sync the product with UrbanPiper. - Place an online order with a quantity greater than 1. Issue: --- - `total_with_tax` was incorrectly treated as the unit price for multi-quantity tax-included orders. Fix: --- - Calculate the unit price by dividing `total_with_tax` by the ordered quantity before creating the POS order line. task-6427634 Forward-Port-Of: odoo/enterprise#125989

**Before this change** We have the potential to attempt to send a notification email from virtual records created by our `BaseModel.new()` method. This can happen during an `onchange` request, given that we'll be working with a virtual "snapshot" record to recompute potentially changed values for our origin record after a change to one or more values. This issue manifests when using Studio to attach a many2many field to a form view, where the related model is "Approval Request". If an approval request record in either the "Approved" or "Refused" state is attached to our record via this new Studio field, any `onchange` requests will trigger this bug. This is because we can't send messages on a virtual record. **After this change** Prevent the creation and sending of a message if we are computing the request status of a virtual `approval.request()` record. The field `request_status` on this model is computed and stored, but the fact that it is a computed field means that it must be recomputed for a virtual record, even if the origin record already has a stored `request_status`. Thus, we may need to compute a `request_status` value for an ephemeral "snapshot" record. Though the issue only manifests for the "Approved" and "Refused" states, this PR expands on a test that covers every approval request state. opw-6390453