Daily updates from Odoo
Tuesday, May 5, 2026
11 changes · saas-18.2
Resolved issues and error corrections
This update resolves an issue where Amazon's stock synchronization was failing due to incorrect fulfillment channel data. The system now uses a new API field to accurately determine channel availability, defaulting to FBM when necessary to ensure stock updates continue. The update also improves the process for handling user-specific configurations.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#114473
This update adds logging of Amazon's request IDs for SP-API responses. Previously, these IDs were missing, making it harder for support teams to troubleshoot issues with Amazon. Logging these IDs will significantly improve response times and resolution for support requests.
Original PR description
Each response from Amazon's SP-API includes a request identifier used by their support team for debugging. This identifier was not previously logged, making support investigations more difficult. Forward-Port-Of: odoo/enterprise#114483
This update corrects a bug that prevented users from saving accounting settings when GST registration was unregistered. The fix ensures the system correctly checks GST registration status, preventing a 'Missing Required Fields' error and allowing users to configure the module properly. This improves the usability of the Invoicing module for businesses operating in India.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001
This update resolves an issue where multiple users were incorrectly added to WhatsApp discussion channels after a message was sent. The fix ensures that only the user who initiated the conversation is added to the channel, preventing unnecessary notifications and channel clutter. This improves the user experience and channel management efficiency.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138 Forward-Port-Of: odoo/enterprise#102452
This update resolves a problem with the CSV export for Dutch Intrastat reporting, which was broken following a recent technical update. The fix addresses an incorrect formatting of 'Commodity flow' data and ensures the database is up-to-date before generating the report, improving data accuracy for reporting.
Original PR description
Since the technical refactoring of intrastat in 18.0, the csv export in `l10n_nl_intrastat` seems broken. Here is the fixes done in this commit: 1. `Commodity flow` is supposed to be a single diggit (6 or 7) but an empty blank space was hidden. 2. Switching the condition on `country_origin_code` as it was the opposite 3. Add a `flush_all` before calling the report during the export, to be sure the database is up to date. opw-5799126 Forward-Port-Of: odoo/enterprise#115791
This update resolves an issue where users could accidentally select customers from different companies within the Helpdesk module. The fix adds a restriction to the customer selection field, ensuring users only see customers within their assigned company. This improves data accuracy and prevents potential errors in ticket management.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
This update resolves an issue causing incorrect rounding when importing purchase orders processed through OCR. The fix restores the original rounding precision, aligning with the intended functionality for EDI processing, rather than the OCR process. This ensures accurate financial data import.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116021
This update fixes an error in how VAT reimbursement moves are calculated when carrying over unclaimed tax amounts. The previous calculation incorrectly used data from the previous month's tax report, leading to inaccurate reimbursement amounts. This ensures accurate VAT reporting and proper reimbursement processing.
Original PR description
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and…
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and post a bill in May containing a VAT amount. - Create and post a bill in June containing a VAT amount. - Create a VAT return for May to carry over the VAT amount to the next month. - Create a VAT return for June, requesting the full VAT amount to be reimbursed. - Validate and send the June VAT return. - Check the generated reimbursement move Issue: Line values does not correspond to anything real/tangible. It occurs because when computing the ratio for the move we check the last tax report entry, where we find the amount of tax from the past months and a line balancing the last month that should not be taken into account. The "Balance tax current account (receivable)" line from the tax closing entry is mistakenly picked up as a tax carried forward line, throwing off the amounts. opw-5961836 Forward-Port-Of: odoo/enterprise#115451
This update resolves an issue where error messages from the Danish tax reporting system (l10n_dk_rsu) could cause unexpected errors. The fix ensures that error messages are handled correctly, preventing system crashes and improving the reliability of tax report generation. This resolves a technical bug related to data type mismatches.
Original PR description
before this commit, if the SKU server was returning an error message, the error handler would raise an exception because of the lazyTranslate. The reason is that `join()` expects an actual sting as argument, not a lazy string. This commit adds some tests for the error case and fixes the error due to the lazytranslate in the error codes. opw-6171466 Forward-Port-Of: odoo/enterprise#115515
This update fixes a minor typo in the French Profit & Loss report. The term "exceptionnel" was incorrectly using masculine form when it should be feminine to accurately reflect charges. This ensures correct reporting and compliance for French accounting standards.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges.
This update resolves an error in the Luxembourg VAT reports (FAIA) caused by a missing required TaxType element ('TVA'). The fix ensures the reports comply with Luxembourg tax regulations, preventing export failures. This was triggered by a customer report and verified against XSD files.
Original PR description
This is one of several commits fixing the FAIA xml export. The customer in ticket [opw-5427296](https://www.odoo.com/odoo/unassigned-tasks/5427296) received several errors which mention that the `TaxType` element should be 'TVA'. This is corroborated by one of these elements in the XSD files for the FAIA report. The XSD files can be found at the link below. https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-6118272 [link](https://www.odoo.com/odoo/project.task/6118272) Forward-Port-Of: odoo/enterprise#113720