Daily updates from Odoo
Wednesday, March 18, 2026
40 changes · saas-18.3
Resolved issues and error corrections
This update ensures that shift notifications are automatically sent to employees in their preferred language, regardless of the user's language settings. Previously, emails were defaulted to the current user's language, causing confusion. This fix improves communication and user experience for international teams.
Original PR description
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language.…
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language. 4. Create a shift for that employee and click "Send". 5. Check the message in Settings > Technical > Discuss > Messages. Issue: --------- The email is sent in the language of the current user rather than the language of the employee receiving the shift. Cause: --------- The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language on the planning slot record because it is not directly linked to a `partner_id`. As a result, it falls back to the current user's language. Solution: ------------ Explicitly pass the employee partner's language in the mail context so that the email is sent in the correct language. opw-5928676 Forward-Port-Of: odoo/enterprise#110778 Forward-Port-Of: odoo/enterprise#109619
This update fixes a technical issue in the Odoo Enterprise software related to demo certificates used for Peru's electronic invoicing (PE) requirements. The certificate's lifespan was extended by ten years to align with current regulations, ensuring accurate reporting within the system. This change ensures continued compliance and proper functionality for users utilizing the l10n_pe_edi module.
Original PR description
In runbot's faketime tests, the test 1 year in the future goes past the end date of the demo PE certificate which had a lifetime of 2017-02-25 to 2027-02-25. This commit replaces that with one that lasts another ten years (2026-03-13 to 2036-03-13). runbot-241058 Forward-Port-Of: odoo/enterprise#110719
This update resolves an issue that prevented demo data from loading correctly when errors occurred during the process. By preventing errors related to missing record IDs, the system is now more robust during demo data installation and loading, ensuring a smoother user experience. This improves the reliability of initial module setup.
Original PR description
``` * = {appointment_account_payment, appointment_hr_recruitment, mrp_workorder, quality_mrp_workorder, quality_mrp_workorder_worksheet} ``` Currently, an error may occur if a referenced record ID…
```
* = {appointment_account_payment, appointment_hr_recruitment,
mrp_workorder, quality_mrp_workorder, quality_mrp_workorder_worksheet}
```
Currently, an error may occur if a referenced record ID is not found during XML data loading. This can happen in various scenarios, including:
- While loading demo data during module installation.
- When an exception interrupts demo data loading, it prevents remaining data from being processed.
- When demo data is being loaded while the module is simultaneously being uninstalled in another session.
**Steps to Reproduce:**
- Install all the modules without demo data.
- Go to settings and manually load the demo data.
- If a user error occurs during this process, the demo data load will fail and raise an error.
**Error:**
`Could not eval([(4, ref('mrp.product_product_computer_desk'))]) for product_ids in {"lang":null}`
This commit applies `raise_if_not_found=False` to XML references in `eval`, preventing errors when the referenced external ids are missing.
Related-community-PR: https://github.com/odoo/odoo/pull/212295
Sentry - 3935871751This update resolves a potential error that occurred when loading demo data in the pos_loyalty module. The change prevents errors if referenced records aren't found during the loading process, ensuring demo data can be loaded consistently even with interruptions or concurrent uninstallations.
Original PR description
Currently, an error may occur if a referenced record ID is not found during XML data loading. This can happen in various scenarios, including:
- While loading demo data during module installation.
- When an exception interrupts demo data loading, it prevents remaining data from being processed.
- When demo data is being loaded while the module is simultaneously being uninstalled in another session.
**Steps to Reproduce:**
- Install all the modules without demo data.
- Go to settings and manually load the demo data.
- If a user error occurs during this process, the demo data load will fail and raise an error.
**Error:**
`Could not eval([(4, ref('mrp.product_product_computer_desk'))]) for product_ids in {"lang":null}`
This commit applies `raise_if_not_found=False` to XML references in `eval`, preventing errors when the referenced external ids are missing.
Related-enterprise-PR: https://github.com/odoo/enterprise/pull/86681
Sentry - 3935871751This update resolves an issue where validating a delivery record would cause an error when the associated sale order lacked order lines. The fix automatically assigns a default sequence value of zero, ensuring deliveries can be validated correctly even without existing order lines. This improves the reliability of the delivery process.
Original PR description
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and…
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and `confirm` it. - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`. - In the `Additional tab`, select the `sale order (the one without order lines)`. - Now `validate` this delivery. **Error:** `ValueError: max() arg is an empty sequence` This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error. This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used. [1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164 sentry-7089149997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239030
This update resolves a technical issue that prevented users from running the automated download of vendor invoices from the Polish KSeF system when rate limits were exceeded. The fix ensures that error messages are handled correctly, preventing a common traceback error and allowing the scheduled action to continue functioning properly.
Original PR description
Before this commit: Steps 1. Create a Polish company 2. Run scheduled action "Polish eInvoice: Download vendor bills from KSeF" 3. If the customer gets 429 Too Many Requests => A traceback error is raised as message isn't an attribute in KSeFRateLimitError object `AttributeError: 'KSeFRateLimitError' object has no attribute 'message'` This happens because `KSeFRateLimitError` does not define a `message` attribute. The message is only passed to the base Exception and stored in `args`. After this commit: Use `str(e)` to properly retrieve the exception message and avoid the AttributeError. opw-6009380 Forward-Port-Of: odoo/odoo#253549
This update resolves an issue where users creating freelance employees would receive an error message about missing SDWorx codes. The fix ensures that the system correctly skips this validation check for freelancers, streamlining the export process and preventing unnecessary errors.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#102211
This update resolves an issue preventing new employee creation when generating BVG-LLP reports. The fix addresses a technical problem within Odoo's reporting system related to how it handles multiple report records with the same month, preventing a critical error. This ensures employees can be correctly created within the Swiss payroll process.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#102335This update resolves an issue where the bulk payment feature would crash if a bank account wasn't linked. A new user message now alerts users to ensure their payment journal is connected to a bank before checking batch status, improving the user experience and preventing errors.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083 Forward-Port-Of: odoo/enterprise#110474 Forward-Port-Of: odoo/enterprise#109956
This update resolves a test failure caused by overly sensitive checks for loading indicators (fa-spin). The trigger has been removed, ensuring tests run smoothly even with minor delays in the system. This improves the reliability of our testing process.
Original PR description
In this commit: = - Removed the trigger that checks for `fa-spin` as it was causing test failures when minor delays occurred between steps. - Checks for `fa-spin(Sync)` is alredy handled by the `isSynced` or `waitRequest`. Runbot-error: [198580](https://runbot.odoo.com/odoo/error/198580), [234025](https://runbot.odoo.com/odoo/error/234025) Forward-Port-Of: odoo/enterprise#87281
This update ensures that the system correctly handles file uploads, specifically by verifying the MIME type passed to the 'File' constructor. This change aligns with Chrome's latest standards and prevents compatibility issues with older browser versions, ensuring smoother file operations.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/odoo#254154 Forward-Port-Of: odoo/odoo#253631
This update ensures that new files created within the Odoo Enterprise system correctly identify their file types (mimetypes). This fix addresses a compatibility issue with older versions of Chrome, aligning with current web standards and preventing potential display or functionality problems.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/enterprise#110812 Forward-Port-Of: odoo/enterprise#110496
This update ensures that payments received from external providers are always fully reconciled – either completely paid or not paid at all. Previously, partial reconciliation was allowed, which created an inaccurate record of transactions. This change improves the accuracy of financial reporting.
Original PR description
When we receive a payment from a provider, we allow partial reconciliations to be done on this move, but we shouldn't. Payments coming from providers are always either fully paid, or not paid at all. task-5893189
A test was failing due to inconsistencies in the system's clock. This update ensures the test accurately measures the time it takes for a bill retry process, guaranteeing reliable test results and preventing potential delays in automated bill downloads. This improves the stability of the l10n_pl_edi module.
Original PR description
The test `TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after` was failing with a stack like following, because the `now()` time was taken after the cron was executed, making the time diff sometimes shorter than the required 120s.
```
FAIL: TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after
Traceback (most recent call last):
File "/data/build/odoo/addons/l10n_pl_edi/tests/test_l10n_pl_edi.py", line 619, in test_l10n_pl_edi_download_bill_retry_after
self.assertGreaterEqual(capt.records[-1].call_at, fields.Datetime.now() + timedelta(seconds=120))
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: datetime.datetime(2026, 2, 21, 4, 20, 7) not greater than or equal to datetime.datetime(2026, 2, 21, 4, 20, 8)
```
runbot-241016
Forward-Port-Of: odoo/odoo#254234This update resolves an issue where changing the copyright footer background color would cause a CSS error when the footer had no background color. The fix adds a fallback value to ensure the copyright color displays correctly regardless of the footer's background setting, improving website appearance consistency.
Original PR description
Before this commit, a css error would happen when the user tried to change the copyright background color if the footer had no background color.
This was due to $-footer-color not having a fallback value when neither o-color('footer-custom') nor o-color('footer') was defined.
This commit adds a fallback value to fix the issue.
task-5452457
Forward-Port-Of: odoo/odoo#248283This update fixes a display problem with the mega menu on mobile devices. Previously, when the mega menu was set to 'Narrow,' it would sometimes take up too much space. This change ensures the mega menu's width is correctly controlled, preventing oversized displays and maintaining a consistent user experience.
Original PR description
The property "max-width" of the mega menu in mobile view was set with the class o_mega_menu_is_offcanvas of its ancestor. However, when the user set the mega menu template size to "Narrow", new CSS rules were added to change the mega menu size based on the screen size. The first rule was overridden, resulting in the mega menu being larger than the mobile navbar width. This commit sets the property "max-width" as "important" to prevent this issue from occurring. task-5972284 Forward-Port-Of: odoo/odoo#250690
This update simplifies invoice processing by automatically enabling self-billing for all users within the Odoo system. Previously, this feature required a separate module. Additionally, the xRechung functionality has been removed, ensuring invoices are only sent to government entities as intended.
Original PR description
Everybody is now able to receive self billing invoices even without the additional module. So the service should be added to the base module. Also remove xRechung because users are not supposed to receive it, only government. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254341
This update resolves an issue where the delivery process would fail if Sendcloud, our shipping provider, didn't respond to a request for shipping prices. The fix prevents a system error (traceback) from occurring, ensuring smoother and more reliable delivery processing. This improvement enhances the overall reliability of our shipping functionality.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#109252
A test case was failing due to a missing accounting group during user creation, leading to an access error when attempting to create a journal entry. This change ensures the necessary group is assigned, resolving the test failure and preventing similar issues in the future.
Original PR description
The crash occurs due to the test case introduced in PR #246920. While creating the user, no accounting group was assigned, so when this user attempts to create a Journal Entry, an AccessError is raised. **Root cause:** - In the previous version, when a public user was created, the required groups for creating an account move were assigned by default. However, in the current version, only a single group is assigned by default, which is Role/Member. As a result, when attempting to create an account move, an access error. In this commit, the required accounting group is added during user creation to ensure the test runs correctly. Runbot-241930
A test in the sale_timesheet module was failing due to a dependency on the account_accountant (Invoicing) module. The fix ensures the Invoicing module is automatically installed during test execution, allowing the test to run successfully. This prevents disruptions to the testing process.
Original PR description
__ ## Error description When the test runs following a specific configuration, the field `invoicing_switch_threshold` isn't found. However, we have to keep this field in the test because we can't replicate the issue the test checks without it. ## Origin of the issue This field belongs to the `account_accountant` (Invoicing) module. However, `sale_timesheet` doesn't have a dependency on this module: there's only an auto install for `account_accountant` when installing the module from the front-end. Therefore, if we launch the test without the `account_accountant` auto install, it will fail. __ original commit: https://github.com/odoo/odoo/pull/250946/changes/52a9841c754466c2df65c75d13c9ed2ae86a51ce Forward-Port-Of: odoo/odoo#252772
This update resolves an issue where clicking 'View' links after deleting a website page (like 'ContactUs') didn't function correctly. The fix ensures that links redirect properly by using the correct model name in the URL, preventing broken functionality and improving the user experience.
Original PR description
**Steps to reproduce:** 1. Go to the list view of website pages. 2. Select the page "ContactUs". 3. Click Delete. 4. A warning dialog appears. 5. Unfold one of the lists of records where the page is used. **Issue** Clicking on a record link (for example, "View") does not redirect anywhere. This is due to the use of the model display name in url. caused by https://github.com/odoo/odoo/commit/de302c2d36305c0d7562572a30587641eabfe914 **Fix** Use the model_name instead of the display name in the URL. task-5880458 Forward-Port-Of: odoo/odoo#245932
This update fixes an issue where sales order margins were incorrectly calculated due to a misunderstanding of the product's cost method. The fix ensures margins are accurately determined based on the company associated with the sales order line, regardless of the user's default company setting. This improves the reliability of margin reporting.
Original PR description
Steps to reproduce: - Have 2 companies: - Company A with a property_cost_method 'average' - Company B with a property_cost_method 'standard' - Create a sales order in B - Set the default company of the user to A. - Under certain scenarios, when we confirm the sales order, there will be a `flush_all`. - When that's the case, margins are recomputed with `line.product_id.categ_id.property_cost_method` as `average` instead of `standard`. In other words, it will take the property_cost_method from the `user.company_id` (A), instead of the property_cost_method from the `line.company_id` (B). This fix ensures the `property_cost_method` considered is the one related to the company of the sale order line. A similar issue was fixed on https://github.com/odoo/odoo/pull/192890 OPW-5939464 Forward-Port-Of: odoo/odoo#253764 Forward-Port-Of: odoo/odoo#252161
This update resolves issues with how invoices handle discounts and down payments when submitting data to the Viettel system. Specifically, it corrects errors caused by negative values and ensures that note lines are now correctly included in the invoice submission process. This improves the accuracy and reliability of invoice data transmission.
Original PR description
Previously, the invoice logic did not properly handle the following scenarios: - Global discount: when a global discount was applied, negative values were sent to Sinvoice, resulting in a BAD_REQUEST_ITEM_VALUES_NEGATIVE error. - Down payment: when an invoice included a down payment to deduct the amount, negative values were sent to Sinvoice, triggering the same BAD_REQUEST_ITEM_VALUES_NEGATIVE error. - Note lines: note lines on the invoice were not being uploaded/included in the invoice submission. This commit fixes the handling of global discounts and down payments by ensuring negative values are properly transformed before being sent to Sinvoice, and adds support for uploading note lines in the invoice. task-5875158 Forward-Port-Of: odoo/odoo#253867 Forward-Port-Of: odoo/odoo#251913
This update corrects a problem causing incorrect stock synchronization for Amazon listings, specifically addressing 'ghost listings' that led to unwanted orders. The fix allows users to manually specify the fulfillment channel (FBA or FBM) for listings, resolving a previous flawed assumption and improving order accuracy.
Original PR description
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and…
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662
This update fixes a problem causing users to see multiple notification popups when receiving push notifications through Social Marketing. The fix ensures notifications are displayed correctly across browsers and resolves a subscription error, improving the overall user experience.
Original PR description
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the…
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field. 2. Our service worker displays a notification popup when receiving a background message from Firebase. To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us. Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications. To fix that issue, we will: 1. Ensure that the service worker reaches the `ready` state before communicating with it. 2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page. Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers. Task-5124645 Forward-Port-Of: odoo/enterprise#110823 Forward-Port-Of: odoo/enterprise#96029
This update resolves an issue where the Public Administration (PA) invoice status wasn't correctly updated after SDI validation, leading to potential rejection errors. The fix ensures the system accurately reflects the invoice's state, improving the reliability of the Italian tax reporting process. This change impacts the l10n_it_edi module.
Original PR description
### Issue: After the SDI validation, the state was never updated to match the PA state, resulting in a mismatch with the actual status ### Cause: When `l10n_it_edi_state` is set to `forwarded`, the cron `cron_l10n_it_edi_download_and_update` doesn't consider that a new state could occur However, invoices sent to Public Administration can still be rejected after being forwarded It is not possible to reproduce the issue with the demo system, as it only sets the state to `forwarded` Ticket [link](https://www.odoo.com/odoo/project.task/5391891) opw-5391891 Forward-Port-Of: odoo/odoo#253525
This update resolves an issue where downpayment invoices generated with fixed taxes incorrectly lacked tax line items. This prevented proper invoice generation for Peppol compliance, leading to errors. The fix removes the problematic downpayment processing related to fixed taxes, ensuring accurate invoice creation.
Original PR description
When making a downpayment for an order containing product using fixed taxes, the downpayment invoice would contain line without tax associated This is an issue when sending these invoices to Peppol. Steps to reproduce: ------------------- * Create a fixed tax of 5€ * Set this tax on any product along another tax * Create a sale order for this product * Make a downpayment of 10% * The invoice created has a line without any tax set > Observation: When sending to Peppol we get an error Why the fix: ------------ We remove the downpayment part that concerns fixed tax to avoid having lines without tax set. opw-5853070
This update prevents users from deleting tax groups that are currently in use within the system. Previously, deleting a tax group could cause errors. Now, a validation error is displayed, ensuring data integrity and preventing potential issues with financial reporting. This change improves the stability and reliability of the accounting module.
Original PR description
Before this PR: - Group of taxes can be deleted by a user, even if they are used. After this PR: - If a user tries to delete a group of taxes in use, a validation error is raised. - Fixed a test case in POS and deactivated the tax instead of deleting the tax. Related PR: https://github.com/odoo/enterprise/pull/105174 task-5472834
This update resolves an issue in the GSTR report testing process. Previously, tests were incorrectly deleting tax information. Now, the system removes taxes from the account move line, ensuring more accurate report generation and compliance. This change improves the reliability of the GSTR reports.
Original PR description
Before this PR: - A test case was deleting taxes. After this PR: - Removed the taxes from the account move line instead of deleting the taxes. Related PR: https://github.com/odoo/odoo/pull/245243 task-5472834
This update resolves an issue where tax calculations were incorrect during the reconciliation process for certain journal entries, specifically those involving reverse charges. The fix ensures that tax amounts are accurately reflected in the reconciled entries, improving financial reporting accuracy. This primarily impacts users utilizing the VAT (Value Added Tax) reconciliation feature.
Original PR description
## ISSUE 1: **Steps to reproduce [l10n_be easier]:** - Create a journal entry: ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in…
## ISSUE 1: **Steps to reproduce [l10n_be easier]:** - Create a journal entry: ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in the wizard > account 600 tax 12% (purchase) - Validate - Check the last entry created **Issue:** There is no invert tag set on the tax line **Cause:** The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815 The line was never set to properly (same of is_refund) ## ISSUE2: **Steps to reproduce:** - create a journal entry ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in the wizard > account 600 tax 21% EU M (Purchases) - Validate - Check the last entry created **Issue:** No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0. opw-4976780 Forward-Port-Of: odoo/enterprise#93839 Forward-Port-Of: odoo/enterprise#92556
This update resolves a problem where the system incorrectly flagged invoices for EC Sales List compliance checks when customers were registered as intra-EU. The fix ensures that the system accurately identifies and reports on invoices related to intra-EU sales, improving data accuracy and compliance.
Original PR description
The EC Sales List return check "Only intra-EU customers" is reviewed when an invoice that match the condition for the warning same_country is present. To Reproduce: - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer (in the previous month of the current month, for example February if the current date is in March - Open the Tax Returns - Open the EC Sales List Return - The Only intra-EU customers check is reviewed when it should show an anomaly.
A bug preventing the reset of the Lead Forward email template was resolved. This issue occurred due to a new validation check introduced in version 18.3. The fix ensures users can now correctly reset the template without encountering an error, maintaining proper email template functionality.
Original PR description
Steps to reproduce: - Create a lead > click on gear icon > Forward to partner - Send the forward and ensure there is at least one record of crm.forward.to.partner - Navigate to email templates technical settings menu and search for Lead Forward: Send to partner - Click on Reset Template in the template form Current behavior: - Validation Error thrown Expected behavior: - No validation error thrown and template is reset Note: MailTemplate._check_can_be_rendered was added in version 18.3 which checks for invalid object references when trying to alter + save templates. This template was out of date and fails the check Referenced PR: https://github.com/odoo/odoo/pull/176623 opw-6001560
This update resolves an issue where component consumption in manufacturing orders wasn't working correctly, leading to incorrect quantity updates and a missing warning message. The fix ensures that component stock is accurately tracked and consumed during the production process, improving the reliability of manufacturing operations.
Original PR description
# Product Configuration *Manufactured Product* - Storable - Tracked by Quantity - Manufacture Route - Has a BOM with atleast 1 component *Component Product* - Storable - Tracked By Lot # How to…
# Product Configuration
*Manufactured Product*
- Storable
- Tracked by Quantity
- Manufacture Route
- Has a BOM with atleast 1 component
*Component Product*
- Storable
- Tracked By Lot
# How to reproduce
- Ensure there is available stock for the component product in a lot
- Create a MO for the Manufatured Product
- Confirm the MO
- Click "Details" on the component product
- Remove the reserved quant and add a new one
- Increase the quantity of this new quant to more than "To Consume"
- Save
- Observe that "Consumed" = The quantity you just set on the quant
- Click on "Produce All"
# The issue
- The Consumed quantity is reset to the "To Consume" quantity.
- Furthermore, a warning popup should be displayed when clicking on "Produce All" but there is none.
- Finally, depending on the version you may get this error message : "You need to supply Lot/Serial Number for products and 'consume' them: - Component Product" even though a lot is already assigned
# Why
All these issues stem from the fact that move_raw_ids.picked from mrp.production is set to False instead of True.
This issue was introduced by this commit (https://github.com/odoo/odoo/commit/ef592464983d66ac76bc71a9886462f1f47dc28d) that changed the way the picked value is set.
In write(self, vals) de stock_move, we have :
```py
if self.env.context.get('force_manual_consumption') and 'quantity' in vals:
moves_to_update = self.filtered(lambda move: move.product_uom_qty != vals['quantity'])
if moves_to_update:
moves_to_update.write({'manual_consumption': True, 'picked': True})
```
Followed a bit later by :
```py
res = super().write(vals)
```
This usually works fine except when vals contains edition commands for move_line_ids. Then, the first write will correclty set picked to True, but then picked will be reevaluted after the second write with :
```py
@api.depends('move_line_ids.picked', 'state')
def _compute_picked(self):
for move in self:
if move.state == 'done' or any(ml.picked for ml in move.move_line_ids):
move.picked = True
else:
move.picked = False
```
If all the resulting move_line_ids from the commands edition have picked set to False, then move.picked will also be set to False.
opw-5937171
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects a recent change that removed a feature in the traceability report. The original fix, which limited breadcrumb size, was deemed a poor solution and has been reverted to restore the intended functionality. This ensures users can properly track component lots within the traceability report.
Original PR description
commit d7f81c25555c800bf296da2507d010257292aa55 It was removed in order to limit the breadcrump size. However it was a stupid solution and it's better to let the feature rather than limiting the breadcrump size. Forward-Port-Of: odoo/odoo#254330
This update corrects an issue where incorrect folio numbering occurred when Chilean accounting (l10n_cl_edi) wasn't configured. The fix ensures folios are properly generated, preventing negative numbering and associated sequence corruption, which could have caused errors in financial reporting. This improves data accuracy and reliability for Chilean operations.
Original PR description
`l10n_cl_edi` overrides `account.move._get_last_sequence()` to ensure the folio belongs to an available in-use CAF. When no CAF exists at all, `l10n_latam.document.type._get_start_number()` returns 0 and the fallback builds a previous sequence using start_nb - 1. Formatting -1 as `:06d` yields “-00001”, which then propagates to “FAC -00002”, “-00003” and corrupts the sequence chain. In addition, returning an invalid “last sequence” may force `sequence.mixin` to search for a free number under the UNIQUE constraint by retrying increments inside a savepoint and rolling back on UniqueViolation, which is costly when many values are already taken see [ _locked_increment()](https://github.com/odoo/odoo/blob/18.0/addons/account/models/sequence_mixin.py#L352). Now we only reset to the CAF start when an in-use CAF actually exists (start_nb > 0). opw-5918758 Forward-Port-Of: odoo/enterprise#108909
This update resolves an issue where Odoo incorrectly generated UBL/QR invoices for customers in other countries (like Colombia). By defaulting the receiver identification type to '0', the system now creates valid XMLs that meet SUNAT requirements, ensuring accurate invoice processing for multi-country businesses.
Original PR description
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an…
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types. In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like: ``` 2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value). ``` Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia): https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4 This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in: - PartyIdentification/ID/@schemeID - AccountingCustomerParty/AdditionalAccountID - the QR payload identification type field This prevents generating invalid UBL/QR content for foreign customers in multi-country setups. Forward-Port-Of: odoo/enterprise#105115
This update corrects a minor issue in the Helpdesk module where ticket links were incorrectly identified as regular links instead of buttons. This change ensures that buttons within email templates function as expected, allowing users to properly interact with ticket information. The fix resolves a visual inconsistency and improves the user experience.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#107888
This update resolves an issue where GS1 barcode filtering would fail due to an error when a barcode was interpreted as a date. The fix prevents this error from blocking product filtering, ensuring accurate internal transfer operations. This improves the reliability of barcode scanning for inventory management.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064 Forward-Port-Of: odoo/enterprise#110679 Forward-Port-Of: odoo/enterprise#110636
This update resolves a problem where tours on the website weren't loading translations correctly, particularly in newer Chrome versions. The fix adds a temporary step to ensure translations start loading promptly, preventing delays and interruptions during the tour experience. This ensures tours function reliably for all users.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/odoo#254210 Forward-Port-Of: odoo/odoo#253896
This update resolves a problem where tours on the website were failing to load translations correctly, particularly for new startup requests. The fix introduces a temporary step to ensure translations load before the tour begins, addressing an issue exacerbated by recent Chrome browser updates. This ensures tours function reliably for all users.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#110856 Forward-Port-Of: odoo/enterprise#110648