Daily updates from Odoo
Monday, June 1, 2026
14 changes · 18.0
Resolved issues and error corrections
This pull request addresses minor fixes identified during the recent update of the French VAT (PDP) module. These changes ensure accurate VAT calculations and reporting for French businesses using Odoo. The fixes are backported to the 18.0 release.
Original PR description
Backports some fixes discovered during FW-porting task-None
This update ensures that descriptions are correctly populated on sale order lines when adding delivery items. Previously, new delivery lines didn't use the product's description, leading to incomplete order information. This change maintains accurate product details across the sales process, improving reporting and order clarity.
Original PR description
When a line is added to a delivery related to a sale order, the corresponding line created in the sale order uses only the display_name as a description. This commit makes sure that if a previous SO line exists for the product, the new line uses the same description. Otherwise we call `get_product_multiline_description_sale()` Steps to reproduce: - Create a product with a description in the Sales tab - Create a quotation with any product (can be said product) and confirm it - Go to the delivery action, and add a new line with the product in the view, set delivered quantity to 1 - After Validating, you'll notice that the new line in the Quotation doesn't have a description opw-6175891
This update fixes an issue where UBL files weren't correctly applying tax rates during import. The previous system used a simplified cache key, leading to inaccurate tax assignments for similar lines. This change ensures that the tax rates specified in the UBL file are precisely applied, improving data accuracy.
Original PR description
When we import a UBL file, we call the `_import_retrieve_tax` method to fetch taxes to indicate on lines.
During the process, we use cache to avoid performing the search a second time if a new line is the same as a previous one.
https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/account/models/account_tax.py#L4459-L4462
The cache_key used is defined as follows: {line's invoice, line's name, line's partner}.
This implies that if two lines from the same invoice share the same name and partner, the same tax will automatically be used even if different taxes were indicated in the file.
This is not desirable as we should match what is indicated in the XML file imported.
opw-6226166
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a test failure related to how binary data is handled during the import of Italian electronic invoices. The fix ensures the test data is correctly formatted for Python 3.14's stricter base64 validation, preventing an error. This improves the reliability of the Italian EDI module.
Original PR description
This commit fixes an error when running the `test_edi_import` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw test content was being passed to the `datas` field of an attachment when a base64 representation was actually expected (which is obviously invalid base64). Passing it via the `raw` field instead correctly handles the raw binary data. runbot-939133 Forward-Port-Of: odoo/odoo#266731
This update resolves an issue where Odoo's session testing process incorrectly flagged errors in Python 3.14. The change adjusts the tests to recognize a specific `PicklingError` that Python 3.14 now raises when attempting to serialize certain code snippets. This ensures the session tests accurately reflect the behavior of Odoo with the latest Python version.
Original PR description
Python 3.14 now raises `pickle.PicklingError` instead of `AttributeError` when attempting to pickle local functions or lambdas. This updates the session serialization assertions to expect the correct exception depending on the current Python version. runbot-938172 Forward-Port-Of: odoo/odoo#266862
This update resolves an issue where currency differences were incorrectly aggregated in hierarchical financial reports. The change ensures that reports accurately display totals in the original currency, improving the reliability and accuracy of financial data presented to users. This update addresses a potential misrepresentation of financial figures.
Original PR description
opw-6015098 Forward-Port-Of: odoo/enterprise#114827
This update corrects a technical issue preventing vendor bills with DAM (Declaración Aduanera de Mercancías) documents from being accepted by the SUNAT/SIRE system. The fix ensures that only the required 3-digit customs dependency code is used in the relevant field, aligning with SUNAT regulations. This resolves a rejection error and ensures proper reporting.
Original PR description
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the…
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047). * Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4). * Export the TXT file and open it. **Observed behavior:** * Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code. * SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes. **Cause:** * `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235". * The same incorrect value was also written to field 28 (aduana_code). * ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf **Fix:** * For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value). * Apply the same logic to field 28 (aduana_code) for consistency. opw-6157662 Forward-Port-Of: odoo/enterprise#115406
This update corrects a bug that incorrectly marked mass email sending as 'sent' even when emails hadn't actually been delivered to customers. This ensures accurate tracking of email campaigns and prevents misreporting of delivery status, improving the reliability of our customer communication features.
Original PR description
Fixed an issue where mass sending entries would set the sent status to true even if it's not actually sent to the customer task-6060589
This update resolves a bug where users were unexpectedly locked out of list views after editing a row. The fix ensures the system correctly exits edit mode when a user navigates away from a selected row, restoring normal functionality. This improves user experience and prevents disruptions to workflow.
Original PR description
Problem: When a user selects a row, attempts to edit a cell, and then clicks away without saving, the view becomes unusable. The selected row remains highlighted, and the system prevents the selection of other lines. The user is locked out until they click the "Save" or "Discard" buttons. Cause: The UI becomes stuck in edit mode. The `onGlobalClick` event handler within `documents_list_renderer` was missing the method call to exit edit mode. Solution: Updated `onGlobalClick` to correctly trigger the method to leave edit mode. task-6059836
This update resolves an issue where payments to PL suppliers without VAT would trigger errors when exceeding 15,000 PLN. The fix adds a check for suppliers without VAT, preventing unnecessary verification creation and ensuring smooth payment processing. This improves the reliability of the bank verification process for PL suppliers.
Original PR description
[FIX] l10n_pl_bank_verification: PL Supplier no VAT When a PL supplier has no VAT and a PL company tries to pay him a bill above 15.000 PLN, there is a traceback. The reason is that there was no check for partner with no VAT, a verification was created every time the field was compute.
This update resolves a minor typo in the name of the Sendcloud website delivery module. The incorrect spelling ('Sendcould') was corrected to the accurate 'Sendcloud'. This ensures consistent branding and avoids confusion for users.
Original PR description
The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.
opw-6239003
Forward-Port-Of: odoo/enterprise#118223This update resolves an issue where currency amounts in Arabic RTL (right-to-left) views were incorrectly formatted, appearing with the minus sign positioned to the right of the currency symbol. The fix ensures that currency amounts are displayed correctly, aligning with standard left-to-right formatting in Arabic locales, improving the user experience for Arabic-speaking users.
Original PR description
Steps to reproduce 1. Create a company with Egypt localization, currency EGP 2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts 3. Register a customer payment so the journal dashboard shows the Payments row with a negative amount 4. Switch the user language to Arabic 5. Open the Accounting dashboard Issue The Payments amount renders as "LE 5,000.00-" instead of "-5,000.00 LE". formatCurrency returns the string "-5,000.00 LE". In an Arabic page the leading "-" has no intrinsic direction, so the browser attaches it to the surrounding right-to-left Arabic text and visually moves it past the symbol. Sibling rows on the same dashboard render correctly because they already wrap the amount in dir="ltr", see https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/account/views/account_journal_dashboard_view.xml#L252 opw-6183749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where purchase journals created with only the Invoicing app couldn't import Peppol XML invoices due to a missing default account. The fix automatically assigns a default expense account, mirroring the behavior for bank/cash journals, ensuring invoices can be processed correctly. This prevents database errors and improves invoice import functionality.
Original PR description
When a user installs only the Invoicing app and creates a new purchase journal, no default_account_id is set on the journal. The Invoicing app does not expose account configuration, so the user cannot fix this manually. As a result, importing a Peppol XML invoice through that journal fails with a database constraint error because the generated account.move.line has a null account_id. https://github.com/odoo/odoo/blob/16245530f0e3e9be21c8b96baaecd3a679420cac/addons/account/models/account_journal.py#L776-L805 This already auto-creates accounts for bank/cash journals, but does nothing for sale/purchase journals. Steps to reproduce: - Install the Invoicing app (no full Accounting) - Create a new purchase journal with type 'purchase' - Go to Vendors -> Bills and Upload a Peppol XML file - Error importing attachment as invoice (decoder=_import_invoice_ubl_cii) Ticket [link](https://www.odoo.com/odoo/action-4043/6014363) opw-6014363 Forward-Port-Of: odoo/odoo#252859
This update corrects a bug in how backorder receipts are valued, ensuring consistent USD pricing regardless of exchange rate fluctuations between the bill date and receipt date. The change updates the calculation method for receipt value, resolving discrepancies that previously resulted in incorrect unit costs for backordered items.
Original PR description
Configuration: - Costing method: FIFO, automated valuation - Multi-currency: PO in a foreign currency (e.g. EUR), company currency USD - Two different exchange rates: one active at bill date, one at…
Configuration:
- Costing method: FIFO, automated valuation
- Multi-currency: PO in a foreign currency (e.g. EUR), company currency USD
- Two different exchange rates: one active at bill date, one at receipt date
- Bill posted before any goods are received
Steps to reproduce:
- Set EUR as a secondary currency with two different rates:
- Rate 1 on January 1st: 1 EUR = 1 USD
- Rate 2 on January 8th: 1 EUR = 2 USD
- Create a PO in EUR for 20 units @ 10,000 EUR
- Post the vendor bill dated January 3rd (rate 1 applies: 1 EUR = 1 USD)
- Receive 10 units on a date after January 8th and create a backorder
- Receive the remaining 10 units from the backorder on the same date
- Inspect the stock valuation layers and interim account journal entries for both receipts
Prior to this commit:
The two receipts, identical in quantity, date, and PO price, would produce different unit costs in USD. The backorder receipt would be incorrectly valued due to a wrong exchange rate being used when computing `receipt_value` in `_get_price_unit()`.
Receipt 2 (backorder):
SVL 1 value: $100,000 USD
Converted to EUR at receipt date (1 USD = 0.5 EUR):
receipt_value = $100,000 × 0.5 = 50,000 EUR (wrong rate)
total_invoiced_value = 200,000 EUR
remaining_value = 200,000 - 50,000 = 150,000 EUR
remaining_qty = 20 - 10 = 10
price_unit = 150,000 / 10 = 15,000 EUR
Converted to USD at bill date (1 EUR = 1 USD):
price_unit = $15,000 USD
SVL value = $15,000 × 10 = $150,000
This bug only affects backorder receipts. The first receipt always gets `receipt_value = 0` (no prior SVLs exist), so the problematic conversion never runs.
After this commit:
`receipt_value` is now computed using `_get_currency_convert_date()` instead of `layer.create_date`. This ensures `receipt_value` and `total_invoiced_value` are both expressed in EUR at the same reference rate.
Receipt 2 (backorder):
SVL 1 value: $100,000 USD
Converted to EUR at bill date (1 EUR = 1 USD):
receipt_value = $100,000 × 1.0 = 100,000 EUR (correct rate)
total_invoiced_value = 200,000 EUR
remaining_value = 200,000 - 100,000 = 100,000 EUR
remaining_qty = 20 - 10 = 10
price_unit = 100,000 / 10 = 10,000 EUR
Converted to USD at bill date (1 EUR = 1 USD):
price_unit = $10,000 USD
SVL value = $10,000 × 10 = $100,000
Both receipts now produce identical unit costs regardless of exchange rate differences between bill date and receipt date.
OPW: 5426718
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262577