Thursday, April 9, 2026
14 changes · saas-18.4
Enhancements to existing features
Accounting screens that show running balances now load using far less memory by only calculating balances for the records being viewed. This prevents crashes on very large accounting datasets and improves response times for heavy list views.
Original PR description
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move…
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move lines, the result returned by fetchall() hits the memory limit and the server crashes. We propose to encapsulate the original query to only return the result for the account move lines present in self. Benchmarks --------------- The following benchmarks were generated with a customization of the account.move.line list view to display the cumulated_balance field. Memory usage during the self.env.cr.execute and the dictionary population: | Operation | Before the fix | After the fix | |---------------|----------------|---------------| | populate dict | 1.5 GB | 17.1 MB | | execute query | 430 MB | 8.3 MB | 100 000 lines were displayed at the same time to get a significant size. So the number of records in self is more than 7 000 000 without the fix and 100 000 with the fix. Time spent in the _compute_cumulated_balance method: | No of AML | Before the fix | After the fix | |-----------|----------------|---------------| | 7 000 000 | 10.4 s | 6.8 s | opw-6053720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256658 Forward-Port-Of: odoo/odoo#255780
Resolved issues and error corrections
Payments linked to vendor bills can now update to paid when the bill is fully reconciled, including cases with early payment discounts. This prevents paid bills from incorrectly appearing as still in process, improving payment status accuracy for accounting teams.
Original PR description
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without…
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without outstanding accounts. Steps to reproduce: - Create an early payment term. - Create a Vendor Bill with EPD and post it. - Register a payment for this bill (no outstanding account set on journal => no move created). - Create a bank transaction fully paying the bill. - Reconcile the transaction with the bill. Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'. Analysis: The issue occurs because the reconciliation process misses the trigger to set the payment state to 'paid'. Specifically: - The payment amount does not match the bill total due to the EPD. - The payment compute method does not monitor 'reconciled_bill_ids', causing it to ignore the status of linked vendor bills. This change adds 'reconciled_bill_ids' to the compute dependencies and ensures that if a payment is reconciled with any moves (invoices or bills), their payment_state is considered to determine the final state of the payment. Test in enterprise: https://github.com/odoo/enterprise/pull/112398 opw-5881976 Forward-Port-Of: odoo/odoo#256486
This fix stops repeated invoice actions on the same point-of-sale order from creating extra inventory transfer records. It helps keep stock movements accurate and avoids duplicate warehouse operations in specific accounting and stock-closing setups.
Original PR description
Calling `action_pos_order_invoice` on an already-invoiced POS order (e.g. a backend user clicking "Invoice" more than once) would unconditionally invoke `_create_order_picking`, producing one extra `stock.picking` per click under anglo-saxon + update_stock_at_closing configurations. opw-6092999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257509
Polish e-invoicing connections now renew automatically before the government-issued token expires. This helps prevent interruptions when sending invoices or receiving supplier bills through KSeF, avoiding the need for manual re-authentication every week.
Original PR description
The KSeF refresh token issued by the Polish Ministry of Finance expires after a week. Once it expires, the automatic fetching of incoming bills and sending of invoices will fail until the user manually re-authenticates in the settings. To ensure uninterrupted synchronization with the KSeF API, this commit adds a new scheduled action that runs every 6 days to automatically renew the tokens. task-6041758 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256700
Fixes an error that could appear when editors added multiple tags while editing a blog post cover. The change prevents unfinished new tags from being treated as existing database records, so users can continue editing without a traceback.
Original PR description
# How to reproduce - Go to a blog page and edit the Blog Post Cover - Add a tag - Try to add another one # The problem A traceback is shown # Why When adding a new record for a many 2 many relation, the framework ensure the user cannot create a record with a name that already exists via a name search. This commit (https://github.com/odoo/odoo/commit/3631757a4766bc59378bb975e01e115c92ef1dd4) changed the way the name search is done to add this domain to the request : ```py domain.push(["id", "not in", selectedIds]); ``` But selectedIds can contain strings in the case of uncreated records, which causes the SQL query to throw an error trying to match the model id with strings opw-5978305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an access rights error when marketing users add allowed dynamic fields, such as a recipient name, to mass mailing emails. The email editor now avoids adding styling metadata to placeholder elements that could be mistaken for a restricted template instruction, making campaign creation smoother for permitted users.
Original PR description
This commit fixes an unexpected access rights error when users try to add simple dynamic fields allowed by mail_allowed_qweb_expressions to mass_mailing emails. During the convert_inline process, the…
This commit fixes an unexpected access rights error when users
try to add simple dynamic fields allowed by mail_allowed_qweb_expressions
to mass_mailing emails.
During the convert_inline process, the <t t-out=""/> placeholder element
has its style inlined, and attributed to its style attribute.
This style attribute was not filtered out during the safety
check process, resulting in the templating engine believing a disallowed
directive was used.
Steps to reproduce:
- On a fresh 18.0+ install with demo data, login as Marc Demo
- Access the Email Marketing app
- Create a new mailing campaign
- Set sending to Newsletter or Mailing Contact
- Type /field to add a dynamic value
- Set it to Name
- Save the mailing
- An access rights error is raised due to the user not having
group_mail_template_editor permissions and the dynamic placeholder
node having a style attribute
Fix:
T nodes are no longer granted a style attribute during style inlining.
Forward-Port-Of: odoo/odoo#226111Sales orders for customers with SEZ GST treatment now select the correct SEZ fiscal position instead of being treated as exports. This helps ensure Indian tax handling is applied accurately and reduces manual correction for affected sales orders.
Original PR description
Before this commit: When creating a sale order, if the GST Treatment of partner is SEZ, then the Fiscal position is set as Export instead of SEZ. Reason: The default `foreign_state` obtained currently is searched on base of state whose country is not India, so any random state is fetched. But in the fiscal position of SEZ, we want "Foreign State", so while selecting fiscal position from `_get_fiscal_position` method, the Export fiscal gets higher ranking and gets selected. This commit fixes this issue by returning the correct Foreign State if fiscal position is set to SEZ. task-5958903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254887
Marketing emails written in right-to-left languages, such as Arabic, now preserve their intended text direction when sent. This prevents recipients from seeing campaign content incorrectly flipped to left-to-right formatting.
Original PR description
**Steps to reproduce:** - Install Mail Marketing app - Change user language to a RTL language (such as Arabic) - Create a marketing campaign with RTL content - Send it (with the campaign, test mail works properly) - Mail received changes from RTL to LTR **Issue:** Table `direction` style is removed by the `_Cleaner` as it is not in its `_style_whitelist` during the composer creation. **Fix:** Add it to the valid styling to ensure rtl mails are properly formatted by the rtlcss library. related fix: https://github.com/odoo/odoo/commit/4ac3766fa5b458864c1728441cf4a157df943d39 sanitize on `mail.composer.mixin`: https://github.com/odoo/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208 opw-5982854 Forward-Port-Of: odoo/odoo#257886
This fixes an issue where automatic absence detection could choose the wrong day for employees in time zones behind UTC. It prevents false errors that incorrectly said an employee was already checked in, helping attendance records stay accurate across regions.
Original PR description
### Steps to reproduce: - Have a database in timezone America/Asuncion for example - Create an employee - Create an attendance for the day before yesterday from 13h to 19h - Run the absence detection cron - An error will be raised saying the user is already checked-in on that day ### Cause: When trying to create an absence attendance we localized yesterday's midnight into UTC and then apply the employee timezone. Which cause a one-day shift when having a timezone behind UTC as at that point we try to create an attendance on the day before yesterday not yesterday ### Fix: We use the timezone of the employee to localize midnight then get this time in UTC. opw-5930309 Forward-Port-Of: odoo/odoo#257932
Newly added detailed stock operation lines now remain visible after refreshing the page or using actions such as Put in Pack. This prevents warehouse users from thinking newly entered stock movement details were lost and reduces unnecessary navigation back and forth.
Original PR description
**Problem:** When creating a new stock.move.line in the moves view (accessed via smart button from a picking), the newly created line disappears after any refresh action (manual refresh or triggering…
**Problem:**
When creating a new stock.move.line in the moves view (accessed via smart button from a picking), the newly created line disappears after any refresh action (manual refresh or triggering "Put in Pack").
**Steps to reproduce:**
1. Open a receipt/picking operation
2. Click on the "Moves" smart button to open the detailed operations view
3. Create a new stock.move.line record
4. Click "Put in Pack" or manually refresh the page
5. Observe that the newly created line disappears
**Current behavior:**
The newly created stock.move.line disappears from the view after refresh, and only reappears if you navigate back to the picking and then return to the moves view.
**Expected behavior:**
The newly created stock.move.line should remain visible in the view after refresh or any action that triggers a view reload.
**Cause of the issue:**
The action_detailed_operations method uses a static domain [('id', 'in', self.move_line_ids.ids)] that captures a snapshot of move line IDs at the moment the action is opened.
https://github.com/odoo/odoo/blob/22ac818970f104a732cc7d24afc440cf0e6d74bd/addons/stock/models/stock_picking.py#L1204-L1212 When a new stock.move.line is created in this view, its ID is not included in the original static list. Any refresh (manual or triggered by operations like "Put in Pack") re-applies this static domain, filtering out the newly created lines because their IDs weren't captured in the initial list.
**Fix:**
Using a dynamic domain based on picking_id ensures all move lines belonging to the picking are always visible, regardless of when they were created. This aligns with the expected behavior of showing "all move lines for this picking" rather than "only the move lines that existed when the view was opened". The relational lookup [('picking_id', '=', self.id)] is re-evaluated on each refresh, automatically including any newly created lines that have the correct picking_id set.
opw-5398620
Forward-Port-Of: odoo/odoo#247170This update ensures that negative values in the Mod 390 tax reports for Spain (l10n_es_reports) are accurately marked with the 'N' indicator as required by Spanish tax regulations. Previously, this indicator was missing, leading to potential reporting discrepancies. This fix aligns with official documentation for accurate tax reporting.
Original PR description
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative…
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export ### Note: According to the official specification, negative amounts must be explicitly marked with N Latest documentation: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` with demo data and switch to the ES company - Create a Bill (Price: 100, Taxes: 21% G) - Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year - Open the VAT Deductible tab - The last line (65) should be negative - Export the BOE file using the gear menu - Check the last value of section 4 in the file ### Before the fix: Negative values were not marked with N opw-5482706 Forward-Port-Of: odoo/enterprise#113200 Forward-Port-Of: odoo/enterprise#111262
This update resolves an issue where automatic bank reconciliation would fail when using the liquidity account as an outstanding payment account. The fix prevents the system from attempting to reconcile transactions with this account, avoiding a persistent error message and ensuring data integrity. This improves the reliability of bank statement processing.
Original PR description
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity…
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account - Go to the Transactions of the Journal - Add a new Transaction for partner X and amount Y - Add a second Transaction also for partner X and amount Y # The issue A popup appears that can never be saved # Cause When we click on "Add & New" or "Add & Close", we run the `validate()` function : https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16 Which tries to do a model save, but it fails so it show the Form dialog : https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163 The save fails because : This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so : https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385 https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245 But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once: https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737 opw-6063654 Forward-Port-Of: odoo/enterprise#112750
This update fixes an issue where Odoo incorrectly consumed stock from the wrong location when scanning serial numbers on manufacturing orders. Previously, the system prioritized a location (Vendors or Stock) based on database ID, leading to inaccurate stock tracking. This change ensures the correct Stock location is always selected, improving inventory accuracy.
Original PR description
Steps to reproduce: - Create a Manufacturing Order with a serial-tracked component. - Open the Shop Floor. - Scan the serial number barcode to register the component. - Observe which location the component was consumed from. Issue: When a product is received from a vendor, Odoo creates two quants for the same serial number — one at Partners/Vendors location and one at WH/Stock location. Because get_quant_from_barcode searched for a matching serial number with no location filter, it returned whichever quant had the lowest database ID — which was always the Partners/Vendors or Production quant created first — instead of the correct WH/Stock quant. Solution: Prevent selecting a quant from an incorrect location when multiple quants exist for the same serial number, as this can lead to consuming stock from the wrong location. opw-5974474 Forward-Port-Of: odoo/enterprise#112691
This update corrects a problem where '&' characters in vendor bill references were incorrectly exported as '&' in SEPA payment files. This prevented successful processing of payments by banks, ensuring compliance with SEPA regulations and avoiding payment failures. The fix replaces '&' with '+' during XML generation.
Original PR description
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net &…
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer. 4. Create a batch payment with the SEPA payment and validate it. Issue: The `&` character is exported as `&` in the generated PAIN XML, while according to the SIX specification it should be replaced with `+` Cause: The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed. Solution: Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML. Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf opw-5941724 Co-authored by @bhra-odoo Forward-Port-Of: odoo/enterprise#110809