Monday, August 3, 2026
8 changes · saas-19.1
Enhancements to existing features
The Chilean F29 tax report has been optimized to calculate all report lines in one pass, improving performance and reliability for users preparing tax declarations. The update also refines the six-column report layout, tax credit handling, withholding sections, and related submission flow to better match reporting needs.
Original PR description
This commit optimizes the F29 report by using just one big query to compute the data for all the report lines at once. task-4329648 Forward-Port-Of: odoo/enterprise#106701
Payment export files now include building numbers in structured addresses for ISO 20022 formats. This prepares businesses for upcoming banking requirements that make this information mandatory from November 2026.
Original PR description
This commit adds the <BldgNb> node in the iso20022 XML files, as it will be mandatory starting November 2026. Linked: https://github.com/odoo/odoo/pull/271855 task-6317758 Forward-Port-Of: odoo/enterprise#126377 Forward-Port-Of: odoo/enterprise#121674
Resolved issues and error corrections
Bank transaction matching now ignores archived bank accounts when choosing the customer or vendor. This prevents transactions from being assigned to outdated partners and helps automatic reconciliation follow the expected payment details instead.
Original PR description
Steps to reproduce: - Have a partner with a bank account, then archive the res.partner.bank record (keep the partner active). - Import or create a bank transaction (e.g. via bank sync) whose account number matches that archived bank account, and whose label/payment_ref would otherwise match a reconciliation model for a different partner. - Let the transaction go through automatic partner retrieval. => The archived bank account's partner is assigned, even though a normal manual entry (which skips the account-number match) would have used the label instead. Cause of the issue: `AccountBankStatementLine._retrieve_partner()` matches statement lines to partners in batch using raw SQL joining `res_partner_bank`. The query's WHERE clause filters out archived partners (`AND partner.active`) but never filters `res_partner_bank.active`. opw-6340479 Forward-Port-Of: odoo/enterprise#124537
Users can now click and edit custom fields directly in the Documents list view, including fields added through Studio. This removes an extra step and makes document data entry faster and more intuitive.
Original PR description
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The…
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field. This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list. This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected. **Steps to reproduce:** - Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit - In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode - In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field **Current behavior before PR:** - Custom fields do not trigger inline edit mode **Desired behavior after PR is merged:** - Custom fields trigger inline edit mode opw-6378102 Forward-Port-Of: odoo/enterprise#125378 Forward-Port-Of: odoo/enterprise#125239
Guatemalan electronic invoice PDFs now show 'CF' whenever the official XML uses it, keeping the customer-facing document aligned with the submitted tax file. The fix also treats placeholder VAT entries as missing and applies the 2,500 threshold in company currency, reducing compliance inconsistencies on foreign-currency invoices.
Original PR description
with this commit:- - Display 'CF' in the invoice PDF whenever the generated XML uses CF. - Treat placeholder VAT values such as '/', 'NA', and 'na' as missing VAT. - Compare the invoice total using the company currency instead of the document currency when evaluating the 2,500 threshold, ensuring the legal limit is applied consistently regardless of the invoice currency task-6305333 Forward-Port-Of: odoo/enterprise#120985
The aged payable and receivable drill-down now hides fully paid invoices and bills, so users only see items that were genuinely outstanding. Historical reports also respect the selected reporting date, improving accuracy when reviewing past balances.
Original PR description
Steps to Reproduce: 1. Create a vendor/customer with multiple bills/invoices. 2. Fully pay one or more, leaving at least one still open for the same partner. 3. Open Accounting > Reporting > Partner…
Steps to Reproduce:
1. Create a vendor/customer with multiple bills/invoices.
2. Fully pay one or more, leaving at least one still open for the same partner.
3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable.
4. Set to any date and click into an aging bucket for that partner.
Issue:
The drill-down list shows fully settled bills (residual = 0.00) alongside genuinely outstanding ones. Only surfaces when the partner has at least one open balance — if everything is paid, there is no bucket to click into.
Root Cause:
aged_partner_balance_audit builds the drill-down domain filtering only by reconcile flag, journal type, and date range — never checking residual. Additionally it completely overwrites the XML action domain (account.action_amounts_to_settle) which already had ('amount_residual', '!=', 0), losing that protection entirely.
Fix:
Added ('residual_at_date', '!=', 0) to the domain in aged_partner_balance_audit and set recon_limit in the action context so residual_at_date computes as of the report's 'as of' date rather than today's value:
action['context'] = {
'recon_limit': options['date']['date_to'],
}
Without recon_limit, residual_at_date falls back to amount_residual (today's value) which incorrectly excludes bills that were genuinely open on the report date but paid after it.
Result:
The drill-down now correctly shows only genuinely outstanding items regardless of whether the report is run as of today or a historical date.
opw 6333699This pull request addresses several key updates to the Chilean tax reporting functionality within Odoo. Specifically, it incorporates new tax categories, corrects fiscal position calculations, and improves data consistency for accurate reporting. These changes ensure compliance with updated Chilean tax regulations.
Original PR description
added tags for accounts and new demo data for l10n_cl_reports f29 refactor refactor file to company_demo.xml Add widthholding tax 2nd category for 2027 and 2028 since it is suitable for this report compatibility [FIX] l10n_cl: add more taxes and fix translation [FIX] l10n_cl: adapt fiscal position to new scheme. [FIX] l10n_cl: remove unused tags [FIX] l10n_cl: add fiscal position to taxes and replacement tax. Change refs in demo and fix demo values to make more consistent with real cases [FIX] l10n_cl: change monthy taxes payable 210760 from payable to current [FIX] l10n_cl: add new ILA accounts to COA and fix ILA tax repartition lines Compatibility with 'remove tax_tag_invert' [FIX] l10n_cl: fix 'compras de combustibles' task-4329648 Forward-Port-Of: odoo/odoo#247545
This update ensures that customer signatures are consistently included in order confirmation PDFs, regardless of whether online payment is enabled. Previously, signatures were missing when using online payment, and this fix corrects a technical issue related to context settings within the order confirmation process. This improves customer satisfaction and provides a more complete record of the sale.
Original PR description
**Steps to reproduce:** 1. Create a new SO and enable "Online Signature" and "Online Payment" in the "Other Info" tab 2. Click on Preview and click on "Sign & Pay" from the portal (demo payment…
**Steps to reproduce:** 1. Create a new SO and enable "Online Signature" and "Online Payment" in the "Other Info" tab 2. Click on Preview and click on "Sign & Pay" from the portal (demo payment should be enabled from the settings to proceed) 3. Once the transaction is processed and the order confirmed, check the confirmation email/PDF sent to the customer in the chatter **Issue:** - The order confirmation sent to the customer after paying online does not include the signature they provided when accepting the quotation - Even if "Online Payment" is not enabled and Signing will directly confirm the order, the signature is still missing. **Why this happens:** - The signature block in `sale.report_saleorder_document` is gated by the `sale_include_signature` context key rather than solely by doc.signature. This was introduced by commit ef8246a4daf6146da2ed3cb78c37c7bf0937a4df to retain signature integrity. - `portal_quote_accept` only sets this context right after the customer signs on the pdf rendered for us (company), and was not passed through `_validate_order()` when there was no online payment - When online payment is required, `_has_to_be_paid()` defers the order confirmation which happens later, and the context is never set elsewhere **Fix:** - Pass the context when online payment is not required - If online payment is required, the sale quotation can be modified after being signed. However, since the customer previews the quotation when Paying, we can say the signature integrity is retained opw-6389733 Forward-Port-Of: odoo/odoo#278854