Daily updates from Odoo
Wednesday, May 20, 2026
5 changes · master
Resolved issues and error corrections
This update resolves an issue where kitchen tickets were incorrectly printed after a platform order was cancelled, regardless of where the cancellation occurred (Odoo PoS or the provider platform). Now, cancelled platform orders will no longer trigger kitchen ticket printing, improving order accuracy and reducing unnecessary printing.
Original PR description
This fixes platform orders should not send to kitchen printer when the platform orders being cancelled. Currently accepting platform orders will not send to kitchen printer. However when cancelling platform orders on either provider platform, or within Odoo PoS. It will print a kitchen ticket of customer note. task-6071740 Forward-Port-Of: odoo/enterprise#114171
This update fixes an error in the Luxembourg Annual VAT Declaration report that resulted in incorrect calculations for Appendix E 1a. The fix ensures that VAT tax codes are included accurately in the formula, resolving a discrepancy in the reported total. This ensures accurate VAT reporting for Luxembourg businesses.
Original PR description
### Issue: The formula `L10N_LU_TAX_163` in the Luxembourg Annual VAT Declaration was incorrect: - `L10N_LU_TAX_791.year_start` was added twice - `L10N_LU_TAX_993.year_start` was missing As a result, the computed total in Appendix E 1a was incorrect ### Steps to reproduce: - Install `l10n_lu_reports` - Open the `Report: Annual VAT Declaration (LU)` - Go to `Appendix E` - Use the `Start of Financial year` pencil icons to manually set values for fields `791` and `993` - Check the computed value of field `163` After the fix, both values are included exactly once in the formula opw-6158950 Forward-Port-Of: odoo/enterprise#117214
This update fixes an issue where freight charges were incorrectly applied to all pickings, particularly with backorders. The change ensures freight costs are only included in the first confirmed picking, aligning with the correct invoicing process and accurately reflecting delivery costs.
Original PR description
Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result: 1. When creating backorders, the `freight_costs` are…
Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result: 1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings. 2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself. Solution ----- For the first problem, there are a couple things to keep in mind: - the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer - products can be added and removed from the picking after the SO has been confirmed - actual delivery cost can change between invoice date and actual delivery date - picking can be split into multiple packages at the user's discretion Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders. ----- Ticket: opw-6013387 Forward-Port-Of: odoo/enterprise#117115 Forward-Port-Of: odoo/enterprise#111304
This update ensures that the first variant image displayed on the external website matches the first variant selected in the product configurator and shop category page. It corrects a previous issue where the website wasn't consistently showing the correct initial variant, leading to a potentially confusing customer experience.
Original PR description
When generating a product, set product.template.attribute.value sequences so that the variant that shows first in the external website is also first by _get_first_possible_variant_id(). This ensures the correct variant image appears on the shop category page and is pre-selected in the product configurator. Forward-Port-Of: odoo/enterprise#117701
This update fixes a potential crash during bank statement imports by ensuring the correct journal is selected based on currency and IBAN. The system now automatically finds the best match, preventing errors and improving the reliability of importing bank statement data. This enhances data accuracy and reduces potential user issues.
Original PR description
Behavior before: The import flow could crash with an "Expected singleton" error if multiple journals shared an IBAN. Additionally, the system blindly accepted the current context ('self') as the…
Behavior before:
The import flow could crash with an "Expected singleton" error if multiple
journals shared an IBAN. Additionally, the system blindly accepted the
current context ('self') as the target journal, even if its currency or
bank account mismatched the statement, often leading to avoidable
UserErrors.
Behavior after:
The system now validates 'self' against the statement's currency and IBAN
before assignment. If a mismatch is found, it automatically searches for
the correct journal. The search is now restricted by currency and includes
a limit=1 to prevent crashes and ensure accurate selection.
Root Cause:
In _find_additional_data(), 'journal = self' was assigned without validation.
Furthermore, the fallback search lacked a record limit and currency matching
logic, allowing multiple records to be returned when duplicates or
multi-currency setups existed.
Fix:
- Added validation for the initial 'self' candidate (currency and IBAN match).
- Refined the search domain to include currency matching (journal or
company fallback).
- Added limit=1 to the search to guarantee a singleton recordset.
opw-5462037
Forward-Port-Of: odoo/enterprise#117394
Forward-Port-Of: odoo/enterprise#115475