Daily updates from Odoo
Thursday, March 19, 2026
10 changes · 18.0
Resolved issues and error corrections
This update fixes a potential server error that could occur when checking the status of batch payments. Previously, an error would display to the user, but now the system gracefully handles authentication issues and redirects the user to reconnect, improving the payment process reliability.
Original PR description
**Steps to reproduce:** 1. Install module `account_online_payment` 2. Go to Invoice > Payment, create payment, set partner and amount, then confirm 3. Go to Batch Payments and create a batch, set the bank and add the payment 4. From batch payment list view, select batch and click "Check Status" action **Issue:** Checking the status of a batch payment may raise a traceback with `OdooFinRedirectException`. **Cause:** `check_online_payment_status` calls `_fetch_odoo_fin` to retrieve the payment status. When the online account needs re-authentication, `_handle_response` raises `OdooFinRedirectException`. Since this exception is not handled, it propagates and results in a server error. **Fix:** Catch `OdooFinRedirectException` in `check_online_payment_status` to handle exception so that, user is redirected to reconnect the online account instead of seeing a traceback. **opw-5961729**
This update fixes a bug in the General Ledger CSV export by adding an initial balance line. It also corrects rounding logic to ensure currency conversions are accurate, improving the reliability of financial reporting data. This ensures more precise and complete financial reports.
Original PR description
1) 8dfe4c06106029f3f8039afc863bcacf7057106f added a csv export ledger for the general ledger, but it doesn't handle the initial balance. The fix is to call `_get_initial_balance_values` in the export method, as the query doesn't compute the initial balance lines. 2) Also changing the rounding logic, as currently the currency used is always the company currency, but for `amount_currency` it should use `currency_id`. task-5734354 Forward-Port-Of: odoo/enterprise#108344
This update resolves an issue where accounting calculations in the l10n_mx_edi_pos module were inconsistent with Python computations. The fix ensures accurate amounts are displayed in the POS, aligning with the expected financial reporting. This improves the reliability of sales transactions for Mexican businesses using this module.
Original PR description
Before this commit, the needed assets were not correctly loaded in the POS, which caused the amounts to be different from the ones computed in python. opw-5970322
This update resolves an issue where the WhatsApp integration would crash when a WhatsApp Business Account was linked to multiple phone numbers. Odoo's design allows for this, but the webhook processing logic was flawed, causing a security error. This fix ensures the WhatsApp integration remains stable and reliable for users managing multiple WhatsApp Business Accounts.
Original PR description
The webhook crashes when a WhatsApp Business Account uses multiple phone numbers. ### Steps to reproduce 1. Link two phone numbers to the same Account ID. 2. Receive a webhook for that account. ### Cause Odoo allows multiple records to share one Account ID to support multiple phone numbers. When a webhook arrives, searching by this ID returns a of all 2 matching records. The system crashes because it tries to read a security secret from this recordset to verify the request. opw-5419180
This update resolves a memory issue that occurred when propagating deliveries across multiple lots, particularly those with a large number of related picking IDs. The fix prevents a crash when handling large datasets, ensuring smooth operation for warehouses with extensive inventory.
Original PR description
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents. - Updating parent sets in a single operation caused a MemoryError for large datasets. ```sql…
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.
```sql
Traceback (most recent call last):
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
MemoryError
(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682
Lot_id 11412: delivery_by_lot size = 7420, parents = 3
Lot_id 11753: delivery_by_lot size = 0, parents = 7
Lot_id 12845: delivery_by_lot size = 11, parents = 5
Lot_id 14646: delivery_by_lot size = 12, parents = 2
Lot_id 15801: delivery_by_lot size = 1700, parents = 3
Lot_id 19817: delivery_by_lot size = 0, parents = 4
Lot_id 22370: delivery_by_lot size = 0, parents = 1
Lot_id 25072: delivery_by_lot size = 6827, parents = 2
Lot_id 25134: delivery_by_lot size = 3, parents = 2
Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones
UPG - 3869661
OPW - 5900313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248826This update fixes an issue where the cash difference report in Point of Sale was inaccurate. The fix ensures the starting cash amount is correctly used, providing a more precise calculation of cash discrepancies. This improves the reliability of financial reporting for PoS transactions.
Original PR description
**Steps to reproduce:** - Open the PoS, input 100 as starting cash amount - Make a Sale for $70 and pay in cash - Close the PoS and input 170 as ending cash while closing the session - Open the PoS again, input 100 as starting cash - Close the PoS without making any sale and input 100 as closing cash - Go to the session reports for the last session - The **Difference** is wrong **Why the fix:** Before this commit, when closing the session without making any sale, the starting cash amount was set to the ending cash amount from the last session. This means that the input from the user at the begining of the session was not taken into account. We now use the starting cash instead of last session's ending cash. We also display the correct amount in the 'Cash Opening' section. opw-5391239
This update resolves a critical bug in the Odoo testing framework that caused it to freeze when using the `child_of` operator. The fix utilizes a more efficient Depth-First Search (DFS) algorithm, improving performance and stability during testing. This ensures the testing environment runs smoothly and reliably.
Original PR description
Problem: Triggering the `child_of` operator in the testing framework caused an infinite loop that froze Odoo. This occurred because the framework attempted to fetch all children of the root operand without accounting for already visited nodes, resulting in children being added indefinitely. Additionally, the original implementation had a O(n²) time complexity. Solution: Implemented a proper Depth-First Search (DFS) to retrieve all children and prevent duplicate traversal in O(n) time.
This update fixes an issue where tax calculations on invoices were incorrect when currency rates were changed. The fix recomputes tax amounts using the latest price unit, ensuring accurate tax reporting for invoices with multiple currency rates. This improves financial reporting accuracy for international transactions.
Original PR description
# How to reproduce - Install the l10n_hu_edi module - Switch to a Hungarian company - Enable a currency (e.g., EUR) and configure two different exchange rates on two different dates - Create a new…
# How to reproduce
- Install the l10n_hu_edi module
- Switch to a Hungarian company
- Enable a currency (e.g., EUR) and configure two different exchange rates on two different dates
- Create a new invoice with :
- Delivery Date: One of the configured date
- A line with a price unit and a tax
- Save the invoice
- Edit the invoice :
- Delivery Date : The other configured date
- Change the price unit of the line
- Save the invoice
# The problem
The taxed amount total is using the old price unit
# Why
This commit (https://github.com/odoo/odoo/pull/225407) added a condition on the write of an account_move that made it so the tax amount is recomputed when the currency_rate is changed :
```py
elif field_has_changed(moves_values_before, move, 'invoice_currency_rate') and not field_has_changed(moves_values_before, move, 'invoice_date'):
# Changing the rate should preserve the tax amounts in foreign currency but reapply the currency rate.
round_from_tax_lines = 'reapply_currency_rate'
```
However, this recomputation is done using the old values for the invoice_lines and so it does not take into account the the newly changed price_unit
opw-5800521
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where invoices created with 'pay later' payment methods in the Swiss Point of Sale module were missing the necessary QR code for payment. The fix ensures that invoices correctly identify the bank partner, resolving this problem and allowing for proper payment processing. This impacts Swiss customers using the POS system.
Original PR description
Step to reproduce: - Install l10n_ch_pos and make sure swiss company has tax id filled - Create a swiss customer with an email address and vat, add full address - Open a pos session, and make an invoice for a product with tax, - select payment method, which allows `pay_later`, i.e. payment without journal_id Observation: - the invoiced order, do not have qr for payment, because the invoice do not have `bank_partner_id` Cause: - `_get_partner_bank_id` is recently updated in commit[1], which do not considered `pay_later` option [1] https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7 Fix: - Fixed the fallback logic for `_get_partner_bank_id` opw-6023060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue causing UBL invoices to fail validation due to minor rounding differences in quantity calculations. The fix adjusts how these rounding discrepancies are handled in the XML export, ensuring compliance with VAT regulations. This prevents invoice rejection during Peppol transmission.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_be - Switch to a Belgian company (e.g. BE Company CoA) - In Accounting settings: * activate Peppol * set "Rounding Method" to "Round Globally" -…
**Steps to reproduce:**
- Install Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings:
* activate Peppol
* set "Rounding Method" to "Round Globally"
- Create an invoice:
* Customer: [a Belgian customer with a VAT]
* Invoice Lines:
| Label | Quantity | Price | Taxes |
| ------- | ---------- | ------- | ------- |
| Line 1 | 1.0 | 90.30 | 0% |
| Line 2 | 0.45 | 2.54 | 6% |
| Line 3 | 0.28 | 6.87 | 6% |
- Confirm the invoice
- Send the invoice to Peppol
**Issue:**
The generated XML has a line with `<cbc:LineExtensionAmount>` set to 90.31, `<cbc:InvoicedQuantity>` set to 1.0 and `<cbc:PriceAmount>` set to 90.30, which fails the validation with the following error:
`[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".`
**Cause:**
The use of decimal number in quantity generates a 0.01 rounding difference in the base amounts.
The extra cent is dispatched in one of the `<cbc:LineExtensionAmount>` node.
**Solution:**
There is no easy solution to handle these rounding cases. The solution used in this fix is to handle the extra cents as if they are cash rounding amount and declare them in `<cbc:PayableRoundingAmount>` node.
opw-5933545
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr