Daily updates from Odoo
Friday, March 13, 2026
32 changes · saas-18.3
Resolved issues and error corrections
This update fixes a calculation error in the equity reports. Previously, `equity_unaffected` accounts were incorrectly using 'historical' currency rates. The change reorders the CASE statement to ensure these accounts use the correct, current rate conversion, leading to more accurate financial reporting.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update addresses a common error (code 9004) users were encountering with the Instagram integration in Odoo. The fix provides clearer, more helpful messaging to guide users in troubleshooting potential network or file-related issues, reducing the need to contact support. This improves the overall user experience and stability of the Odoo Enterprise platform.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#110456 Forward-Port-Of: odoo/enterprise#109319
This update resolves an issue preventing Argentinian companies with 'IVA Sujeto Exento' (VAT exempt) AFIP responsibility types from creating 'Export Invoices' documents. Previously, the system restricted this functionality. This change ensures compliance and allows businesses to properly generate export invoices as required by Argentinian tax regulations.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Create a Argentinian company with "AFIP Responsibility Type" set to "IVA Sujeto Exento" (VAT exempt) - Switch to the created company - In Accounting settings, set up "AFIP Web Services" - Create a journal for export invoices - Create a customer with "AFIP Responsibility Type" set to "Cliente del Exterior" - Create an invoice - Select the created customer - Try to set the document type for export invoices **Issue:** It is not possible to select "(19) EXPORT INVOICES" as "Document Type" for companies having "AFIP Responsibility Type" set to "IVA Sujeto Exento". It is not because the company is "VAT exempt" that it should not be able to create an export invoice. opw-5974268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252232
This update corrects a naming error in the ZUGFeRD eInvoice XML file generated by our accounting module. Previously, the file was named incorrectly, causing validation issues with several key e-invoice validators. Now, the file name aligns with accepted standards, ensuring proper processing and compliance with German regulations.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252681
This update fixes a minor issue where closing the emoji or GIF picker wouldn't always allow it to reopen immediately. The fix ensures the picker state is correctly reset, providing a smoother and more reliable user experience when selecting emojis or GIFs. This improves usability for all users.
Original PR description
**Current behavior before PR:** When the GIF or emoji picker is dismissed by clicking outside, the component state remains out of sync because `props.onClose` isn't triggered. This causes the next attempt to open the picker to fail, requiring an extra click from the user. **Desired behavior after PR is merged:** Closing the picker now correctly triggers the `props.onClose`. This ensures the component state is always reset, allowing the picker to reopen immediately on the next click. task-[5953015](https://www.odoo.com/odoo/project/1519/tasks/5953015) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250630
During migration, the `l10n_pl` end-migrate script was loading for every company using the `pl` chart template, including child companies. However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies. Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration. To prevent this, restrict chart loading to root
Original PR description
During migration, the `l10n_pl` end-migrate script was loading for every company using the `pl` chart template, including child companies. However, account codes must be…
During migration, the `l10n_pl` end-migrate script was loading
for every company using the `pl` chart template, including child companies.
However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies.
Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration.
To prevent this, restrict chart loading to root companies only, which is consistent with how account code uniqueness is enforced.
**Steps to reproduce:**
1. Create a database in 17.0
2. Install `account_accountant` and `l10n_pl`
3. Create a child (branch) for the company using the `pl` chart template
4. Migrate the database to 18.0
5. Migration fails with duplicate account code validation errors
**Traceback**
```py
Traceback (most recent call last):
File "/home/odoo/odoo18/community/odoo/service/server.py", line 1366, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/odoo18/community/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/odoo18/community/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/odoo18/community/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 222, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/odoo18/community/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
Template._load_data({'account.account': Template._get_account_account('pl')})
File "/home/odoo/odoo18/upgrade/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
return super()._load_data(data, *args, **kwargs)
File "/home/odoo/odoo18/community/addons/account/models/chart_template.py", line 677, in _load_data
created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals, ignore_duplicates=ignore_duplicates)
File "/home/odoo/odoo18/community/odoo/models.py", line 5531, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/odoo18/community/odoo/models.py", line 5435, in _load_records_create
records = self.create(vals_list)
File "<decorator-gen-196>", line 2, in create
File "/home/odoo/odoo18/community/odoo/api.py", line 498, in _model_create_multi
return create(self, arg)
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 987, in create
records._ensure_code_is_unique()
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 1064, in _ensure_code_is_unique
raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 01.000.100, 01.000.200, 01.000.400, 01.000.900, 02.000.100, 02.000.200, 02.000.300, 02.000.900, 03.000.100, 03.000.200, 03.000.300, 03.000.400, 03.000.500, 03.000.600, 03.000.700, 03.000.800, 03.000.900, 03.050.100, 03.050.200, 03.050.300, 03.050.900, 07.010.200, 07.010.300, 07.010.400, 07.010.500, 07.010.600, 07.020.100, 07.020.200, 07.020.300, 07.030.100, 07.030.200, 08.000.100, 08.000.200, 08.000.300, 08.000.400, 08.000.500, 10.000.100, 10.000.200, 10.000.900, 13.000.100, 13.000.200, 13.000.900, 14.000.100, 14.000.200, 14.000.900, 14.050.100, 20.000.100, 20.000.200, 20.000.300, 21.000.100, 22.000.100, 22.010.100, 22.010.200, 22.010.300, 22.020.100, 22.020.200, 22.020.300, 22.030.100, 22.030.200, 22.030.300, 22.030.400, 22.030.500, 22.030.600, 23.000.100, 23.000.200, 23.000.900, 24.010.100, 24.010.200, 24.020.100, 24.020.200, 24.030.100, 24.030.200, 24.030.300, 24.030.400, 24.050.100, 24.090.100, 24.090.200, 24.090.300, 24.090.900, 28.000.100, 29.000.100, 29.010.100, 29.020.100, 30.000.100, 30.000.200, 30.000.300, 30.000.400, 30.000.500, 30.000.600, 30.000.700, 30.000.800, 30.000.900, 31.010.100, 31.060.100, 31.090.100, 33.000.100, 33.000.200, 33.000.300, 33.000.400, 33.000.500, 33.000.600, 34.010.100, 34.020.100, 34.020.200, 34.020.300, 34.020.400, 34.060.100, 34.070.100, 39.000.100, 40.000.100, 40.010.100, 40.010.200, 40.010.300, 40.010.400, 40.010.900, 40.020.100, 40.020.200, 40.020.300, 40.020.400, 40.020.500, 40.020.600, 40.020.700, 40.020.900, 40.030.100, 40.030.200, 40.030.300, 40.030.400, 40.030.500, 40.030.600, 40.030.700, 40.030.800, 40.030.900, 40.040.100, 40.040.200, 40.050.100, 40.050.200, 40.050.300, 40.050.900, 40.090.100, 49.000.100, 49.000.200, 49.000.300, 49.000.400, 50.000.100, 50.000.200, 50.010.100, 50.010.200, 52.010.100, 52.070.100, 53.000.100, 53.000.200, 55.000.100, 55.000.200, 58.000.100, 60.000.100, 60.010.100, 60.020.100, 62.000.100, 62.010.100, 64.000.100, 64.010.100, 65.000.100, 65.010.100, 70.000.100, 70.000.200, 70.000.300, 70.000.400, 70.010.100, 70.010.200, 70.010.300, 70.010.400, 73.000.100, 73.000.200, 73.000.300, 73.000.400, 73.010.100, 73.010.200, 73.010.300, 73.010.400, 74.000.100, 74.000.200, 74.000.300, 74.010.100, 74.010.200, 74.010.300, 75.000.100, 75.000.200, 75.000.300, 75.000.400, 75.000.500, 75.000.600, 75.000.700, 75.000.900, 75.010.100, 75.010.200, 75.010.300, 75.010.400, 75.010.500, 75.010.900, 76.000.100, 76.000.200, 76.000.300, 76.000.400, 76.000.900, 76.010.100, 76.010.200, 76.010.300, 76.010.900, 79.000.100, 79.000.200, 79.000.300, 79.000.400, 79.000.500, 80.000.100, 80.000.200, 80.000.300, 80.000.400, 81.010.100, 81.020.100, 81.030.100, 81.040.100, 82.000.100, 83.000.100, 83.000.200, 83.010.000, 83.010.100, 83.010.200, 84.010.000, 84.020.100, 84.020.200, 85.010.100, 85.020.100, 85.020.200, 85.020.300, 86.000.100, 87.000.100, 87.000.900
```
**Fix:**
- Load `account.account` records only for root companies during When the chart template loads for `pl` localization.
opw-5932421
upg-3895331
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#250654This update resolves an issue where parallax preview animations appeared differently in Firefox and Chrome due to inconsistent iframe height calculations. The fix now uses the root document height, ensuring a stable and predictable animation across all browsers. This improves the user experience for website editors.
Original PR description
Steps to reproduce: - Open the website editor. - Open the snippet dialog. - Scroll through a parallax snippet preview in Firefox and Chrome. => The preview animation does not move the same way. Before this commit, the parallax preview used `body.clientHeight` inside the scaled snippet preview iframe. Firefox and Chrome can return different values there, so the preview animation was inconsistent. After this commit, the preview reads `document.documentElement.clientHeight` instead, which gives a stable iframe viewport height across browsers.
This update resolves an issue where quotation documents with zero subtotal lines were being discarded during upload. The fix ensures that all lines, including those with a zero subtotal, are correctly processed, preventing data loss and improving the accuracy of quotation generation. This change maintains compatibility with older Odoo versions (16.0+).
Original PR description
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document…
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document upload. Steps to reproduce: --- 1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket) 2- As you see, lines are discarded. Cause: --- This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0. Fix: --- Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself. opw-5977735 Forward-Port-Of: odoo/odoo#253149 Forward-Port-Of: odoo/odoo#251463
This update fixes a technical issue related to XML files used for Swedish payment processing (pain.001.001.09). The change ensures the correct XML structure is used, improving compatibility with Swedish banking systems. This ensures accurate and compliant payment processing for our Swedish customers.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221 Forward-Port-Of: odoo/enterprise#109930
A warning message was appearing during tax report adjustments in the French localization. This was caused by an unnecessary reference to a field ('box_B1') within the report's calculations. This update removes the problematic reference, ensuring accurate reporting and eliminating the warning message for users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
This update corrects a minor syntax error in the PWA service's CSS selector, which was preventing the application from correctly registering during installation. This fix ensures that the PWA installation process functions smoothly, resolving a potential issue that could have disrupted the user experience. The change is focused on version 18.3.
Original PR description
Description of the issue/feature this PR addresses:
Fixes a typo in the manifest selector used by the PWA service.
document.querySelector("link[rel=manifest") was missing the closing ], making the selector invalid.
Current behavior before PR:
Calling getManifest() could throw a DOMException due to an invalid CSS selector, preventing manifest retrieval and potentially breaking PWA install flow.
Desired behavior after PR is merged:
getManifest() correctly queries link[rel=manifest], retrieves the manifest URL, and keeps the existing manifest-fetch behavior intact (including test coverage already present in pwa_service.test.js).
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251376This update fixes an issue where temporary files used during report generation weren't always being properly deleted after tests. The change ensures these files are cleaned up immediately, preventing potential disk space issues. This improves the stability and efficiency of the Odoo reporting system.
Original PR description
Investigated after finding `/tmp/report.*` left over after running tests. #186547 left some temporal holes in the cleanup which are apparently sufficient to not correctly clean the files in some cases? Since `mkstemp` already creates the files, don't wait to have written stuff inside to record the file for deletion, do it immediately *then* write content to the file. An even better solution would be to use `NamedTemporaryFile(delete_on_close=False)`, however that's only available from 3.12, and it does not log deletion errors (although I'm not convinced that's useful in the first place). Forward-Port-Of: odoo/odoo#253053
This update resolves an issue where a regex used to process vendor bills could fail when encountering unexpected data types (specifically, False). The change ensures the regex only operates on valid string values, improving bill processing reliability and preventing errors during import.
Original PR description
The issue occurred because a test regex was applied to a non-string value. In some cases the value was False, which caused the operation to fail. Steps to reproduce: - Import a vendor bill - Remove the product and the label from one line, then post the bill - Import another bill (or the same bill)from the same supplier - An error occurs when the regex tries to match a non-string value This change ensures the regex is only applied to valid strings. It also improves the code by extracting the static part of the regex into a dedicated variable. opw-6019298 opw-6030364 opw-6033013 opw-6032608 opw-6032546 Forward-Port-Of: odoo/odoo#253576
This update fixes a problem where the HTML editor would lose its current selection when the editor regained focus after using the command palette. The change ensures the selection is preserved, improving the user experience when navigating the editor. This prevents frustration and allows users to continue editing seamlessly.
Original PR description
Before this commit: when the whole editable regains the focus, the selection in the editable is reset to the start of it. After this commit: We create a override for hotkey service to open the command palette with an onClose to refocus the editable area without losing the current selection. For the hotkey override, we pass the area option so it's only valid in the editable area. Outside the editable, the command palette is opened in the default way. task-5949705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250624
This update ensures Odoo complies with new NACHA regulations regarding payment descriptions. Starting March 2026, all payroll payments must include 'PAYROLL' in the Company Entry Description field to avoid potential payment issues. This change is a necessary update to maintain compliance and accurate financial reporting.
Original PR description
Starting March 20, 2026, NACHA requires the Company Entry Description field to contain "PAYROLL" for paying wages, salaries, or compensation [1]. [1] https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions task-5981941 Forward-Port-Of: odoo/enterprise#109460
This update corrects a bug where combo items weren't printed using preparation printers if their category wasn't listed as restricted. The change ensures all preparation categories are loaded, guaranteeing that items are correctly printed regardless of their category assignment. This improves the reliability of preparation receipts.
Original PR description
Since this PR https://github.com/odoo/odoo/pull/225658, if the POS category of a combo item product was not listed under the restricted categories but was assigned to a preparation printer, the item would not be printed by the preparation printer. This commit ensures that preparation categories are loaded, preventing any used category from being missed. Enterprise PR: https://github.com/odoo/enterprise/pull/110470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231733
This update resolves a bug where combo items weren't printed correctly when assigned to preparation printers. The fix ensures that all relevant preparation categories are loaded, preventing missed categories and ensuring accurate printing of these items. This improves the reliability of the POS system.
Original PR description
Since this PR https://github.com/odoo/odoo/pull/225658, if the POS category of a combo item product was not listed under the restricted categories but was assigned to a preparation printer, the item would not be printed by the preparation printer. A test was already present to check this, but the validation method was incorrect (test_restricted_categories_combo_product) This commit ensures that preparation categories are loaded, preventing any used category from being missed. X-original-commit: b9cf922f9f4a29bc2e6d7d51c9698e8ff97a85c6
This update resolves a technical problem that prevented users from correctly filtering job postings within the website's HR recruitment module. The issue stemmed from an unsupported comparison operator ('==') when dealing with recordsets in the filters. This fix ensures the job filter functionality works as intended for all users.
Original PR description
When `selection` is a recordset, `==` is an unsupported operand type
This update enhances the 'My Team' filter in Live Chat reports to accurately reflect the team members of the current user and their direct managers. Previously, the filter was limited to department-based reporting, now it provides a more comprehensive view of team members, improving reporting accuracy and team management insights.
Original PR description
Replace the department-based domain with a hierarchy-based domain in livechat reports. The new filter includes the current user's records and the records of employees whose manager is the current user. task-6030147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test issue where simultaneous data synchronization within the Point of Sale (POS) tax module caused errors. The fix ensures that backend processes complete before the test continues, improving test reliability and stability. This enhances the overall quality of the POS tax functionality.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872
This update fixes an issue where the SVL (Stock Valuation Layer) values were incorrectly calculated for dropshipping backorders created with bills. The fix ensures that the SVL values accurately reflect the quantity of the product, preventing discrepancies in inventory valuation. This improves the accuracy of financial reporting for dropshipping transactions.
Original PR description
…order dropship **Problem:** when the backorder of the delivery (with a bill) of a dropshipped fifo/avco product is validated, the svl created don't have the right values **Steps to reproduce:** -…
…order dropship **Problem:** when the backorder of the delivery (with a bill) of a dropshipped fifo/avco product is validated, the svl created don't have the right values **Steps to reproduce:** - create a new product, with dropship and buy routes - in the purchase tab select "on ordered quantities" - add a vendor with a price of 10 - create a new quotation for a quantity of 10 - confirm and confirm the purchase order - click on "create bill" and confirm it - go back to the PO and click on the "dropship" smart button - change the quantity to 5, validate and create backorder - go back to the PO, click on the "dropship" smart button and select the picking of the backorder (with status ready) - validate - click on the "valuation smart" button **Current behavior:** the svl created for the backorder have a value of 100 and -100 **Expected behavior:** it should be 50 and -50 **Cause of the issue:** inside _get_dropshipped_svl_vals _get_price_unit is called https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/stock_account/models/stock_move.py#L219 because we created a bill and it's a backorder line.qty_invoiced is higher than received_qty and this condition is true https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L51 but because it's a dropship there is as much positive svl as negative svl linked to the move so receipt value is null https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L56-L63 and remaining value will be 100 instead of 50 (receipt value should have been 50) https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L80 **fix** the negative svl from the dropshipped move should not impact receipt value opw-4888827 Forward-Port-Of: odoo/odoo#224288 Forward-Port-Of: odoo/odoo#216899
This update resolves an issue where upload widgets within dropdown menus on small screens wouldn't function correctly. The fix ensures that clicking the dropdown item doesn't immediately close it, allowing the widget action to complete successfully. This improves usability for users accessing Odoo on mobile devices.
Original PR description
## Issue: On small screens, when an upload widget is placed inside a dropdown (e.g., Upload Bill from a Purchase Order), the action does not work Clicking the dropdown item closes the dropdown immediately, which prevents the widget action from completing ## Cause: Widget actions require an accessible anchor element to function properly. However, dropdown items automatically close the dropdown on click As a result, the widget is triggered but immediately detached from the DOM before its action can fully execute ## Steps to reproduce: - Install `purchase_stock` (to have the Upload Bill widget available) - Create and confirm a Purchase Order (the Receive button must be available) - Reduce the browser width until the action buttons collapse into the three-dots menu - Click Upload Bill and try to upload a document opw-5918379
This update prevents an infinite loop in the system's credit note processing. Previously, credit notes were incorrectly polled, leading to unnecessary checks. The fix restricts the polling process to only invoices, ensuring efficiency and stability.
Original PR description
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de…
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever. Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint. Fix: restrict the cron domain to out_invoice only Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain. After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop. opw-5933833 Forward-Port-Of: odoo/enterprise#109995
This update fixes an issue where resending invoices to MER would overwrite existing addendums, even if the invoice hadn't been sent. The change ensures that existing addendums are updated instead of replaced, streamlining the resend process and preventing data loss. This improves invoice processing reliability.
Original PR description
Issue: when resending an invoice already sent to MER, the existing addendum is overwritten even when the invoice is not sent to MER. Solution: updating values on the existing addendum rather than creating a new one, if it already exists. task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253281
This update resolves a minor issue where the helpdesk tour would intermittently fail due to timing problems when creating new tickets. The fix ensures the tour waits for the kanban view to fully load before attempting to click the 'New' button, improving overall tour reliability. This prevents the tour from incorrectly targeting elements on the page.
Original PR description
This PR fixes a flickering failure in the `helpdesk_tour` ### Problem In the kanban view, the tour occasionally tried to click the "New" (quick create) button before the view's internal structure was fully painted. This caused the tour to click a wrong element. ### Solution Updated the step trigger to include a selector for the kanban group (`.o_kanban_group`). By requiring the presence of the group container, we ensure that: 1. The page content has actually loaded. 2. The specific "New" button within the kanban context is visible and ready. **Runbot ID: 223081**
This update resolves an issue where clicking on 'reply' links within Odoo mailboxes didn't function correctly. The change ensures that clicking on a reply link now automatically jumps to the original message thread, improving the user experience and streamlining communication workflows. This fix enhances the usability of the mail functionality.
Original PR description
Before this change, clicking on a `message in reply` in mailboxes had no effect. The expected behavior is for it to jump to the message in its origin thread. To fix it, this commit ensures that `useMessageHighlight` hook receives the correct thread which in this case is the origin thread of the message in reply. task-5343804 Forward-Port-Of: odoo/odoo#253589 Forward-Port-Of: odoo/odoo#253334
This update ensures that Danish SEPA payments are correctly formatted with the necessary FIK reference information. The change refactors the XML generation process to handle country-specific reference formats, improving compliance and future-proofing the system.
Original PR description
Issue: - A related PR introduced Danish FIK payment references on customer invoices. - The generated SEPA payment XML did not include this reference, resulting in missing structured communication for Danish payments. IMP: - Extended the SEPA payment XML generation to include the Danish FIK reference when present. - Refactored the structured reference XML builder to use lxml elements instead of string-based XML construction, ensuring proper escaping of structured references. Impact: - Ensures compliant Danish SEPA payments with correct FIK references. - Makes SEPA XML generation future-proof for country-specific structured references containing non-numeric characters. Related PR: https://github.com/odoo/odoo/pull/240829 Task: 5401553 Forward-Port-Of: odoo/enterprise#102612
This update resolves an issue where reconciling expenses linked to multiple legacy accounts would cause the system to crash. Now, when multiple expenses share a common account, the system correctly identifies it and allows reconciliation. This ensures accountants can accurately manage older expense data.
Original PR description
back port of #239539 The aim of this commit is to allow accountants to be able to reconcile legacy <account.move> linked to several expenses. Context: With the refactoring of the expense module, we made the assumption that an expense paid by the company will generate one <account.move>. This is True within the new system but is wrong regarding legacy data and those weren't adapted through an upgrade script. Before this commit: Trying to reconcile an <account.move.line> that is already linked to another one from which it's <account.move> is linked to several expenses will crash while we try to get the relevant account to compute the needed_terms on the <account.move>, even if all the expenses will result in giving back the same account. After this commit: We check if all the expense retrieve the same account. If they do, we just retrieve it. If not, we throw a UserError instead of a weird singleton error. opw-5930789 Forward-Port-Of: odoo/odoo#249132
This update resolves an issue that prevented users from copying spreadsheets within Odoo. The fix corrects a technical error that disabled the copy button, ensuring users can now seamlessly duplicate spreadsheets as needed. This improves usability and efficiency for spreadsheet-based workflows.
Original PR description
Fix error which disabled the copy button. 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
A bug preventing users from copying spreadsheets has been resolved. This update corrects a technical error that disabled the copy button, ensuring seamless spreadsheet functionality for all users. This fix improves the user experience and prevents data loss.
Original PR description
Fix error which disabled the copy button.
This update fixes an issue where timesheet descriptions were not consistently grouped after edits within the grid view. The fix ensures that when a timesheet line is updated, a new line with the same description is created, maintaining accurate grouping and reporting. This improves data clarity and accuracy for timesheet management.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#108894
This update fixes an issue where overpayments made via bank payment in Point of Sale didn't create accounting entries, leading to incorrect customer balances. The fix ensures that a necessary accounting line is created when a customer pays more than the order amount using a bank payment, accurately reflecting the transaction.
Original PR description
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the…
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the order amount with bank pm * Validate * Close register * Check customer > Observation: It says we owe the customer money, although change was given. Why the fix: ------------ Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it. Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted. opw-5149700 Forward-Port-Of: odoo/odoo#253311 Forward-Port-Of: odoo/odoo#247621