Wednesday, September 24, 2025
14 changes · saas-18.2
Resolved issues and error corrections
The Accounting reports follow-up view has been corrected so users can load additional invoice lines without hitting an error. This prevents interruptions for teams reviewing customer statements or follow-up reports with many invoices.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103Merging timesheet entries from the same helpdesk ticket now keeps them connected to that ticket. The system also prevents merging entries tied to different tickets, helping avoid lost ticket history and reporting errors.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090 Forward-Port-Of: odoo/enterprise#94780
This change updates a journal report test so it no longer depends on a payment reference staying empty in all country configurations. It helps keep automated builds reliable when Czech localization is installed, reducing false test failures without changing user-facing accounting behavior.
Original PR description
test_document_data_for_bank_journal_with_show_payment_option was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which is a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#95014
Users can now enter a checkout time directly from the Attendance Gantt popup when an attendance is still open. This fixes a visibility issue that blocked manual corrections and helps managers complete attendance records without leaving the Gantt view.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978 Forward-Port-Of: odoo/enterprise#92726
Purchase bills that are moved back to Draft now return to a clean GSTR-2B reconciliation state. This prevents old return-period links or exception flags from carrying over, helping teams reconcile GST data accurately when bills are corrected.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582 Forward-Port-Of: odoo/enterprise#95161 Forward-Port-Of: odoo/enterprise#95026
Chilean electronic delivery guide XML now reports the actual quantity delivered instead of the originally requested quantity. This prevents customers and authorities from seeing overstated quantities when only part of an order is delivered.
Original PR description
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered…
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE. **Steps to Reproduce** 1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock. 2. Create and confirm a new Sale Order. 3. Click on the Delivery smart button. 4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder. 5. Generate the Delivery Guide. 6. Open the generated DTE XML and observe that the quantity is incorrect. **Root Cause** The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount. **Fix** Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE. Opw-4892276 Forward-Port-Of: odoo/enterprise#89633
Chilean electronic invoice imports now correctly treat lines marked with exemption code 6 as negative amounts. This prevents vendor bills from being imported with overstated positive values, improving accounting accuracy for Chilean companies.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723 Forward-Port-Of: odoo/enterprise#93393
Shiprocket Cash on Delivery orders now include coupon-based discounts when sending shipment details. This prevents overreported COD amounts and keeps Shiprocket totals aligned with what the customer actually owes, including tax-aware discount handling.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.
Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
- Sale price: 1000 INR
- Weight: 100g
- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
- Payment Method: COD
- Set some "Shiprocket Channel"
- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
- Name: 50% off
- Program Type: Coupons
- Change the existing reward to 50% discount on order
- Generate some coupon
- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
- Shiprocket COD
- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log
--> total_discount is 0
Cause
-----
The problem comes from
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301
There are 2 issues here.
The first and most important one is how we find the discount lines.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320
Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
def _can_be_invoiced_alone(self):
""" Whether a given line is meaningful to invoice alone.
It is generally meaningless/confusing or even wrong to invoice some specific SOlines
(delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
in the SO.
"""
self.ensure_one()
return self.product_id.id != self.company_id.sale_discount_product_id.id
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_reward_line
We just have to be careful not to accidentally include delivery fees because of
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_delivery
The second issue is that we use the untaxed discount amount.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321
This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).
-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357
Forward-Port-Of: odoo/enterprise#94798
Forward-Port-Of: odoo/enterprise#92310Corrected a typo that caused a lock-date warning in accounting reports to display bullet points with inconsistent indentation. This makes the message clearer for users when a locked period prevents changes to a report external value.
Original PR description
[FIX] account_reports: typo in error message typo in generation of error message saying that lock dates are blocking the modification of a report external value See odoo/enterprise#92949 Forward-Port-Of: odoo/enterprise#95175
Fixed an issue where accounting reports could error if a currency rate filter dropdown was closed while the report view was being exited or refreshed. The system now avoids applying the filter after the report component is no longer active, improving stability for users navigating reports.
Original PR description
For the currency rate filter, applyFilters is called when the dropdown is closed. It might heppen that we have the dropdown open then we click on something that trigger the destruction of the report view but that still trigger applyFilters which try to apply filter on a destroyed component which is illegal. To prevent this we check if the component is destroyed before reloading the controller. Forward-Port-Of: odoo/enterprise#94313
The Belgian POS fiscal module no longer shows the “THIS IS NOT A VALID VAT TICKET” warning on invoice and daily report views. This avoids confusing users by keeping that message only on POS receipts where it is legally relevant.
Original PR description
- Remove the message "THIS IS NOT A VALID VAT TICKET" from the invoices and POS daily reports views. This message is only necessary on POS receipts that are not final TVA tickets. task-id: 5013860 Forward-Port-Of: odoo/enterprise#92287
This fix prevents barcode database updates from replacing an existing eCommerce product description. Businesses can safely use barcode lookup to fill missing product details without losing manually written website content.
Original PR description
Scenario: - enable "Barcode Database" in general settings - set an eCommerce description on a product - set a barcode in the database on that product (eg. 799439112766) Result: the eCommerce description has been overwritten by the barcode lookup result. Fix: do like other _update_product_by_barcodelookup methods and only update value that are not yet set. Note: also fixes the return of the overridden methods. opw-5061231 Forward-Port-Of: odoo/enterprise#94098
This fix prevents an error when users open sale order line details with related invoice lines from a product form dialog. It improves stability for accounting and sales workflows that use customized Studio views.
Original PR description
…in a dialog Steps to reproduce ================== Prerequisites: Having a product with an SO and an Invoice confirmed. Steps: - Open Product Variant Form - Open Studio - Add new O2M to SOL: Product (Sale Order Line) - Edit subview form - Add invoice_lines - Quit Studio - Click on SOL on Product view → It crashes => TypeError: can't access property "context", ctx.env.searchModel is undefined Cause of the issue ================== In form view dialogs, we don't have a search model Solution ======== We should use the context from the current record opw-4921186 Forward-Port-Of: odoo/enterprise#95259
Czech VAT return entries without a partner VAT number, or using special VAT regimes for travel services and margin schemes, are now consistently reported in section A5 regardless of invoice amount. This prevents affected invoices from being incorrectly placed in section A4, improving compliance and reducing manual corrections.
Original PR description
Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787 Forward-Port-Of: odoo/enterprise#92833