Thursday, March 19, 2026
12 changes · saas-18.3
Resolved issues and error corrections
This update corrects an issue where QR codes generated for self-ordering pickup orders included incorrect URLs with table identifiers. The fix ensures QR codes are generated correctly for 'pickup zone' ordering modes, preventing errors in downloaded PDFs and improving the customer ordering experience. This resolves a previous bug impacting order accuracy.
Original PR description
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right…
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right there below these configs) Observation: - in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be. - QRs do not have table_id Cause: - there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone" Fix: - we only use table_id when ordering_mode = 'table'. **Before:** <img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" /> **After** <img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" /> opw-5095607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251759 Forward-Port-Of: odoo/odoo#247184
This update resolves a memory issue that occurred when propagating deliveries across multiple lots, particularly those with a large number of associated picking IDs. The fix ensures the system handles large datasets efficiently, preventing crashes and improving performance for users 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 resolves a problem where invoices with specific fixed tax configurations (related to 'vidange/consigne' returns) were failing Peppol validation checks. The fix adjusts how tax exemptions are handled during invoice generation, ensuring compliance with Peppol standards and allowing invoices to pass validation.
Original PR description
**PROBLEM** Here is the client use case: The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the…
**PROBLEM** Here is the client use case: The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations. **STEP TO REPRODUCE** 1. Create a fixed tax used for 'vidange/consigne'. 2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'. 3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08]. **CAUSE** Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice: line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange. After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%. line 2: qty=-1, unit_price=0, taxes: 0%. line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None. When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'. Line 2 reason comes from: https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274 opw-5912986 Forward-Port-Of: odoo/odoo#250413
This update corrects a bug that was causing incorrect decimal values to be generated in intrastat XML reports for French companies. The issue stemmed from how the system processed invoice data, specifically when handling weights with decimal amounts. This fix ensures accurate intrastat reporting, preventing potential discrepancies with tax authorities.
Original PR description
Steps to reproduce: - Select a French company and activate intrastat - Create an invoice with a 100% discount to a european partner and provide intrastat values such as intrastat code, product commodity code, ... and most importantly a weight with a decimal amount. - Create at least one other invoice to a european partner that has a date earlier than the first one (but on the same month) - Go to intrastat report and export the XML (DEBWEB2) and select EMEBI and then Departures. -> Issue: The line that got processed after the one with a 0 value is not properly post-process regarding the integer conversion because we used to iterate on a list that was modified at the same time. opw-5973832 Forward-Port-Of: odoo/enterprise#110971
This update resolves an issue where users lacking live chat permissions would encounter an error when trying to open the invite panel. The change ensures that active live chat partners are correctly retrieved for invited users, improving the usability of the live chat feature. This prevents frustration and ensures a smoother experience for all users.
Original PR description
When opening the livechat invite panel, users without livechat access rights encounter an access error. This commit fixes the issue by ensuring active live chat partners can be retrieved for invited users. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a user experience issue where generating PDFs for multiple employee declarations didn't process all records when using the 'Select All' feature. Now, selecting all records and generating PDFs will process all drafts, and users can easily regenerate existing PDFs. This ensures a smoother and more reliable process for generating employee declaration reports.
Original PR description
This PR solves the following issues: - In the list view of employee declarations, when the records span to multiple page, pressing `Select all` and the `Generate PDFs` button only generates the PDFs of the records selected on the current page, which is confusing for users who expect all records to be processed. - When you select lines that have a generated PDF, you should have an option to regenerate the PDF if needed. At the moment, the Generate PDFs button only works on lines in draft state. task-5909426
This update fixes an issue where reasons provided by Public Administrators when refusing invoices weren't displayed in Odoo. Now, the reason message (EsitoCommittente/Descrizione) is shown on the invoice header, ensuring accurate record-keeping related to invoice refusals. This ensures compliance with Italian tax regulations (FatturaPA).
Original PR description
When a Public Administrator business refuses an invoice, they also give a reason message (EsitoCommittente/Descrizione), which comes through the IAP to Odoo as an XML tag aside the Outcome code (EsitoCommittente/Esito). Before this PR, the message was ignored, now we show it in the invoice's header. ref: https://www.fatturapa.gov.it/export/documenti/messaggi/v1.1/MessaggiTypes_v1.1.xsd <img width="823" height="232" alt="image" src="https://github.com/user-attachments/assets/8f222f6b-1615-4dd2-a5dd-25e0991ea037" /> <img width="942" height="206" alt="image" src="https://github.com/user-attachments/assets/cdf109ff-40d0-4c50-bdc7-51fb4ea15c98" /> Ticket [link](https://www.odoo.com/odoo/project.task/6041276) opw-6041276 Forward-Port-Of: odoo/odoo#254481
This update resolves an issue preventing users from creating new journals when a previously archived default account was linked to a journal. Previously, the system blocked new journal creation due to a uniqueness check that included archived accounts. Now, users can create new journals seamlessly, even with archived accounts, improving workflow efficiency.
Original PR description
Backport of https://github.com/odoo/odoo/pull/249869 Description This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a…
Backport of https://github.com/odoo/odoo/pull/249869 Description This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a default account linked to an existing journal has been archived. Current Behavior Currently, when a user creates a new journal (e.g., a "Bank" type journal), the system automatically generates or assigns a default account. If the user subsequently archives that default account, any future attempt to create a new journal of the same type results in a Validation Error: "Account codes must be unique. You can't create accounts with these duplicate codes: [XXXXXX]" This happens because the system's uniqueness check for account codes includes archived accounts, but the automated journal setup logic fails to account for this state, effectively locking the user out from creating new journals until the archived account is manually renamed or unarchived. Desired Behavior After this PR is merged, users should be able to create new journals seamlessly, even if previous journals have archived default accounts. video https://drive.google.com/file/d/1VzAskdTwF7lNc1y8PIpvN0T2zzKTMtdJ/view 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#251025
This update resolves an issue where generating VAT reports (FAIA) for invoices in different currencies caused a rendering error. The fix ensures the necessary currency information is included in the report template, allowing accurate reporting across multiple currencies. This improves the reliability of VAT reporting for Luxembourg companies.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057 Forward-Port-Of: odoo/enterprise#110660 Forward-Port-Of: odoo/enterprise#106902
This update fixes an issue where analytic distribution wasn't being correctly passed from sales orders to purchase orders. Now, when a sale order with analytics is confirmed, the correct distribution is automatically applied to the corresponding purchase order, ensuring accurate cost tracking for inventory. This improves financial reporting and inventory management.
Original PR description
Steps to reproduce: - Enable analytic distribution in Accounting settings - Create a storable product "P1": - Routes: MTO + Buy - Vendor: add any supplier - Create a Sale Order: - Add 1 unit of P1 -…
Steps to reproduce: - Enable analytic distribution in Accounting settings - Create a storable product "P1": - Routes: MTO + Buy - Vendor: add any supplier - Create a Sale Order: - Add 1 unit of P1 - Set any analytic distribution - Confirm the Sale Order Result: A Purchase Order is created, but the analytic distribution is not propagated to the purchase order line. Problem: When the Sale Order is confirmed, `_action_launch_stock_rule()` is triggered. It creates and confirms the corresponding stock move with values from the sale order line. Since the product uses the MTO route, the procurement rule is executed. The rule prepares procurement values from the stock move, but the analytic distribution is not included in these values: https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L1539 Later, `_run_buy` is triggered. It uses the procurement values coming from the stock move to find an existing purchase order line candidate or to create a new one. Because the analytic distribution is missing from the values, the created (or matched) purchase order line does not contain the analytic distribution: https://github.com/odoo/odoo/blob/621a93b7b723999d943f1c4da78547763498c008/addons/purchase_stock/models/stock_rule.py#L113 Solution: Propagate the analytic distribution from the sale order line through the stock move so it can be included in the procurement values and correctly applied to the purchase order line. opw-5936971 Forward-Port-Of: odoo/odoo#252577 Forward-Port-Of: odoo/odoo#252292
This update fixes an issue where overtime calculations were inaccurate after employees switched their leave status between 'draft' and 'validated'. The system now automatically recalculates overtimes whenever leave information is updated, ensuring accurate overtime reporting. This prevents miscalculations and provides more reliable data for payroll and time tracking.
Original PR description
When we re-evaluate leaves we update overtimes after switching to draft but we do not update the overtimes again after the leave is switched back to validated. This causes the overtimes from attendances that overlap with the leave to be miscalculated as if the leave was not validated. To rectify this issue, we recalculate the overtimes for the affected employees after every create/write/unlink of `resource.calendar.leaves`. opw-4844447 Forward-Port-Of: odoo/odoo#253590 Forward-Port-Of: odoo/odoo#229723
This update resolves an issue where quarterly VAT returns in Odoo Enterprise weren't automatically generating the necessary XML files for submission. The fix corrects a logic error that incorrectly used the return's start date instead of the end date for quarter detection. This ensures accurate XML generation and avoids return closure without the required export.
Original PR description
## Issue: When the tax return periodicity is set to quarterly and the return is validated, the XML file is not generated and downloaded ## Cause: The quarter detection logic was based on the `date_from` field of the return However, for quarterly returns, the correct reference should be `date_to` Using `date_to` also works correctly for monthly returns ## Steps to reproduce: - Install `l10n_it_xml_export` - Switch to the IT Company - Go in the Tax Report (Monthly VAT Report (IT)) to do a Tax Return (Opening Date: 01/01/2025, Periodicity: Quarterly) - If needed change the Tax Return Periodicity in Settings to Quaterly - Select the first report and ignore the error in Review Before the fix, it is only possible to close the return without generating the XML export opw-5707544