Daily updates from Odoo
Monday, July 27, 2026
209 changes
27 changes
Resolved issues and error corrections
This fixes Peppol settings so companies are only required to choose a purchase journal when it is actually needed. Non-French companies using Documents for Peppol imports are no longer blocked by French PDP-related requirements, and imports go to the selected destination only.
Original PR description
Fixes the settings view for the account_peppol_purchase_journal_id. account_peppol, documents_account_peppol and l10n_fr_pdp all wants to use a specific condition for the required attribute of the view. With PDP especially, once l10n_fr_pdp is installed, the view forces the base condition, even if documents_account_peppol is installed, and even if the company is not even French. On a non-French company registered/registering on Peppol, the journal shouldn't be mandatory if documents_account_peppol_folder_id is set up. To ease things up, it is now using a computed field. task-6304479 Forward-Port-Of: odoo/enterprise#120721 Forward-Port-Of: odoo/enterprise#120717
This fix ensures accounting reports correctly recognize when no report section has been opened yet. It helps prevent incorrect navigation or display behavior when users open financial reports.
Original PR description
**Root Cause:**
At [1], the condition `this.lastOpenedSectionByReport === {}` always
return `false` because JavaScript compares objects by reference
rather than by value. As a result, the code never detects when
`lastOpenedSectionByReport` is empty.
**Fix:**
This commit ensures the code correctly detects an empty
`lastOpenedSectionByReport` object.
[1]:
https://github.com/odoo/enterprise/blob/ae4b461edb1d6b49c25d4e264380e7ae4b67f10c/account_reports/static/src/components/account_report/controller.js#L50
**No task ID**
Forward-Port-Of: odoo/enterprise#125325
Forward-Port-Of: odoo/enterprise#124223The trial balance report now avoids displaying extremely small leftover amounts caused by decimal rounding when an account should balance to zero. This prevents confusing values from appearing in exported XLSX reports and improves confidence in financial reporting.
Original PR description
Steps to reproduce -------------------- - Install account_reports module; - Create a new account; - Create a miscellanous operation for the previous month using thenew account with a credit amount of $8.28; - Create a second MISC for the current month with two lines using the account : debit = 262.67 and credit = 254.39; - Open the trial balance report and filter the new account (end balance should be 0); - Export the report as XLSX; The end balance value is 2.84e-14 due to float rounding issues. opw-6369016 Forward-Port-Of: odoo/enterprise#125416 Forward-Port-Of: odoo/enterprise#123896
This fix keeps existing tax returns consistent when their allowed workflow steps are changed, such as during upgrades. It prevents errors in return lists by moving returns out of statuses that are no longer allowed and ensuring required workflow settings are present.
Original PR description
To reproduce the issue: 1) Create a company in Belgium 2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only…
To reproduce the issue: 1) Create a company in Belgium 2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only accepts "review" and "submit" stages, not "paid" anymore 4) Go to the list of returns, remove the TODO filter => traceback The problem is here that the existing returns don't recompute their state when the workflow of the type is modified. In some cases, this is fine, but it others, it's annoying. In our example, the terminal state changed, so all the returns in that terminal stage should change their state to the new terminal one. "paid" is not an accepted value anymore, it should become "submitted". Moreover, when the workflow is changed, the selection field actually containing the state must also change. As it is, it seems to work because "state" of account.return is stored, but the value it's based on (the workflow field) won't be consistent with it. It's not annoying now, but those inconsistencies could become a big source of trouble in the future (we know that from experience ... I'm looking at you, version 8 ! è-é). This issue typically happens at upgrade. We had cases in FR and AE already. We solve that by a generic override of the write to sort things out when such change needs to happen. An upgrade PR will also be done to adapt the script so that we eventually solve the inconsistencies on dbs that have already migrated to 19.0. Forward-Port-Of: odoo/enterprise#124934 Forward-Port-Of: odoo/enterprise#124144
Automatic timesheet suggestions now correctly link time related to Discuss to the Discuss app rather than the general database. This helps keep suggested work entries categorized accurately for easier review and reporting.
Original PR description
## Previous Behavior: When generateing AW sugestions, discuss related time would be associated to the DB and not the discuss app inside the database. ## Task task-[5167914](https://www.odoo.com/odoo/project/4105/tasks/5167914/project.task/6381120/project.task/6409826) Forward-Port-Of: odoo/enterprise#125339
Philippines check printing now rounds the cents portion of written payment amounts to two decimals, even when the currency is configured with more precision. This prevents confusing or incorrect check text such as showing four decimal digits in the xx/100 amount.
Original PR description
Current behavior: --- When paying with checks, if the currency has more than 2 decimals, the decimal amount is printed with more than 2 decimals. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. In the PHP currency, change rounding factor to 0.0001 4. In Decimal accuracy > product price, set 4 digits 5. Create a new Vendor Payment, payment method Check, amount 100.1268 PHP 6. Results: One Hundred and 1268/100, should be 13/100 Expected behavior: --- The xx/100 part of amount in words text in the check should always be rounded to 2 decimals. opw-6302337 Forward-Port-Of: odoo/enterprise#124572 Forward-Port-Of: odoo/enterprise#121913
This fix prevents an access error when an authorized manufacturing user edits a manufacturing order linked to a sales order they are not allowed to view. It keeps production work moving while preserving sales document access restrictions.
Original PR description
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a…
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a sale order for A unit of P - Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO) - Open the MO, add a component line and save #### > Access Error: Blame the following rule: - Personal Order ### Cause of the issue: Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423 During this confirmation process, one calls the `_merge_moves` method in order to merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576 Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO: https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40 However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49 Community: https://github.com/odoo/odoo/pull/271017 opw-6275658 Forward-Port-Of: odoo/enterprise#121845 Forward-Port-Of: odoo/enterprise#121135
The barcode app now correctly finds manufacturing orders that were split into multiple related orders. This prevents users from seeing a false “not found” error when scanning the original manufacturing order name, keeping shop floor workflows moving smoothly.
Original PR description
### Steps to reproduce: - Create a product FP with a BOM: 1 X COMP (enough units in stock) - Create and confirm an MO for 3 units - Click on the cog wheel icon > Split the MO in 3 - On the barcode app > Operations > Manufacturing - Scan the name of your base MO #### > Error: No product or order found for barcode ... ### Expected behavior: Scanning an existing MO only adds its barcode as a `search_default_name`: https://github.com/odoo/enterprise/blob/598a8e335605fd68e3ceb5c1170864243426f994/stock_barcode_mrp/models/mrp_production.py#L162-L178 However, while this search is performed with an ilike, we only check the existence of an exact match before raising an error, which does not happen since our splitted MOs have a name: barcode-001, barcode-002, barcode-003,... opw-6376937 Forward-Port-Of: odoo/enterprise#123931
A test issue in the Knowledge app was corrected so an unrelated collaboration connection from a previous test no longer interferes. This helps keep automated validation stable and avoids false build failures without changing user-facing behavior.
Original PR description
This aims to fix Runbot build error #937788 ([1]). A collaboration error was thrown during a tour which makes no use of collaboration. This makes sure the bus from the previous test doesn't persist when running this tour so it doesn't interfere. [1]: https://runbot.odoo.com/odoo/runbot.build.error/937788 Forward-Port-Of: odoo/enterprise#125509
French VAT declarations now handle SIRET numbers that include spaces, reducing failed submissions caused by formatting differences. Users are also warned when bank account numbers appear incorrectly formatted, helping prevent submission errors before they happen.
Original PR description
This commit resolves an issue where VAT declarations failed when the provided SIRET number included spaces. Since check_siret verifies the format, we now strip all spaces from the input. Additionally, this commit introduces a validation for bank account numbers, ensuring that we warn the user if the account number is wrongly formatted. task-6253745 Forward-Port-Of: odoo/enterprise#125311 Forward-Port-Of: odoo/enterprise#120689
Uploading a document while Auto Sort is enabled no longer triggers an error when the document is automatically moved to another folder. This keeps the Documents workflow stable and avoids interrupting users after sortable uploads.
Original PR description
When Auto Sort is enabled, an uploaded document can be moved to a different folder as part of the sort. The subsequent model reload only fetches records for the current folder to select/scroll to the new record. But, the new document's is absent from `env.model.root.records`. `newRecords` ends up empty, making `newRecords[0]` undefined, which then crashes accessing record.resId. To fix this, we just return early because if the record isn't in the current folder, there's nothing to select or scroll to anyway, so returning early here doesn't change anything visible behavior, it just avoids the crash. Steps to reproudce: 1.Go to Documents. 2.Go to Company->Inbox 3.Go to the gear icon and make sure the "Auto Sort" is enabled with "Move to folder" 4.Add a new document that's sortable. 5.You'll get the error. opw-6281558 Forward-Port-Of: odoo/enterprise#121069
Users who run automatic bank reconciliation with no statement lines available will now see a warning instead of an error. This prevents a confusing crash and makes the accounting workflow clearer when there is no work to process.
Original PR description
Currently, an error occurs when user tries to reconcile when there are no bank statements to reconcile. Steps to replicate: - Install `accountant` with demo. - Open Accounting and Click `To…
Currently, an error occurs when user tries to reconcile when there are no bank statements to reconcile. Steps to replicate: - Install `accountant` with demo. - Open Accounting and Click `To Reconcile` on the Bank Journal. - Go to the list view > Select all > From the Cog menu > Reset to draft. - Again select all and delete all the statement lines. - From Cog menu click on `Run Auto Reconciliation` > Run. Error: ``` SyntaxError: syntax error at or near ')' LINE 44: WHERE st_line.id IN () ``` Cause: - Error occurs because the [search] returns no results and the method `_try_auto_reconcile_statement_lines()` is called on an empty recordset. - Later in the flow the function `_partner_mapping()` [1] is call which makes the `self.ids` as empty tuple [2] this causes the query to have a syntaxerror. Solution: - When there are no statement lines to reconcile we show a warning notification. [search]: https://github.com/odoo/enterprise/blob/ec408cb9a569f321afc99f4065a7a0f545d4faf4/account_accountant/wizard/bank_rec_auto_reconcile_wizard.py#L21-L27 [1]: https://github.com/odoo/enterprise/blob/ec408cb9a569f321afc99f4065a7a0f545d4faf4/account_accountant/models/account_bank_statement.py#L427 [2]: https://github.com/odoo/enterprise/blob/1516209ee077cda03155686d1377eb70080538f1/account_accountant/models/account_bank_statement.py#L620 sentry-7615011817
The US Profit and Loss report now continues to open even if optional summary lines, such as Gross Profit, have been removed from the report configuration. This prevents an unexpected error and lets businesses customize their financial reports more safely.
Original PR description
## Steps to Reproduce: 1. Install the Accounting module with demo data. 2. Enable developer mode. 3. Go to Reporting > Profit and Loss. 4. Click Configuration and delete the 'Gross Profit' line. 5. Return to the report. ## Error: `ValueError: External ID not found in the system: l10n_us_reports.pl_gross_profit` ## Cause: The report assumes the summary lines always exist and tries to fetch XML IDs. If any of these lines has been deleted, looking up will raises an error. ## Fix: Only apply the bold class to summary lines whose XML IDs are available. sentry-7601831925 Forward-Port-Of: odoo/enterprise#125200 Forward-Port-Of: odoo/enterprise#124011
Users with IoT access but without Point of Sale access can now enable LNA on an IoT box without encountering an access error. This helps authorized IoT users complete device setup without needing extra POS permissions.
Original PR description
Before this commit, if a user who has IoT permissions but not POS permissions tries to enable LNA on an IoT box record, they will receive an Access Error. After this commit, a `sudo` is added to the `onchange` handler fixing the issue. task-6392548 Forward-Port-Of: odoo/enterprise#124656
This fix prevents Swiss payroll processing from failing when a payroll rule has been archived. It helps keep payroll value calculations and related transmissions stable even when older rules are no longer active.
Original PR description
Forward-Port-Of: odoo/enterprise#103677
The salary attachment form now shows the refund option again, matching information that was already stored in the system. This helps payroll users correctly view and manage refund-related salary attachments without needing to use a separate wizard.
Original PR description
In an old PR (https://github.com/odoo/enterprise/pull/109195) the is_refund field was removed from the salary attachment view, although the field itself was not removed from the db. In a later PR (https://github.com/odoo/enterprise/pull/114188) the field was removed from the database but later reverted (https://github.com/odoo/enterprise/pull/123728). As it stands now, the field is in the database and is present in the view of a wizard but not in the standard form view of the salary attachment. This PR is reintroducing it. Task: 6415857 Forward-Port-Of: odoo/enterprise#125420
This fixes a display issue where Avalara tax fields could be hidden on contact and product forms when company and country information included both US and Canada. Businesses using Avalara can now see and manage the relevant tax codes and exemption details more reliably.
Original PR description
**Steps to reproduce:**
- Install Accounting and account_avatax
- Use a US company (by default)
- Create a contact with Canada as country
**Issue:**
In "Sales & Purchase" tab, all the fields from avatax module are not displayed (i.e. "Avalara Code", "Avalara Partner Code", "Avalara Exemption").
**Cause:**
The `invisible` property of those fields is using `fiscal_country_codes` char field.
If no company is set on the record, `fiscal_country_codes` will contain the country code of the selected companies in addition to the country code of the record.
In this case, the value of `fiscal_country_codes` will be `US,CA` string, which triggers `fiscal_country_codes not in ('US', 'CA')` invisible condition.
opw-6328395
Forward-Port-Of: odoo/enterprise#124619Fixes an issue where deleting a Knowledge article linked to an Annual Report could cause the automated cleanup process to fail. The cleanup now also removes the related annual report record, preventing background errors and keeping accounting review data consistent.
Original PR description
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install…
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``accountant_knowledge`` module - Go to Accounting > Review > Annual Report > Create a new annual report - Go to Knowledge > Open the knowledge article linked to the annual report > Send to Trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "knowledge_article" violates foreign key constraint "audit_report_knowledge_article_id_fkey" on table "audit_report" DETAIL: Key (id)=(67) is still referenced from table "audit_report". ``` https://github.com/odoo/enterprise/blob/04cce2e400ce2e412f28aa1849078a7c40ff0e2c/knowledge/models/knowledge_article.py#L1069-L1070 The garbage collector deletes trashed knowledge articles that match its domain. Since this domain also includes articles linked to Annual Reports, the cron attempts to delete records that are still referenced by annual report, resulting in a foreign key violation error. Solution: Ensure linked audit reports are also deleted during knowledge article garbage collection. sentry-7488793071 Forward-Port-Of: odoo/enterprise#125323 Forward-Port-Of: odoo/enterprise#121189
This fix restores the validation workflow for Indian GSTR tax returns after a parent view change broke the return screen. Users can continue validating GSTR returns with the expected dedicated process, while the interface now uses the updated shared validation button structure.
Original PR description
Fixed the broken view for indian tax returns due to parent view refactor. Update the Indian GSTR return workflow to: - adapt the kanban button inheritance to the new view structure, - preserve the custom GSTR Validate button independently of unresolved checks, - Keep the GSTR-specific validation workflow unchanged. - remove indian loc specific validate button instead use from parent. - some code cleaning. task-6365198
The AI-powered SEO autofill now generates page titles and metadata in the website page's language instead of the logged-in user's language. This helps multilingual websites publish consistent, correctly localized SEO content for visitors and search engines.
Original PR description
The SEO "Fill with AI" autofill used the user's language for generation. On a website whose language differs from the user's, the generated seo metadata was therefore in the wrong language. This commit fixes this by using the page language instead. Forward-Port-Of: odoo/enterprise#123786 Forward-Port-Of: odoo/enterprise#123447
This fixes an issue that could cause equity transaction processing to fail when multiple transactions were handled at the same time. Users should experience fewer interruptions and error messages when working with cap table or equity transaction data.
Original PR description
When the ``_compute_security_price`` method is called on multiple records, a traceback will appear. Traceback: ```py ValueError: Expected singleton: equity.transaction(1, 2) ``` https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/equity/models/equity_transaction.py#L218 The method filters newly created records using ``self._origin.id``. Since ``self`` is the whole recordset, accessing ``self._origin.id`` on multiple records raises a singleton error. sentry-7626410485 Forward-Port-Of: odoo/enterprise#125307
This fix ensures Saudi GOSI contributions are calculated without being incorrectly prorated. It helps payroll teams produce more accurate payslips and accounting entries for employees covered by Saudi payroll rules.
Original PR description
task-id: 6380239 Forward-Port-Of: odoo/enterprise#124807 Forward-Port-Of: odoo/enterprise#124122
Fixes an issue where the Trial Balance report could fail when loading more partner-grouped lines for Colombian accounting reports. Users can now expand accounts and load additional lines reliably, even when some report data has empty column details.
Original PR description
…umn dict Steps to reproduce: - Install l10n_co_reports and select CO company - Open the trial balance grouped by partner variant - Set the load more limit to 2 - Go back to report, unfold an account, and press load-more line -> Traceback because it's expected the column dict to contain a column group. The report engine, however, accepts lines with empty dicts. Therefore, the trial balance should handle this case. task-6384451 Forward-Port-Of: odoo/enterprise#124506 Forward-Port-Of: odoo/enterprise#124102
This fix ensures Brazilian Avalara tax requests keep required customer tax settings even when their values are empty or false. It prevents Avalara from assigning the wrong fiscal operation code, helping invoices use the correct Brazilian tax treatment.
Original PR description
## Steps to reproduce: 1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`. 2. Ensure that Demo mode is activated if not on Runbot. 3. Navigate to Contacts, then click into "BR…
## Steps to reproduce:
1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
1. Tax Regime set to individual
2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
1. Customer set to the copy created earlier.
2. Operation Type set to Sale of Goods
3. Document Type set to 55
4. Payment Method Brazil set to Money
5. Presence set to Present
6. One sales order line with:
1. Regular Consumable Product
2. quantity set to 1
3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.
Explanation:
PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.
However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.
opw-6085964
Forward-Port-Of: odoo/enterprise#124730
Forward-Port-Of: odoo/enterprise#120783Users who start an AI chat can still be prompted to reopen their most recent relevant conversation after refreshing the page. This makes it easier to continue prior AI interactions while avoiding duplicate prompts when that chat is already open.
Original PR description
Purpose: -------- When launching an AI chat, users can be suggested to reopen the latest non-empty chat matching the same interface key and record. This suggestion used to rely on chats already present in the frontend store, so it was lost after a page reload. With this commit, the suggested channel is selected by the backend whenever the AI channel is added to the store and included in its channel data. This keeps the suggestion available after a page reload while hiding it when the previous chat is already open, but not when it is minimized. Task-6354153
Export invoices in Uruguay can now correctly show discounts that reduce the invoice total to zero. This helps exporters meet electronic invoicing validation requirements while still declaring the value of goods or services.
Original PR description
## Problem When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not…
## Problem When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not handled correctly by the XML/CFE generation logic. This use case is valid and required by exporters who need to reflect the declared value of goods/services while invoicing at zero (e.g. to comply with customs or incoterm requirements such as FCA). In Uruware's validation portal, the "Descuentos y Recargos" (discounts & surcharges) section of the subtotal block must be correctly populated for the CFE to be accepted. **Example:** An invoice with a line of 648.00 UYU and a global discount of −648.00 UYU → Total: 0.00. The export value is still declared, taxes are zero, but the CFE must reflect the discount amount explicitly. <img width="592" height="679" alt="example_expo_invoice_discount" src="https://github.com/user-attachments/assets/aa83c158-e342-4da5-a251-fc209bbed5c4" /> ## Root Cause The CFE template (`cfe_template.xml`) and the move computation logic (`account_move.py`) did not account for the case where export invoices carry line-level or global discounts that zero out the total. The discount amount was either omitted from the XML nodes or computed incorrectly, causing Uruware validation to fail or the discount block to not render. ## Fix - **`l10n_uy_edi/models/account_move.py`** — Updated the export invoice computation to correctly include discount amounts in the CFE data dict, ensuring the `ValorDR` is filled with the value of the discount per line. - **`l10n_uy_edi/views/cfe_template.xml`** — Adjusted the template condition so `MntExpoyAsim` node accepts 0 as value. ## Steps to Reproduce (before fix) 1. Create an export invoice (e-Factura Exportación) for a foreign partner. 2. Add a product line with a unit price, e.g. 216.00 × 3 = 648.00 UYU. 3. Add a global discount of 648.00 (same amount) so the total is 0.00. 4. Confirm and send to Uruware — the CFE is rejected / discount block is missing. ## Verification After the fix, the same invoice generates a valid CFE accepted by Uruware with the discount correctly reflected in the `DscRcgGlobal` node and the discount line visible on the printed document. Forward-Port-Of: odoo/enterprise#124910 Forward-Port-Of: odoo/enterprise#120130
This fixes where Mexican CFDI invoice fields are placed so they remain visible even when Colombian e-invoicing features are also installed. It prevents important Mexican invoice information, such as CFDI Origin, from disappearing due to module layout conflicts.
Original PR description
The CFDI fields used //sheet/group//group[last()], which targets the last group by position. Once l10n_co_edi adds its group after header_right_group, the fields land in it instead, and it is invisible unless country_code is CO, so CFDI Origen disappears on MX invoices. Use //group[@id='header_right_group'], like l10n_co_edi already does, so placement no longer depends on what modules are installed. Task Adhoc side: 67269 Forward-Port-Of: odoo/enterprise#124545
12 changes
Resolved issues and error corrections
Deleting a Knowledge article linked to an Annual Report no longer causes the automated cleanup process to fail. The fix keeps related Annual Report data consistent during cleanup, avoiding unexpected errors for accounting teams.
Original PR description
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install…
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``accountant_knowledge`` module - Go to Accounting > Review > Annual Report > Create a new annual report - Go to Knowledge > Open the knowledge article linked to the annual report > Send to Trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "knowledge_article" violates foreign key constraint "audit_report_knowledge_article_id_fkey" on table "audit_report" DETAIL: Key (id)=(67) is still referenced from table "audit_report". ``` https://github.com/odoo/enterprise/blob/04cce2e400ce2e412f28aa1849078a7c40ff0e2c/knowledge/models/knowledge_article.py#L1069-L1070 The garbage collector deletes trashed knowledge articles that match its domain. Since this domain also includes articles linked to Annual Reports, the cron attempts to delete records that are still referenced by annual report, resulting in a foreign key violation error. Solution: Ensure linked audit reports are also deleted during knowledge article garbage collection. sentry-7488793071 Forward-Port-Of: odoo/enterprise#125323 Forward-Port-Of: odoo/enterprise#121189
Philippines check printing now rounds the cents portion of written amounts to two decimals, even when the currency is configured with more precision. This prevents confusing or incorrect check text such as showing four decimal digits in the cents field.
Original PR description
Current behavior: --- When paying with checks, if the currency has more than 2 decimals, the decimal amount is printed with more than 2 decimals. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. In the PHP currency, change rounding factor to 0.0001 4. In Decimal accuracy > product price, set 4 digits 5. Create a new Vendor Payment, payment method Check, amount 100.1268 PHP 6. Results: One Hundred and 1268/100, should be 13/100 Expected behavior: --- The xx/100 part of amount in words text in the check should always be rounded to 2 decimals. opw-6302337 Forward-Port-Of: odoo/enterprise#124572 Forward-Port-Of: odoo/enterprise#121913
The timesheet timer now automatically returns the cursor to the description field after users save or reset an entry. This removes an extra click when entering multiple timesheets and makes the workflow smoother.
Original PR description
Steps to reproduce: - Install the timesheets application. - Open the timesheet timer menu from the systray. - Fill out the new timesheet entry. - Click the 'Save' or 'Reset' button (or use the keyboard hotkey). - Notice that the cursor focus is lost and the user must manually click back into the description field to start a new entry. Cause: - When a user clicks save or reset, the existing form is cleared via a DOM patch. Because the component is not remounted, the initial onMounted focus logic does not execute again. Fix: - Use onPatched to check if the save or discard button is the active element, and automatically re-focus the description input. task-6357438 Forward-Port-Of: odoo/enterprise#123697
Fixes an issue where Avalara tax fields could be hidden on contact and product forms when the selected company and record countries included both the US and Canada. This ensures users can correctly view and manage Avalara codes, partner codes, and exemptions for supported countries.
Original PR description
**Steps to reproduce:**
- Install Accounting and account_avatax
- Use a US company (by default)
- Create a contact with Canada as country
**Issue:**
In "Sales & Purchase" tab, all the fields from avatax module are not displayed (i.e. "Avalara Code", "Avalara Partner Code", "Avalara Exemption").
**Cause:**
The `invisible` property of those fields is using `fiscal_country_codes` char field.
If no company is set on the record, `fiscal_country_codes` will contain the country code of the selected companies in addition to the country code of the record.
In this case, the value of `fiscal_country_codes` will be `US,CA` string, which triggers `fiscal_country_codes not in ('US', 'CA')` invisible condition.
opw-6328395
Forward-Port-Of: odoo/enterprise#124619This fix prevents an access error when a manufacturing user with limited sales permissions updates a production order linked to a rental sale. It allows production work to continue without requiring visibility into sales orders the user is not allowed to access.
Original PR description
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a…
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a sale order for A unit of P - Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO) - Open the MO, add a component line and save #### > Access Error: Blame the following rule: - Personal Order ### Cause of the issue: Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423 During this confirmation process, one calls the `_merge_moves` method in order to merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576 Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO: https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40 However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49 Community: https://github.com/odoo/odoo/pull/271017 opw-6275658 Forward-Port-Of: odoo/enterprise#121845 Forward-Port-Of: odoo/enterprise#121135
The trial balance report now treats near-zero calculation differences as zero, preventing tiny floating-point amounts from appearing in XLSX exports. This avoids confusion when accounts that should balance to zero are reviewed or shared.
Original PR description
Steps to reproduce -------------------- - Install account_reports module; - Create a new account; - Create a miscellanous operation for the previous month using thenew account with a credit amount of $8.28; - Create a second MISC for the current month with two lines using the account : debit = 262.67 and credit = 254.39; - Open the trial balance report and filter the new account (end balance should be 0); - Export the report as XLSX; The end balance value is 2.84e-14 due to float rounding issues. opw-6369016 Forward-Port-Of: odoo/enterprise#125416 Forward-Port-Of: odoo/enterprise#123896
Fixed an issue where scanning the original manufacturing order barcode failed after the order was split into multiple orders. Users can now scan the base order name and find the related split manufacturing orders as expected, avoiding interruptions in barcode-based manufacturing workflows.
Original PR description
### Steps to reproduce: - Create a product FP with a BOM: 1 X COMP (enough units in stock) - Create and confirm an MO for 3 units - Click on the cog wheel icon > Split the MO in 3 - On the barcode app > Operations > Manufacturing - Scan the name of your base MO #### > Error: No product or order found for barcode ... ### Expected behavior: Scanning an existing MO only adds its barcode as a `search_default_name`: https://github.com/odoo/enterprise/blob/598a8e335605fd68e3ceb5c1170864243426f994/stock_barcode_mrp/models/mrp_production.py#L162-L178 However, while this search is performed with an ilike, we only check the existence of an exact match before raising an error, which does not happen since our splitted MOs have a name: barcode-001, barcode-002, barcode-003,... opw-6376937 Forward-Port-Of: odoo/enterprise#123931
Automated work suggestions now correctly classify Discuss-related time under the Discuss app instead of the database. This helps keep timesheet suggestions and reporting more accurate for users reviewing their activity.
Original PR description
## Previous Behavior: When generateing AW sugestions, discuss related time would be associated to the DB and not the discuss app inside the database. ## Task task-[5167914](https://www.odoo.com/odoo/project/4105/tasks/5167914/project.task/6381120/project.task/6409826) Forward-Port-Of: odoo/enterprise#125339
Fixes issues where cumulative translation adjustment lines could appear or be calculated incorrectly in financial reports, especially when using company comparisons, horizontal groupings, or search filters. This helps ensure trial balance and general ledger reports remain consistent with the filters and periods selected by the user.
Original PR description
The engine for the cumulative translation adjustment line was fully overriding the forced options, but this key might already be present in the options, for example, when using horizontal groups. task-6418960
This fixes an issue where the US Profit and Loss report could crash if a configurable summary line, such as Gross Profit, had been deleted. The report now skips missing summary lines when applying formatting, allowing users to continue viewing the report normally.
Original PR description
## Steps to Reproduce: 1. Install the Accounting module with demo data. 2. Enable developer mode. 3. Go to Reporting > Profit and Loss. 4. Click Configuration and delete the 'Gross Profit' line. 5. Return to the report. ## Error: `ValueError: External ID not found in the system: l10n_us_reports.pl_gross_profit` ## Cause: The report assumes the summary lines always exist and tries to fetch XML IDs. If any of these lines has been deleted, looking up will raises an error. ## Fix: Only apply the bold class to summary lines whose XML IDs are available. sentry-7601831925 Forward-Port-Of: odoo/enterprise#125200 Forward-Port-Of: odoo/enterprise#124011
This fix updates the Field Service planning module to use the latest internal mail tracking method name. It helps ensure planning changes continue to generate the correct activity or log messages after related platform updates.
Original PR description
Rename `_track_subtype` to `_track_log_get_default_subtype` to align with the updated mail tracking. Related Commit https://github.com/odoo/odoo/pull/248505/changes/9c1ce65cdd924b50df3eeef5c69cac110d1eb26b
Users with IoT access but without Point of Sale permissions can now enable LNA on IoT box records without hitting an access error. This removes an unnecessary blocker for teams managing IoT devices separately from POS operations.
Original PR description
Before this commit, if a user who has IoT permissions but not POS permissions tries to enable LNA on an IoT box record, they will receive an Access Error. After this commit, a `sudo` is added to the `onchange` handler fixing the issue. task-6392548 Forward-Port-Of: odoo/enterprise#124656
13 changes
Resolved issues and error corrections
Lazada and Shopee orders with vouchers, coins, discounts, or shipping fees are now imported so their Odoo totals match the marketplace totals. This reduces reconciliation discrepancies and makes marketplace sales reporting more reliable.
Original PR description
Marketplace orders with discount lines could not match the platform total: Odoo accumulated a small rounding residue vs Shopee's total_amount / Lazada's order price. sale_shopee ----------- Changes:…
Marketplace orders with discount lines could not match the platform total: Odoo accumulated a small rounding residue vs Shopee's total_amount / Lazada's order price. sale_shopee ----------- Changes: - Fetch buyer-side escrow amounts via `_fetch_order_income` and pass them through `self.env.context` (`order_income`). - Build item lines from the buyer-paid item price with `discount=0` and a recomputed tax-exclusive `price_unit`. - Distribute order-level discounts (seller/platform vouchers and coins) as dedicated negative lines per product tax group via `_prepare_discount_lines_values`. - Append a shipping line from `buyer_paid_shipping_fee` with fiscal-position mapped taxes. - Reconcile any leftover residue with `_adjust_order_total` using a single tax-free amount-adjustment line. - Register `default_discount_product` and configure it on upgrade (v1.1). sale_lazada ----------- - Port the same reconciliation model as shopee: reconciled line specs, discount=0 with discounted unit from paid_price, shipping line from shipping_fee, order-level "Discount line" distributed at order-level. task-6112062 Forward-Port-Of: odoo/enterprise#124953 Forward-Port-Of: odoo/enterprise#117561
This fix prevents scheduled cleanup from failing when a Knowledge article linked to an Annual Report has been moved to the trash. Linked annual report records are now cleaned up together, avoiding system errors during automatic maintenance.
Original PR description
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install…
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``accountant_knowledge`` module - Go to Accounting > Review > Annual Report > Create a new annual report - Go to Knowledge > Open the knowledge article linked to the annual report > Send to Trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "knowledge_article" violates foreign key constraint "audit_report_knowledge_article_id_fkey" on table "audit_report" DETAIL: Key (id)=(67) is still referenced from table "audit_report". ``` https://github.com/odoo/enterprise/blob/04cce2e400ce2e412f28aa1849078a7c40ff0e2c/knowledge/models/knowledge_article.py#L1069-L1070 The garbage collector deletes trashed knowledge articles that match its domain. Since this domain also includes articles linked to Annual Reports, the cron attempts to delete records that are still referenced by annual report, resulting in a foreign key violation error. Solution: Ensure linked audit reports are also deleted during knowledge article garbage collection. sentry-7488793071 Forward-Port-Of: odoo/enterprise#125323 Forward-Port-Of: odoo/enterprise#121189
This update fixes how Belgian payroll notification files are analyzed. It helps ensure payroll declarations are processed more reliably and reduces the risk of errors when handling official notification files.
Resetting a tax return no longer removes accounting entries that were only reconciled with that return. This protects existing invoices and related accounting records while still allowing the system to clear only the specific carryover amounts from prior tax returns.
Original PR description
Issue: Moves having a line reconciled to a tax return are unlinked if the tax return is reset. Steps to reproduce: - Set the tax account as reconcilable - Create an invoice for previous month and confirm it - Create a tax return for the previous month - Reconcile one of the invoice tax line to the tax return closing move. - Remove the lock date - Reset the tax return Current behavior: - all moves reconciled with the tax return are unlinked Expected behavior: - only moves comming from recoverable amount of previous tax returns should be unlinked opw-6370289
Users responsible for manufacturing can now update production orders linked to rental sales even when they only have access to their own sales documents. This prevents an unnecessary access error and helps teams keep production work moving without broadening sales order visibility.
Original PR description
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a…
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a sale order for A unit of P - Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO) - Open the MO, add a component line and save #### > Access Error: Blame the following rule: - Personal Order ### Cause of the issue: Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423 During this confirmation process, one calls the `_merge_moves` method in order to merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576 Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO: https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40 However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49 Community: https://github.com/odoo/odoo/pull/271017 opw-6275658 Forward-Port-Of: odoo/enterprise#121845 Forward-Port-Of: odoo/enterprise#121135
Fixes an issue where scanning the original manufacturing order barcode failed after the order was split. Users can now scan the base order name and find the related split manufacturing orders in the Barcode app, avoiding unnecessary interruptions on the shop floor.
Original PR description
### Steps to reproduce: - Create a product FP with a BOM: 1 X COMP (enough units in stock) - Create and confirm an MO for 3 units - Click on the cog wheel icon > Split the MO in 3 - On the barcode app > Operations > Manufacturing - Scan the name of your base MO #### > Error: No product or order found for barcode ... ### Expected behavior: Scanning an existing MO only adds its barcode as a `search_default_name`: https://github.com/odoo/enterprise/blob/598a8e335605fd68e3ceb5c1170864243426f994/stock_barcode_mrp/models/mrp_production.py#L162-L178 However, while this search is performed with an ilike, we only check the existence of an exact match before raising an error, which does not happen since our splitted MOs have a name: barcode-001, barcode-002, barcode-003,... opw-6376937 Forward-Port-Of: odoo/enterprise#123931
WinBooks imports now avoid incorrectly combining customer and supplier contact details when they share the same contact number but have different VAT numbers. This prevents import failures caused by invalid VAT validation and helps Belgian accounting data import more reliably.
Original PR description
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian…
When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly. Steps to reproduce: - Create a database with the Belgian localization installed - Install the account_winbooks_import module - Navigate to Accounting > Configuration > Settings > Initial Setup > Import - Import the WinBooks zip Issue: The import fails with the following error: The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx. Analysis: In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number. In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error. This change prevents the merger of partner data if their VAT numbers are explicitly different. opw-6251772 Forward-Port-Of: odoo/enterprise#119579
Bank reconciliation partner searches now include contacts belonging to parent companies of the selected branch companies, as well as global contacts. This helps users in multi-company setups find the right partner without manual workarounds.
Original PR description
When setting a partner from the bank reconciliation control panel, the partner lookup domain only considered global contacts and contacts directly linked to the selected company IDs. This caused a multi-company issue for branch companies, where users could not find contacts owned by their parent company. The domain is now updated to include: Global contacts (company_id = false) Contacts whose company is a parent of the selected companies (company_id parent_of companyIds) Forward-Port-Of: odoo/enterprise#118719
Uploading a document while Auto Sort is enabled no longer causes an error when the document is automatically moved to another folder. This keeps the Documents workflow stable and avoids interrupting users after sortable uploads.
Original PR description
When Auto Sort is enabled, an uploaded document can be moved to a different folder as part of the sort. The subsequent model reload only fetches records for the current folder to select/scroll to the new record. But, the new document's is absent from `env.model.root.records`. `newRecords` ends up empty, making `newRecords[0]` undefined, which then crashes accessing record.resId. To fix this, we just return early because if the record isn't in the current folder, there's nothing to select or scroll to anyway, so returning early here doesn't change anything visible behavior, it just avoids the crash. Steps to reproudce: 1.Go to Documents. 2.Go to Company->Inbox 3.Go to the gear icon and make sure the "Auto Sort" is enabled with "Move to folder" 4.Add a new document that's sortable. 5.You'll get the error. opw-6281558 Forward-Port-Of: odoo/enterprise#121069
This fix prevents Swiss payroll processing from failing when a related payroll rule has been archived. It helps keep monthly payroll data handling stable and avoids unexpected interruptions for HR teams.
Original PR description
Forward-Port-Of: odoo/enterprise#103677
This fix prevents an error that could occur when the system calculates security prices for multiple equity transactions at once. It helps keep equity transaction processing stable and avoids interruptions for users working with capitalization table data.
Original PR description
When the ``_compute_security_price`` method is called on multiple records, a traceback will appear. Traceback: ```py ValueError: Expected singleton: equity.transaction(1, 2) ``` https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/equity/models/equity_transaction.py#L218 The method filters newly created records using ``self._origin.id``. Since ``self`` is the whole recordset, accessing ``self._origin.id`` on multiple records raises a singleton error. sentry-7626410485 Forward-Port-Of: odoo/enterprise#125307
Customers can no longer complete payment for planning-based rental services when the required resources are already booked. The cart now checks planning availability before checkout, helping avoid paid orders that later fail because no resource is available.
Original PR description
**Problem:** On a website with rental planning enabled, a customer can book a planning-backed rental product through eCommerce even when no planning resource is free for the requested window. The…
**Problem:** On a website with rental planning enabled, a customer can book a planning-backed rental product through eCommerce even when no planning resource is free for the requested window. The cart lets them increase the quantity past the available capacity and proceed all the way through checkout without any availability gate. **Steps to reproduce:** 1. Install `website_sale_renting_planning`. 2. Create a planning role with `sync_shift_rental` and one resource. 3. Create a service product with `rent_ok=True`, `planning_enabled=True` and the role above. 4. Pre-book the resource for some window via a `planning.slot`. 5. From eCommerce, add the product to the cart for the same window. 6. Proceed to checkout/payment. **Current behavior:** The cart is considered ready, no warning is shown, and payment can proceed even though no planning resource is free for the chosen period. **Expected behavior:** The cart should be flagged as not ready and pre-payment validation should refuse to confirm until the customer picks a different date or quantity. **Cause of the issue:** `sale.order._available_dates_for_renting` in `website_sale_renting` is the documented hook for "stock availability" gating of the cart and pre-payment flow (called from `_is_cart_ready` and from `_check_cart_is_ready_to_be_paid`). `website_sale_stock_renting` overrides it to apply a per-line stock check, but `website_sale_renting_planning` has no such override, so planning-backed rental services reach payment with no availability gate at all. **Fix:** Apply the same gating pattern that `website_sale_stock_renting` already uses: override `_available_dates_for_renting` in `website_sale_renting_planning` so that, for each rental line whose product is a planning-synced rentable service, the cart is only considered valid when at least the requested quantity of planning resources is free during the rental window (mirroring the resource and leave filtering already done by `_planning_slot_vals_list_per_sol` at SO confirmation time). This puts the gate at the same point the stock-renting flow enforces it, keeping the public cart/checkout flow consistent across rentable product types. opw-6247034 Forward-Port-Of: odoo/enterprise#125478 Forward-Port-Of: odoo/enterprise#118943
Draft invoices no longer show clickable vehicle links on invoice lines. This keeps vehicle navigation consistent with product links, which only become available once the invoice is posted.
Original PR description
The vehicle under account on the invoice lines should not be clickable when the invoice is in draft. Only when it is posted, like the product. task-6385436
18 changes
Resolved issues and error corrections
Fixed an issue where scanning the original manufacturing order barcode failed after the order was split into multiple orders. Users can now find split manufacturing orders from the barcode app as expected, reducing interruptions during shop floor operations.
Original PR description
### Steps to reproduce: - Create a product FP with a BOM: 1 X COMP (enough units in stock) - Create and confirm an MO for 3 units - Click on the cog wheel icon > Split the MO in 3 - On the barcode app > Operations > Manufacturing - Scan the name of your base MO #### > Error: No product or order found for barcode ... ### Expected behavior: Scanning an existing MO only adds its barcode as a `search_default_name`: https://github.com/odoo/enterprise/blob/598a8e335605fd68e3ceb5c1170864243426f994/stock_barcode_mrp/models/mrp_production.py#L162-L178 However, while this search is performed with an ilike, we only check the existence of an exact match before raising an error, which does not happen since our splitted MOs have a name: barcode-001, barcode-002, barcode-003,... opw-6376937 Forward-Port-Of: odoo/enterprise#123931
Sendcloud shipments now include the recipient tax number in customs information when required. This prevents DPD delivery validation from failing for international customers with VAT numbers, allowing affected orders to be shipped normally.
Original PR description
Issue ----- Deliveries cannot be validated using DPD with Sendcloud, users get an error. Steps to reproduce ----- - Set up Sendcloud DPD - Create a SO - Interntional customer - Some VAT number - Some product - Add sendcloud delivery - Confirm SO - Validate the linked picking > Error: “The receiver VAT number is missing; please provide it to continue” Cause ----- Tax numbers should be included in the `customs_information` field of the request as per the API https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-customs-information-tax-numbers ----- Ticket: opw-6250860 Forward-Port-Of: odoo/enterprise#119399
The Peppol settings now correctly decide when a purchase journal is required, avoiding unnecessary mandatory setup for non-French companies using Documents. Choosing Documents for invoice import now routes imports only to Documents instead of duplicating them in Invoicing.
Original PR description
Fixes the settings view for the account_peppol_purchase_journal_id. account_peppol, documents_account_peppol and l10n_fr_pdp all wants to use a specific condition for the required attribute of the view. With PDP especially, once l10n_fr_pdp is installed, the view forces the base condition, even if documents_account_peppol is installed, and even if the company is not even French. On a non-French company registered/registering on Peppol, the journal shouldn't be mandatory if documents_account_peppol_folder_id is set up. To ease things up, it is now using a computed field. task-6304479 Forward-Port-Of: odoo/enterprise#120721
This fix keeps a clipboard-related test change limited to the exact step where it is needed, preventing leftover test state from affecting later checks. It helps maintain reliable automated testing for appointment-to-CRM flows without changing user-facing behavior.
Original PR description
Capturing `oldWriteText` at module import and relying on a subsequent tour step to restore it can cause state leakage if the subsequent step doesn't exactly target a resulting effect of the mocked `writeText` call. Refactor the tour step to capture `writeText` dynamically and restore the original method on first call. runbot-241004 Forward-Port-Of: odoo/enterprise#125290
This fix ensures Avalara tax-related fields appear correctly when creating or editing contacts in supported countries such as the United States and Canada. It prevents users from missing key tax setup options when company context includes multiple countries.
Original PR description
**Steps to reproduce:**
- Install Accounting and account_avatax
- Use a US company (by default)
- Create a contact with Canada as country
**Issue:**
In "Sales & Purchase" tab, all the fields from avatax module are not displayed (i.e. "Avalara Code", "Avalara Partner Code", "Avalara Exemption").
**Cause:**
The `invisible` property of those fields is using `fiscal_country_codes` char field.
If no company is set on the record, `fiscal_country_codes` will contain the country code of the selected companies in addition to the country code of the record.
In this case, the value of `fiscal_country_codes` will be `US,CA` string, which triggers `fiscal_country_codes not in ('US', 'CA')` invisible condition.
opw-6328395
Forward-Port-Of: odoo/enterprise#124619Users with manufacturing rights and limited sales access can now update manufacturing orders created from rental-related sales without hitting an access error. This prevents unnecessary work stoppages while keeping sales document visibility rules intact.
Original PR description
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a…
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a sale order for A unit of P - Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO) - Open the MO, add a component line and save #### > Access Error: Blame the following rule: - Personal Order ### Cause of the issue: Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423 During this confirmation process, one calls the `_merge_moves` method in order to merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576 Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO: https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40 However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49 Community: https://github.com/odoo/odoo/pull/271017 opw-6275658 Forward-Port-Of: odoo/enterprise#121845 Forward-Port-Of: odoo/enterprise#121135
Sales users without Project access can now add products from the catalog on quotations without seeing an access error. The change prevents the Field Service Sales module from checking project-related information when the user does not have the required Project permissions.
Original PR description
A user without Project rights cannot add a product from the catalog on a sale order Steps to reproduce: 1. Install industry_fsm_sale module 2. Go to Settings > Users & Companies > Users and open user Marc Demo 3. Set Field Service and Project rights to No 4. Log in as Marc Demo 5. Go to Sales and open any quotation 6. Click on Catalog in the order lines 7. An access error is raised Issue: industry_fsm_sale overrides `action_add_from_catalog` and tries to read sale.order.tasks_ids but users can't always access this field as it requires Project rights Solution: Check that the user has Project rights before trying to read tasks_ids opw-6315647 Forward-Port-Of: odoo/enterprise#123228
Bank reconciliation partner search now includes contacts belonging to parent companies of selected branch companies, not just global or directly linked contacts. This helps multi-company users select the right partner without manual workarounds.
Original PR description
When setting a partner from the bank reconciliation control panel, the partner lookup domain only considered global contacts and contacts directly linked to the selected company IDs. This caused a multi-company issue for branch companies, where users could not find contacts owned by their parent company. The domain is now updated to include: Global contacts (company_id = false) Contacts whose company is a parent of the selected companies (company_id parent_of companyIds) Forward-Port-Of: odoo/enterprise#118719
This fix stops the Mexican electronic invoicing status check from repeatedly reprocessing the same documents, which could cause unnecessary background workload. It prioritizes older customer invoices and limits vendor bill checks to the relevant period, helping keep tax status updates reliable and efficient.
Original PR description
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid…
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid re-processing what we already check within the last 4 hours/12 hours depending on the type of the document. - The domain takes the *static* create date instead of the write_date to make sure we don't endless re-process the same record and that the window of 7/60 days applies. - Limit the Vendor Bill to be checked only during 7 days after their creation. - Use the create_date in the order of the search to ensure we process older records first, before their time-window closes. - Process the Vendor Bills last, this ensure Customer Invoices will be processed in priority in case we are not able to process everything within the last 4/12 hours. This is still imperfect and a little fragile, we will find a better solution in master, most likely by adding a dedicated field to keep track of the last SAT check. See https://github.com/odoo/enterprise/pull/123213 See https://github.com/odoo/enterprise/pull/103272 task-none Forward-Port-Of: odoo/enterprise#125594 Forward-Port-Of: odoo/enterprise#125317
This fix prevents an unexpected error during Swiss payroll processing when a related salary rule has been archived. It helps payroll users continue their work without interruptions caused by inactive rule records.
Original PR description
Forward-Port-Of: odoo/enterprise#103677
Uploading a document while Auto Sort is enabled no longer causes an error if the document is automatically moved to another folder. This keeps the Documents app stable and avoids disrupting users during document uploads.
Original PR description
When Auto Sort is enabled, an uploaded document can be moved to a different folder as part of the sort. The subsequent model reload only fetches records for the current folder to select/scroll to the new record. But, the new document's is absent from `env.model.root.records`. `newRecords` ends up empty, making `newRecords[0]` undefined, which then crashes accessing record.resId. To fix this, we just return early because if the record isn't in the current folder, there's nothing to select or scroll to anyway, so returning early here doesn't change anything visible behavior, it just avoids the crash. Steps to reproudce: 1.Go to Documents. 2.Go to Company->Inbox 3.Go to the gear icon and make sure the "Auto Sort" is enabled with "Move to folder" 4.Add a new document that's sortable. 5.You'll get the error. opw-6281558 Forward-Port-Of: odoo/enterprise#121069
Fixed an issue that could cause an error when multiple equity transactions were processed at the same time. This improves reliability for equity workflows and helps users avoid interruptions when working with cap table transactions.
Original PR description
When the ``_compute_security_price`` method is called on multiple records, a traceback will appear. Traceback: ```py ValueError: Expected singleton: equity.transaction(1, 2) ``` https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/equity/models/equity_transaction.py#L218 The method filters newly created records using ``self._origin.id``. Since ``self`` is the whole recordset, accessing ``self._origin.id`` on multiple records raises a singleton error. sentry-7626410485 Forward-Port-Of: odoo/enterprise#125307
This update fixes Swedish ISO 20022 payment files so they meet Swedbank's required identification format. It helps companies avoid rejected payment submissions when using Swedish Bankgiro, Plusgiro, or related bank transfer flows.
Original PR description
Fix some issues with the iso20022 XML file for Sweden:
1. Swedbank doesn't allow the us of `CUST` value in the `SchmeNm`
node but force the `BANK` value.
2. Currently, we use the same Id in both `InitgPty` & `Dbtr`, which
looks to be wrong with Swedbank. The format for Swedbank is
`06{company_registry}B001`.
opw-5395736
Forward-Port-Of: odoo/enterprise#125328
Forward-Port-Of: odoo/enterprise#122119Users can now open the Scrap action from a new manufacturing barcode operation without hitting an error screen. The fix also prevents a related crash when scanning products on new manufacturing orders with consignment enabled, improving reliability in warehouse workflows.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Open Barcode app; 2. click Operations; 3. click MANUFACTURING 4. click New; 5. click cogwheel on top right; 6. click Scrap. Issue ----- Traceback: > Error: Record stock.location with id=undefined doesn't exist in the cache Cause ----- When setting up the default context for the scrap menu, it it assumes `this.record` is not empty. Solution -------- Make `cache.getRecord` not raise an error when a location isn't found. Use optional chaining for other parts of the context that rely on a `record` being present. Also fixes a related issue introduced by 4b457fe, where the same traceback would be thrown on opening a new MO and scanning a product whilst consignment is enabled. opw-6397774 Forward-Port-Of: odoo/enterprise#125442 Forward-Port-Of: odoo/enterprise#124818
This change adds a validation test to ensure currency translation calculations handle changing domestic exchange rates correctly. It helps prevent accounting reports from overstating or understating values when exchange rates fluctuate during a reporting period.
Original PR description
Following the fix made in community branch, this adds a test veryfing the expected behavior in case of a fluctuating rate for the domestic currency. Scenario 2: fluctuating domestic (USD) rate USD…
Following the fix made in community branch, this adds a test veryfing the expected behavior in case of a fluctuating rate for the domestic currency. Scenario 2: fluctuating domestic (USD) rate USD rate=1 from Jan 1 to Jun 30, USD rate=3 from Jul 1 to Dec 31 EUR rates unchanged: 2 from Jan 1, 4 from Jul 1 Correct conversion factors (= USD_rate / EUR_rate): Jan 1 – Jun 30 (182 days): 1/2 = 0.50 Jul 1 – Dec 31 (184 days): 3/4 = 0.75 Current rate at 2020-12-31: 3/4 = 0.75 Correct average rate: (0.50 * 182 + 0.75 * 184) / 366 = 229/366 ≈ 0.62568 Previsouly bugged average rate (USD fixed at current=3): (1.50 * 182 + 0.75 * 184) / 366 = 411/366 ≈ 1.12295 Historical equity rates (correct vs previously bugged): Mar 1 (USD=1, EUR=2): correct = 1/2 = 0.50; buggy = 3/2 = 1.50 → 40 * 0.50 = 20 vs 40 * 1.50 = 60 Oct 1 (USD=3, EUR=4): correct = 3/4 = 0.75; buggy = 3/4 = 0.75 → 60 * 0.75 = 45 (same by coincidence) task-5953104 Forward-Port-Of: odoo/enterprise#123055
Uruguayan export invoices that are fully offset by discounts can now be generated correctly as electronic invoices. This ensures exporters can declare the value of goods or services while issuing a zero-total invoice that is accepted by Uruware.
Original PR description
## Problem When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not…
## Problem When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not handled correctly by the XML/CFE generation logic. This use case is valid and required by exporters who need to reflect the declared value of goods/services while invoicing at zero (e.g. to comply with customs or incoterm requirements such as FCA). In Uruware's validation portal, the "Descuentos y Recargos" (discounts & surcharges) section of the subtotal block must be correctly populated for the CFE to be accepted. **Example:** An invoice with a line of 648.00 UYU and a global discount of −648.00 UYU → Total: 0.00. The export value is still declared, taxes are zero, but the CFE must reflect the discount amount explicitly. <img width="592" height="679" alt="example_expo_invoice_discount" src="https://github.com/user-attachments/assets/aa83c158-e342-4da5-a251-fc209bbed5c4" /> ## Root Cause The CFE template (`cfe_template.xml`) and the move computation logic (`account_move.py`) did not account for the case where export invoices carry line-level or global discounts that zero out the total. The discount amount was either omitted from the XML nodes or computed incorrectly, causing Uruware validation to fail or the discount block to not render. ## Fix - **`l10n_uy_edi/models/account_move.py`** — Updated the export invoice computation to correctly include discount amounts in the CFE data dict, ensuring the `ValorDR` is filled with the value of the discount per line. - **`l10n_uy_edi/views/cfe_template.xml`** — Adjusted the template condition so `MntExpoyAsim` node accepts 0 as value. ## Steps to Reproduce (before fix) 1. Create an export invoice (e-Factura Exportación) for a foreign partner. 2. Add a product line with a unit price, e.g. 216.00 × 3 = 648.00 UYU. 3. Add a global discount of 648.00 (same amount) so the total is 0.00. 4. Confirm and send to Uruware — the CFE is rejected / discount block is missing. ## Verification After the fix, the same invoice generates a valid CFE accepted by Uruware with the discount correctly reflected in the `DscRcgGlobal` node and the discount line visible on the printed document. Forward-Port-Of: odoo/enterprise#124910 Forward-Port-Of: odoo/enterprise#120130
Spanish VAT record books now include taxable accounting entries created outside standard invoices and bills, including Point of Sale session closures. This helps businesses produce more complete VAT exports and reduces the risk of missing taxable POS activity in Spanish compliance reports.
Original PR description
Currently, the Spanish VAT record books (Libros Registro de IVA) only include move types associated with invoices and bills. However, miscellaneous entries (type 'entry'), such as those generated by the Point of Sale session closures or manual liquidations, also carry tax obligations and must be reflected in these reports. Steps to reproduce: - Open a POS Session - Create an order, pay and close session - Go to Accouting > Reporting > Tax report - Select Generic Tax report - Print "VAT record Books" Issue: Only invoices and bills are visible in the excel file, and not the entry generated from point of sale. However, movements that are not related to invoices should be included in the VAT books. opw-5862529 Forward-Port-Of: odoo/enterprise#125592 Forward-Port-Of: odoo/enterprise#113681
This fixes where Mexican CFDI invoice fields are placed so they remain visible even when Colombian electronic invoicing is also installed. It prevents the CFDI Origen field from disappearing on Mexican invoices, reducing confusion and data entry issues.
Original PR description
The CFDI fields used //sheet/group//group[last()], which targets the last group by position. Once l10n_co_edi adds its group after header_right_group, the fields land in it instead, and it is invisible unless country_code is CO, so CFDI Origen disappears on MX invoices. Use //group[@id='header_right_group'], like l10n_co_edi already does, so placement no longer depends on what modules are installed. Task Adhoc side: 67269 Forward-Port-Of: odoo/enterprise#124545
5 changes
Resolved issues and error corrections
Opening the Scrap option from a new manufacturing barcode operation no longer triggers an error when no location record is available. This keeps the workflow usable for staff creating manufacturing orders and also prevents a related crash when scanning products with consignment enabled.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Open Barcode app; 2. click Operations; 3. click MANUFACTURING 4. click New; 5. click cogwheel on top right; 6. click Scrap. Issue ----- Traceback: > Error: Record stock.location with id=undefined doesn't exist in the cache Cause ----- When setting up the default context for the scrap menu, it it assumes `this.record` is not empty. Solution -------- Make `cache.getRecord` not raise an error when a location isn't found. Use optional chaining for other parts of the context that rely on a `record` being present. Also fixes a related issue introduced by 4b457fe, where the same traceback would be thrown on opening a new MO and scanning a product whilst consignment is enabled. opw-6397774 Forward-Port-Of: odoo/enterprise#125442 Forward-Port-Of: odoo/enterprise#124818
This fix prevents Swiss payroll processing from failing when a related salary rule has been archived. It helps payroll teams avoid interruptions and ensures historical or inactive rules do not cause unexpected errors during ELM transmission workflows.
Original PR description
Forward-Port-Of: odoo/enterprise#103677
The Peppol settings now apply the right journal requirement depending on whether invoice imports are handled through Documents, especially when French PDP features are installed. This prevents non-French companies from being incorrectly forced to select a purchase journal when a Documents folder is already configured, and ensures imports go only to the chosen destination.
Original PR description
Fixes the settings view for the account_peppol_purchase_journal_id. account_peppol, documents_account_peppol and l10n_fr_pdp all wants to use a specific condition for the required attribute of the view. With PDP especially, once l10n_fr_pdp is installed, the view forces the base condition, even if documents_account_peppol is installed, and even if the company is not even French. On a non-French company registered/registering on Peppol, the journal shouldn't be mandatory if documents_account_peppol_folder_id is set up. To ease things up, it is now using a computed field. task-6304479 Forward-Port-Of: odoo/enterprise#120719
Guatemalan credit notes now reference the original invoice’s actual issue date instead of a technical certification timestamp. This helps prevent SAT rejections when credit notes are issued on a different date from the original invoice.
Original PR description
### Issue before this commit: When reverting a Guatemalan invoice (creating a credit note), the XML node FechaEmisionDocumentoOrigen incorrectly reports the EDI document's technical certification…
### Issue before this commit: When reverting a Guatemalan invoice (creating a credit note), the XML node FechaEmisionDocumentoOrigen incorrectly reports the EDI document's technical certification date instead of the original invoice's emission date. This causes the SAT to reject the document. ### Steps to reproduce the issue: 1. Download Accounting and l10n_gt 2. Revert an invoice (credit note) inserting a different date than the one of the invoice 3. See that FechaEmisionDocumentoOrigen report the date of the credit note instead of the one of the invoice ### Cause of the issue: The _l10n_gt_edi_add_reference_values method extracted the date from original_document.datetime (the technical timestamp of when the XML was generated) rather than using the actual accounting date of the original invoice. ### Reason to introduce the fix: SAT validation rules strictly require the reference date to match the exact commercial emission date of the original invoice. Fetching invoice_date directly ensures compliance, avoids timezone conversion errors, and prevents the XML from being rejected. Source: https://www.lawinsider.com/es/contracts/dJXl4Vo79L2 <img width="730" height="205" alt="2026-07-17_10-19" src="https://github.com/user-attachments/assets/802e7bb3-fcf9-48db-b86f-227b494001b6" /> opw-6394409 Forward-Port-Of: odoo/enterprise#124794
The barcode app now correctly keeps only one delivery line selected when an operation contains both packaged and unpackaged products. This prevents confusion for warehouse users and reduces the risk of acting on the wrong line during scanning.
Original PR description
**Steps to reproduce:** - Enable "Move Entire Packages" setting on deliveries - Make a product A, that has a package P1, on hand qty of 1 - Make product B that don't have a package, but on hand qty…
**Steps to reproduce:** - Enable "Move Entire Packages" setting on deliveries - Make a product A, that has a package P1, on hand qty of 1 - Make product B that don't have a package, but on hand qty of 1 - Make a delivery that has both of those products, requested qty of 1 for both - Mark it as todo - Go to the barcode app, select the delivery - Select the line with product B - Select the line with product A --> The line with product B is not unselected **Why the fix:** When we have a mix of packaged products and products without a package on the same operation, they are handled separately. The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**. As we do not touch this variable, the selected package line stays selected. The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 This function does not care for the **selectedLineVirtualId** which represents the selected line without a package. To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation. This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 to unselect every line regardless of packages. opw-6266203 Forward-Port-Of: odoo/enterprise#125223 Forward-Port-Of: odoo/enterprise#122038
2 changes
Resolved issues and error corrections
This fix prevents an error from interrupting Swiss payroll ELM transmission when a related payroll rule has been archived. It helps payroll users continue processing employee monthly values reliably, even when old rules are no longer active.
Original PR description
Forward-Port-Of: odoo/enterprise#103677
Rental orders using custom routes now correctly generate the expected return transfer, not just the delivery and purchase documents. This prevents missing return logistics when businesses rent products that are procured on demand.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental order for 1 x P and set the the MTO route on the sol - Confirm the order #### > The delivery as well as the purchase for 1 unit of P was generated but the return was not. ### Cause of the issue: The procurement generated to handle both the delivery and the return rental picking are handled by the `_create_procurements`: https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/sale_stock_renting/models/sale_order_line.py#L353-L374 The `route_ids` set and used is the `mto_route` set on the sol: https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L415-L422 https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L282-L297 However, in the present case, the mto route does not contain any rule with a relevant `location_src_id` in the rental location so that the return will not be generated. opw-6361322 Forward-Port-Of: odoo/enterprise#124097
6 changes
Resolved issues and error corrections
This fix ensures generated timesheet suggestions for Discuss activity are associated with the Discuss app rather than the database record itself. This helps keep suggested work time categorized correctly for users reviewing or entering timesheets.
Original PR description
## Previous Behavior: When generateing AW sugestions, discuss related time would be associated to the DB and not the discuss app inside the database. ## Task task-[5167914](https://www.odoo.com/odoo/project/4105/tasks/5167914/project.task/6381120/project.task/6409826) Forward-Port-Of: odoo/enterprise#125339
Philippine check printing now rounds the cents portion of written amounts to two decimals, even when the currency is configured with more precision. This prevents checks from showing incorrect fractional text such as 1268/100 instead of 13/100, reducing confusion and payment errors.
Original PR description
Current behavior: --- When paying with checks, if the currency has more than 2 decimals, the decimal amount is printed with more than 2 decimals. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. In the PHP currency, change rounding factor to 0.0001 4. In Decimal accuracy > product price, set 4 digits 5. Create a new Vendor Payment, payment method Check, amount 100.1268 PHP 6. Results: One Hundred and 1268/100, should be 13/100 Expected behavior: --- The xx/100 part of amount in words text in the check should always be rounded to 2 decimals. opw-6302337 Forward-Port-Of: odoo/enterprise#124572 Forward-Port-Of: odoo/enterprise#121913
Trial balance reports now avoid showing negligible rounding leftovers as balances when exported to Excel. This prevents accounts that should balance to zero from displaying confusing tiny scientific-notation values, improving report accuracy and clarity for finance users.
Original PR description
Steps to reproduce -------------------- - Install account_reports module; - Create a new account; - Create a miscellanous operation for the previous month using thenew account with a credit amount of $8.28; - Create a second MISC for the current month with two lines using the account : debit = 262.67 and credit = 254.39; - Open the trial balance report and filter the new account (end balance should be 0); - Export the report as XLSX; The end balance value is 2.84e-14 due to float rounding issues. opw-6369016 Forward-Port-Of: odoo/enterprise#125416 Forward-Port-Of: odoo/enterprise#123896
Scanning the original manufacturing order barcode now correctly finds related split manufacturing orders instead of showing a “not found” error. This helps warehouse and production teams continue barcode-based manufacturing flows after an order has been split.
Original PR description
### Steps to reproduce: - Create a product FP with a BOM: 1 X COMP (enough units in stock) - Create and confirm an MO for 3 units - Click on the cog wheel icon > Split the MO in 3 - On the barcode app > Operations > Manufacturing - Scan the name of your base MO #### > Error: No product or order found for barcode ... ### Expected behavior: Scanning an existing MO only adds its barcode as a `search_default_name`: https://github.com/odoo/enterprise/blob/598a8e335605fd68e3ceb5c1170864243426f994/stock_barcode_mrp/models/mrp_production.py#L162-L178 However, while this search is performed with an ilike, we only check the existence of an exact match before raising an error, which does not happen since our splitted MOs have a name: barcode-001, barcode-002, barcode-003,... opw-6376937 Forward-Port-Of: odoo/enterprise#123931
The portal now accurately reduces a user’s pending signature count after they sign their assigned document. This prevents users from seeing completed signing tasks as still outstanding and improves trust in the portal status display.
Original PR description
Version: master Steps to reproduce: - Create a sign request with two signers. - Assign the first signature to a portal user. - Log in as the portal user and sign the document. Issue: After signing, the to-sign count in the portal does not decrease. This is because the query only checks the overall sign request state instead of the individual signer's item state, so the count remains unchanged Fix: Added an item level state check to the count query so it only counts items that are still pending for that specific user. Task ID: 6412976
This fixes Peppol settings so the purchase journal is only required when it should be, especially when French PDP features are installed for non-French companies. It also ensures that choosing Documents for import sends invoices only to Documents, avoiding duplicate handling in Invoicing.
Original PR description
Fixes the settings view for the account_peppol_purchase_journal_id. account_peppol, documents_account_peppol and l10n_fr_pdp all wants to use a specific condition for the required attribute of the view. With PDP especially, once l10n_fr_pdp is installed, the view forces the base condition, even if documents_account_peppol is installed, and even if the company is not even French. On a non-French company registered/registering on Peppol, the journal shouldn't be mandatory if documents_account_peppol_folder_id is set up. To ease things up, it is now using a computed field. task-6304479 Forward-Port-Of: odoo/enterprise#120724
9 changes
Resolved issues and error corrections
Spanish VAT record books now include taxable accounting entries created outside standard invoices and bills, such as Point of Sale session closures and manual tax liquidations. This helps ensure VAT reports are complete and aligned with Spanish tax obligations.
Original PR description
Currently, the Spanish VAT record books (Libros Registro de IVA) only include move types associated with invoices and bills. However, miscellaneous entries (type 'entry'), such as those generated by the Point of Sale session closures or manual liquidations, also carry tax obligations and must be reflected in these reports. Steps to reproduce: - Open a POS Session - Create an order, pay and close session - Go to Accouting > Reporting > Tax report - Select Generic Tax report - Print "VAT record Books" Issue: Only invoices and bills are visible in the excel file, and not the entry generated from point of sale. However, movements that are not related to invoices should be included in the VAT books. opw-5862529 Forward-Port-Of: odoo/enterprise#125548 Forward-Port-Of: odoo/enterprise#113681
Opening the Scrap option from a new manufacturing barcode operation no longer crashes when no location or production record is selected yet. This keeps the manufacturing barcode workflow usable and also prevents a related crash when scanning products with consignment enabled.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Open Barcode app; 2. click Operations; 3. click MANUFACTURING 4. click New; 5. click cogwheel on top right; 6. click Scrap. Issue ----- Traceback: > Error: Record stock.location with id=undefined doesn't exist in the cache Cause ----- When setting up the default context for the scrap menu, it it assumes `this.record` is not empty. Solution -------- Make `cache.getRecord` not raise an error when a location isn't found. Use optional chaining for other parts of the context that rely on a `record` being present. Also fixes a related issue introduced by 4b457fe, where the same traceback would be thrown on opening a new MO and scanning a product whilst consignment is enabled. opw-6397774 Forward-Port-Of: odoo/enterprise#125442 Forward-Port-Of: odoo/enterprise#124818
The AI tool descriptions were cleaned up to remove misleading labels that could cause agents to request a tool that does not exist. This reduces avoidable AI workflow failures and helps automated actions run more reliably.
Original PR description
Purpose: -------- Agents occasionally fail by trying to call a `search` tool that does not exist. This seems to come from the `Tool Name: search` header in the tool description, which can be confused with the actual tool name used by the LLM, i.e. the tool xmlid. This commit removes these headers from the search and read group tool descriptions. They were missed in [this commit](https://github.com/odoo/enterprise/commit/912bce43a98d45e90dbd24328fa2f46caba4c887 ), which removed the same headers from the other tools. Task-6401285
The French accounting report tests were updated to match the latest fallback behavior for FEC export labels. This helps ensure the export validation remains reliable after the related core accounting change, with no expected change for day-to-day users.
Original PR description
Adjust the FEC export test expectations to match the updated `EcritureLib` fallback logic introduced in the related community change. Related: https://github.com/odoo/odoo/pull/257242 task-5346068
The rental order form now displays the duration and pricing update button correctly when translated button labels are longer. This prevents overlapping text, making rental durations easier to read across languages and screen sizes.
Original PR description
**Steps to reproduce:** 1. Set the UI language to Spanish (or any language with a long "Update Rental Prices" translation) 2. Create a rental order with a rental period that has both days and hours…
**Steps to reproduce:** 1. Set the UI language to Spanish (or any language with a long "Update Rental Prices" translation) 2. Create a rental order with a rental period that has both days and hours (e.g. July 15 10:00 → July 25 14:00 = 10 days 4 hours) 3. Observe the "Duration" field in the form after zooming (depends on screen resolution) **Issue:** The duration row displays overlapping text **Why this happens:** The "Update Rental Prices" button and the duration text share the same o_row flex container. In translated UIs the button text can be significantly wider than in English, pushing the total row width past the form value-cell boundary. When the row overflows, only spans and the button shrink, the integer field widgets do not. The threshold at which this triggers is zoom dependent based on screen resolution. **Fix:** Add `.flex-wrap` utility class to the duration `o_row` so the button wraps to the next line when space is insufficient, keeping the duration text intact on a single line. opw-6389526
This fix prevents Swiss payroll processing from failing when a related payroll rule has been archived. It helps payroll teams continue monthly value handling without unexpected interruptions caused by inactive rules.
Original PR description
Forward-Port-Of: odoo/enterprise#103677
The Twitter integration now disables the reply option when Twitter would not allow a response, such as when the account is not mentioned or the post does not quote one of its tweets. This helps prevent failed replies and avoids unwanted automated responses to Twitter users.
Original PR description
Purpose ======= To prevent LLM from spamming Twitter users, Twitter does not allow to reply to a tweet if we are not mentioned in it, or if the tweet does not quote one of our tweet. For that reason, we disable the reply button when needed. Task-5964524 Forward-Port-Of: odoo/enterprise#112161
Fixed Uruguayan electronic export invoices so invoices fully offset by discounts can still be generated and validated correctly. This helps exporters report the declared value of goods or services while issuing a zero-total invoice when required for customs or commercial terms.
Original PR description
## Problem When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not…
## Problem When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not handled correctly by the XML/CFE generation logic. This use case is valid and required by exporters who need to reflect the declared value of goods/services while invoicing at zero (e.g. to comply with customs or incoterm requirements such as FCA). In Uruware's validation portal, the "Descuentos y Recargos" (discounts & surcharges) section of the subtotal block must be correctly populated for the CFE to be accepted. **Example:** An invoice with a line of 648.00 UYU and a global discount of −648.00 UYU → Total: 0.00. The export value is still declared, taxes are zero, but the CFE must reflect the discount amount explicitly. <img width="592" height="679" alt="example_expo_invoice_discount" src="https://github.com/user-attachments/assets/aa83c158-e342-4da5-a251-fc209bbed5c4" /> ## Root Cause The CFE template (`cfe_template.xml`) and the move computation logic (`account_move.py`) did not account for the case where export invoices carry line-level or global discounts that zero out the total. The discount amount was either omitted from the XML nodes or computed incorrectly, causing Uruware validation to fail or the discount block to not render. ## Fix - **`l10n_uy_edi/models/account_move.py`** — Updated the export invoice computation to correctly include discount amounts in the CFE data dict, ensuring the `ValorDR` is filled with the value of the discount per line. - **`l10n_uy_edi/views/cfe_template.xml`** — Adjusted the template condition so `MntExpoyAsim` node accepts 0 as value. ## Steps to Reproduce (before fix) 1. Create an export invoice (e-Factura Exportación) for a foreign partner. 2. Add a product line with a unit price, e.g. 216.00 × 3 = 648.00 UYU. 3. Add a global discount of 648.00 (same amount) so the total is 0.00. 4. Confirm and send to Uruware — the CFE is rejected / discount block is missing. ## Verification After the fix, the same invoice generates a valid CFE accepted by Uruware with the discount correctly reflected in the `DscRcgGlobal` node and the discount line visible on the printed document. Forward-Port-Of: odoo/enterprise#124910 Forward-Port-Of: odoo/enterprise#120130
The Belgian Partner VAT Listing now always reports from January 1 to December 31 for the selected year. This prevents incorrect reporting periods for companies whose fiscal year does not match the calendar year, improving compliance accuracy.
Original PR description
The Belgian Partner VAT Listing must always report on the civil calendar year (01/01/N to 12/31/N). Previously, the report was relying on the company's fiscal year configuration, which caused incorrect reporting periods for companies with non-calendar fiscal years. This commit overrides `_custom_options_initializer` to strictly enforce a civil year date range based on the selected year, entirely ignoring custom fiscal year boundaries. Task-6086513
6 changes
Resolved issues and error corrections
Customer follow-up reports now exclude invoices that have already been fully paid, even when they were paid as part of a grouped payment. This prevents customers from seeing settled invoices as still outstanding and makes follow-up communications more accurate.
Original PR description
Steps to reproduce: - Configure a bank journal with Outstanding Receipts/Payments accounts - Create two customer invoices for the same partner (e.g. 1000 and 2000) - Select both, Register Payment,…
Steps to reproduce: - Configure a bank journal with Outstanding Receipts/Payments accounts - Create two customer invoices for the same partner (e.g. 1000 and 2000) - Select both, Register Payment, enable Group Payments, pay 1500 so that the first invoice is fully paid and the second remains partially paid (1500 due) - Validate and reconcile the payment, then open the Customer Follow-up Report Issue: The fully paid invoice still shows up in the Follow-up Report, alongside the partially paid one. Cause: The report's 'unreconciled' domain (account.report. _get_options_unreconciled_domain) filters on full_reconcile_id, which is set per matching-number group rather than per line: when several invoices are settled together through a grouped payment, they all share the same matching number, and the group only gets a full_reconcile_id once *every* line in it is fully paid. Since the second invoice is still open, the group stays without a full_reconcile_id, so the first invoice is wrongly treated as unreconciled too, even though its own residual amount is zero. Fix: Override _get_aml_values on the Follow-up report handler to drop lines that are individually reconciled (amount_residual = 0), instead of relying on the group-level full_reconcile_id. The generic unreconciled domain is left untouched since Partner Ledger and Aged Receivable also rely on it and may depend on keeping partially settled matching groups grouped together. opw-6323401
Ecuador branch users can now create customer invoices without being blocked by an access error. The fix avoids requiring direct access to the parent company when checking the journal’s country, keeping normal accounting workflows working in branch setups.
Original PR description
Steps to reproduce: - Install `l10n_ec` module - Create one branch of the EC company - Give user(not admin) access to company branch and login with user - Go to Accounting > Customers > Invoices - Click New > AccessError Cause: This error occurs because the user is working within a branch of the main company. The code tries to access the journal’s company, which is set to the parent company. As the user does not have access to the parent company, fetching the country code fails. Solution: In some cases, strict company access rules cause `AccessError` and block normal flows, especially with parent–child company setups where a child needs data from the parent. To ensure smooth processing, we use a related field on the journal to retrieve the country code without directly accessing the company. opw-6087460
This fix prevents Swiss payroll ELM transmission from failing when a related payroll rule has been archived. It helps HR teams continue payroll reporting without unexpected errors caused by inactive configuration records.
Original PR description
Forward-Port-Of: odoo/enterprise#103677
Ri.Ba. payment validation now accepts San Marino IBANs as well as Italian IBANs, preventing valid batch payments from being blocked. The payment file generation was also adjusted to keep San Marino records within the required format length.
Original PR description
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a…
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a Batch Payment using the Ri.Ba. payment method. - Validate the Batch Payment. **_Observed behavior :_** The validation fails with the error: `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments` **_Cause :_** The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs. **_Fix :_** - Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files. - While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format. **_opw_** - 6303820
This fixes where Mexican CFDI invoice fields are placed so they no longer disappear when Colombian electronic invoicing is also installed. It ensures users can reliably see and use the CFDI Origin field on Mexican invoices regardless of other localization modules.
Original PR description
The CFDI fields used //sheet/group//group[last()], which targets the last group by position. Once l10n_co_edi adds its group after header_right_group, the fields land in it instead, and it is invisible unless country_code is CO, so CFDI Origen disappears on MX invoices. Use //group[@id='header_right_group'], like l10n_co_edi already does, so placement no longer depends on what modules are installed. Task Adhoc side: 67269 Forward-Port-Of: odoo/enterprise#124545
Before this commit, the down payments line of the project profitability panel had no drill down action for salespersons and billing users without accounting access, because the group references were written with a trailing comma inside the XML id, making the two checks silently fail for everyone. Only the accounting read group check, written correctly, was effective. Steps to reproduce: - create a service product with "Create on Order: Project & Task", sell it on a sale order and confirm it
Original PR description
Before this commit, the down payments line of the project profitability panel had no drill down action for salespersons and billing users without accounting access, because the group references were…
Before this commit, the down payments line of the project profitability panel had no drill down action for salespersons and billing users without accounting access, because the group references were written with a trailing comma inside the XML id, making the two checks silently fail for everyone. Only the accounting read group check, written correctly, was effective. Steps to reproduce: - create a service product with "Create on Order: Project & Task", sell it on a sale order and confirm it - create a down payment invoice from the sale order and post it - create a user with Sales "User: All Documents" access, Project "User" access and no accounting access - as that user, open the dashboard of the generated project and look at the Down Payments line of the profitability panel The Down Payments amount is displayed as plain text, while a user with accounting access can click it to open the related invoices, as intended for the salesperson too. Solution: Move the commas out of the group references. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This fix prevents Swiss payroll ELM transmission from failing when a related salary rule has been archived. It helps payroll users continue processing monthly employee values without unexpected interruptions caused by archived configuration records.
The Swedish SIE4 general ledger export now uses the actual configured fiscal year dates instead of assuming every fiscal year lasts exactly one year. This prevents mismatches between the declared reporting period and the accounting data included in exports, especially for shortened or extended fiscal years.
Original PR description
## Issue: Exporting the general ledger as SIE4 set the duration of fiscal years to one year from the starting date of the fiscal year. ## Steps to reproduce: - Create a fiscal year A of one month for…
## Issue: Exporting the general ledger as SIE4 set the duration of fiscal years to one year from the starting date of the fiscal year. ## Steps to reproduce: - Create a fiscal year A of one month for year X-1 (December 1st to December31th year X-1) - Create a fiscal year B of 1 year and 1 month (January 1st Year X to January 31th year X+1) - Create Invoices in November year X-1, December year X-1, year X and in January year X+1 and confirm them - Go to General Leder - Set date to the fiscal year B - Export as SIE4 ### Current behavior: - **for previous fiscal year** - declared fiscal year (#RAR field) goes : - from fiscal year X date_from -1 year - to fiscal year X date_to -1 year - However data are computed: - from fiscal year X date_from -1 year - to fiscal year X date_from -1 day - **for current fiscal year** - declared fiscal year (#RAR field) goes : - from fiscal year X date_from - to fiscal year X date_to - However data are computed: - from fiscal year X date_from - to fiscal year X date_from +1 year ### Expected behavior: Declared fiscal year match the one that is use for computation. - for previous fiscal year - from fiscal year X-1 date_from - to fiscal year X date_from -1 day - for current year - from fiscal year X date_from - to fiscal year X date_to Cause: Current year length was wrong because it [relied on](https://github.com/odoo/enterprise/blob/22b4100006ec24bf6e4b64042cbfdba360fcf470/l10n_se_sie4_export/models/account_general_ledger.py#L139-L140) the next_date_from which was wrong. opw-6264766