Daily updates from Odoo
Monday, September 1, 2025
7 changes · master
Resolved issues and error corrections
Fixes an issue where Mexican sales orders could show zero invoiced quantity after an invoice cancellation was completed through CFDI. The sales order now updates its invoiced quantities when the CFDI status changes, helping keep order and billing records accurate.
Original PR description
How to reproduce the issue: In l10n_mx: 1. Create a sale order. 2. Create an invoice from the SO, with yesterday’s date, and send it to the CFDI. 3. Lock the period at yesterday’s date. 4. Request the invoice cancellation with the “01” method. This creates a new invoice — confirm it. 5. Create a credit note for the original invoice. 6. Retry sending the cancel request to the CFDI; the CFDI state is now cancelled for the original invoice. On the original SO, the quantity invoiced is 0 despite the CFDI state of the original invoice being cancelled. This commit forces a recompute of the quantity invoiced when the CFDI state changes. Since _compute_qty_invoiced uses _get_invoice_lines, which filters out invoices in sent state, only lines from invoices in cancelled state will be taken into account. opw-4910139 Forward-Port-Of: odoo/enterprise#93480 Forward-Port-Of: odoo/enterprise#91924
Replacing work entries in the Gantt view now correctly creates a new entry using the selected type and the appropriate duration. This helps HR users avoid incorrect work entry totals when updating employee schedules, including empty days where expected working hours are used.
Original PR description
task-5043872
This fixes Italian POS receipts so change given back to customers is not sent to fiscal printers as a negative payment. This helps ensure orders are accepted by fiscal printers and properly reported to the authorities.
Original PR description
Before this commit, specifying the payment method used to give back the change in a POS order would lead to the fiscal printer receiving a negative payment as input, which is not supported, thus leading to the order not being treated by the fiscal printer (so not reported to the government). Only the payments with is_change=true where filtered out. I am now adding a filter to only keep the positive payments in the receipt, as the fiscal printer is computing the change itself. opw-4931671 Forward-Port-Of: odoo/enterprise#91794
Fixes an issue that could block users from deleting a generated bank statement line when the related journal entry used multiple reconciliation rules. This helps accounting users correct bank reconciliations without encountering an unexpected error.
Original PR description
Currently, an error occurs when trying to remove a move line from a bank statement line if the journal entry contains lines with different reconciliation models. **Steps to Reproduce:** 1. Install…
Currently, an error occurs when trying to remove a move line from a bank statement line if the journal entry contains lines with different reconciliation models. **Steps to Reproduce:** 1. Install the Accounting module. 2. Duplicate the "Internal Transfer" reconciliation model. 3. Accounting dashboard > click on Bank > create new record. 4. Add the invoice, apply "Internal Transfer" reconciliation model. 5. Edit the balance of the line to lower, apply duplicated model(Internal Transfers (copy)). 6. Try deleting the generated Liquidity Transfer line. (Refer [this video](https://drive.google.com/file/d/1cz80Q5325x3rqYUlGahVzFIXH2iqrbRF/view?usp=drive_link) for steps to reproduce.) **Error:** ValueError - Expected singleton: account.reconcile.model(8, 6) **Cause:** In the method `delete_reconciled_line` at [1], the `reco_model_id` is fetched from `self.move_id.line_ids.reconcile_model_id`. If the move contains lines linked to multiple reconcile models, this causes a singleton error during subsequent processing. **Fix:** This commit uses the already computed `move_lines_to_remove` to retrieve `reconcile_model_id` instead of accessing it from `self.move_id.line_ids`, which may result in a multi-recordset. [1] - https://github.com/odoo/enterprise/blob/89aa58029a79928788277489414f8192aa5353e4/account_accountant/models/account_bank_statement.py#L1041-L1049 sentry-6781788260 Forward-Port-Of: odoo/enterprise#91619
Kenyan e-invoicing checks now ignore cancelled or draft credit notes when validating quantities and amounts against the original invoice. This prevents incorrect blocking errors when businesses create replacement credit notes after cancelling earlier ones.
Original PR description
[FIX] l10_ke_edi_edi_oscu: ensure quantity and monetary values checks are performed on reconciled reversals only. Fixes a behavior where the checks performed on the credit notes related to their quantities and monetary values include non reconciled credit notes. Steps to reproduce: 1 - activate `l10n_ke` on some company. 2 - Create an invoice. 3 - Create a partial or full credit note ( this one will be reconciled with the invoice automatically ) 4 - cancel the credit note or reset it to draft. 5 - create another credit note where the quantities and/or monetary values exceed that of the invoice if summed up with the cancelled credit note. Following the steps will result in an error message saying that the monetary value or quantities on the credit notes exceed that of the invoice. The correct behavior is to simply not count any credit note that isn't explicitly reconciled with the invoice. opw-4779976 Forward-Port-Of: odoo/enterprise#92319
Default values for tax return types are now applied when companies and return types are created, rather than only during initial chart setup. This prevents missing or incorrect defaults when country-specific reporting modules are installed later, improving consistency for accounting compliance setups.
Original PR description
Before the company dependent default values for the return types were set only during the ```_post_load_data``` of the chart template. The issue with this way is that when we install a l10n for instance 10n_be_reports which add new return types, l10n_be would create a new company then trigger the _post_load_data function on return types that existed at that time. The only problem is that return types from l10n_be_reports are still not installed. The change here is that we set the default value on the creation of the company and return type.
Fixed an issue where returning a rental order linked to a Point of Sale picking could incorrectly increase the delivered quantity. This helps keep rental order records accurate after PoS settlement and return workflows.
Original PR description
**Issue:** Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS **Cause:** The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty`…
**Issue:** Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS **Cause:** The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty` to the related `sale_line` each time it runs When there is no PoS order, the method add 0 to the line, so the expected behavior work But when you have a PoS Picking, a quantity was added to `qty_delivered` each time the `rental.order.wizard` is used The issue also occured earlier when the `flush_all()` is called in `_process_order()` **Fix:** There is already a `_compute_qty_delivered` method in `pos_sale_stock_renting` that override the `qty_delivered` But it's restricted by `_are_rental_pickings_enabled()` That's not necessary because we don't use any `stock.picking` in the `_compute_qty_delivered` function, only `stock.move` so we removed that verification To make the code working, we also need to extend the _get_outgoing_incoming_moves() results Because there were also block by a `_are_rental_pickings_enabled()` condition even if there is only moves here We need all the moves to calculate `qty_delivered` properly **Steps to reproduce:** - Create a New Product "Rental PoS" that Can be Rented - Create and confirm a New Rental Order, with any customer and your product - Open a PoS Session - Click on Quotation/Order - Choose the last Order and Settle the order - Click on Yes (to confirm import to PoS) - Click on Payment, select Cash and Pay - Go in the Backend, and to your RO - Click Return and Validate - Before the fix, the Delivered should be 2.0 opw-4877019 Forward-Port-Of: odoo/enterprise#93406 Forward-Port-Of: odoo/enterprise#90510