Daily updates from Odoo
Wednesday, July 15, 2026
8 changes · 18.0
Resolved issues and error corrections
This fix prevents an accounting dashboard filter from accidentally interfering with Mexican CFDI payment document updates. Users can now update payments without encountering an unexpected error when documents integration is enabled.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172
Colombian electronic invoice imports now keep the XML unit price as provided by DIAN instead of dividing it by the quantity. This prevents incorrect negative discounts from appearing on vendor bills when imported items have quantities greater than one.
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. task-6215466
This fixes an issue where partial receipts involving subcontracted products could incorrectly mark related items as processed, causing backorders to be created with the wrong quantities. Businesses receiving mixed subcontracted and regular products through barcode workflows should now get more accurate receipt validation and backorder handling.
Original PR description
### Steps to reproduce: - Create a subcontracted product P1 - Create a storable product P2 - Buy 5 units of both products from your subcontractor - On the receipt set both moves quantity to 2 Units -…
### Steps to reproduce: - Create a subcontracted product P1 - Create a storable product P2 - Buy 5 units of both products from your subcontractor - On the receipt set both moves quantity to 2 Units - Validate the receipt and create a backorder #### > Only the subcontracted move has been kept on the receipt and a backorder was created for 3 units of P1 and 5 of P2. ### Cause of the issue: Setting the quantity of the subcontracted move will automatically record the quantities on the subcontracted MO: https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L83 https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L123 https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L91 However, the `_update_finished_move` method adds and update the related subcontracted move lines marking them as *picked* to adapt the related reservation: https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L118-L164 This is problematic since picking a move line will also pick the move: https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/stock/models/stock_move.py#L261-L267 And only picked moves are considered to be processed at picking validation. ### Note: The exact same issue had already been fixed in 17.0: db8b33ebb9fe23507bcba30b12741e4d688ae549 However, the fix had an issue concerning the barcode behavior as it removed the picked computation for subcontracted moves which made hybrid pickings such as the above one (with one subcontracted and one non-subcontracted move) impossible to process in the barcode app. As such, the fix and test where reverted in cf2d18c92bee55ef79db1a338e9baf12f258ee5b The present commit provides an alternative fix of the original issue keeping subcontracted moves unpicked by quantity changes without affecting the picked computation of subcontracted moves (e.g. adding a picked move line on a subcontracted move will still pick that move). Community: https://github.com/odoo/odoo/pull/275304 opw-6330584
Fixes an issue where General Ledger spreadsheet exports for a single selected journal showed tax declaration lines multiple times, breaking the report layout. The export now includes those tax lines only once and limits account processing to the selected journal, producing a clearer and correctly formatted file.
Original PR description
## Issue When exporting the General Ledger in xlsx format with only one journal selected, the tax declaration lines appear multiple times and are disrupt the overall format of the report. ## Steps to…
## Issue When exporting the General Ledger in xlsx format with only one journal selected, the tax declaration lines appear multiple times and are disrupt the overall format of the report. ## Steps to reproduce 1. Install *Accounting* (`account_accountant`) with demo data 2. In Accounting > Reporting > General Ledger, select a single journal (e.g. Customer Invoices) and click the *XLSX* export button. 3. **The resulting XLSX file is incorreclty formated. The tax declaration lines appear multiple times and disrupt the structure of the report.** <img width="1012" height="603" alt="image" src="https://github.com/user-attachments/assets/1d22e9a1-3fc2-4538-b1bd-4ca1d1bbe092" /> ## Cause Since https://github.com/odoo/enterprise/commit/6a3804c5fe6b4f1d48a4ab311a0f1fbb24d75187, the xlsx report is generated by iterating over the relevant accounts and injecting the lines into the report account by account. https://github.com/odoo/enterprise/blob/b6d27f428e2b966e38b65e820e1454b711483996/account_reports/models/account_general_ledger.py#L773-L775 The [`_get_accounts_with_move_lines` method](https://github.com/odoo/enterprise/blob/17.0/account_reports/models/account_general_ledger.py#L814) does not take into account the journals that are requested when exporting .xlxs, which leads to too many accounts being iterated over. Before that commit, the `_get_lines` method was only called once when generating the xlsx report. This explains the behaviors below, that were not properly adapted to call the method multiple times to generate a single report. The first issue is that the `_get_lines` method calls the `_dynamic_lines_generator` method, which adds the tax declaration lines after each account when only one journal is selected: https://github.com/odoo/enterprise/blob/b6d27f428e2b966e38b65e820e1454b711483996/account_reports/models/account_general_ledger.py#L88-L91 To avoid that, we can add a context key to prevent the injection of the tax declaration lines for all iterations, then add the lines afterwards. Another issue is that the accounts chosen to iterate over do not take the selected journal into account. Without doing so, we iterate over too many accounts, which is inefficient, but which also adds the tax declaration lines (and only those lines) for those irrelevant accounts. That is why the tax declaration lines appear multiple times in the incorrect reports: they were added for accounts that were not supposed to belong in the report. Lastly, because the total line is added individually, it would not be bold because of the following condition from `inject_lines_into_xlsx_sheeŧ`: https://github.com/odoo/enterprise/blob/b6d27f428e2b966e38b65e820e1454b711483996/account_reports/models/account_report.py#L5262-L5266 ## Performance Impact Because the commit introducing the issue (https://github.com/odoo/enterprise/commit/6a3804c5fe6b4f1d48a4ab311a0f1fbb24d75187) is a [PERF] commit, the performance impact of this fix was evaluated. The table below shows the time taken to export the XLSX report of the General Ledger for a various amounts of `account.move.line`. Each value represents the average execution time over 10 runs (in milliseconds), with the standard deviation shown in parentheses. | | Before (ms) | After (ms) | |--------|------------------|------------------| | 100 | 321.25 (± 49.56) | 363.43 (± 59.93) | | 5,000 | 1759 (± 71.87) | 1773 (± 60.19) | | 10,000 | 2723 (± 70.72) | 2765 (± 106.8) | | 50,000 | 11501 (± 170.32) | 11567 (± 165.87) | opw-5783588 Forward-Port-Of: odoo/enterprise#111826
French VAT declaration submissions now handle SIRET numbers even when users enter spaces, preventing avoidable filing failures. The update also checks bank account number formatting and warns users before submission if something looks incorrect.
Original PR description
This commit resolves an issue where VAT declarations failed when the provided SIRET number included spaces. Since check_siret verifies the format, we now strip all spaces from the input. Additionally, this commit introduces a validation for bank account numbers, ensuring that we warn the user if the account number is wrongly formatted. task-6253745
Fixes an issue where Uruguay e-Ticket Credit Notes linked to original e-Tickets totaling 0.00 could be rejected by the tax authority because a required reference amount was omitted. The required zero amount is now included, helping businesses submit compliant credit notes without manual intervention.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783 Forward-Port-Of: odoo/enterprise#124354
Invoices marked as 'No Follow-Up' are now properly left out of follow-up email attachments and printed follow-up letters. This prevents customers from receiving statements that include invoices the business intentionally excluded from follow-up actions.
Original PR description
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the invoice. 3. Open the contact form and click on the Customer Statement smart button 4. Exclude the invoice using the 'No Follow-Up' toggle 5. In the Accounting tab in the contact form, click on send 6. Open the internal link of the Content Template, go to the options tab and select 'Print Follow-up Letter' in Dynamic Reports 7. Save the configuration and send the email Issue: Excluded invoices still appeared as PDF attachments in the follow-up email and were merged into the printed follow-up letter PDF. Why this happens: Both `default_get` in `account_followup.manual_reminder` and `_get_invoices_to_print` in `res.partner` traversed `unreconciled_aml_ids` without filtering out lines where `no_followup = True`, so excluded invoices were included regardless. opw-6310602
This update fixes an issue where vendor bills generated from Colombian XML imports incorrectly applied discounts due to a misinterpretation of price unit calculations. The change ensures that the PriceAmount is correctly parsed as the unit price, aligning with DIAN regulations and preventing negative discounts on invoices.
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price…
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. Task [link](https://www.odoo.com/odoo/project.task/6215466) task-6215466