Daily updates from Odoo
Tuesday, May 6, 2025
14 changes
Resolved issues and error corrections
Fixes an error in Spanish SII reporting where the equivalence surcharge tax total could include only the last invoice line instead of the full invoice amount. This helps ensure invoices sent to the Spanish tax authority contain accurate tax figures when multiple lines use the same surcharge taxes.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_es_edi_sii - Switch to a Spanish company (e.g. ES Company) - Create an invoice: * Customer: [a Spanish customer] (e.g. Ayuntamiento De Bilbao) *…
**Steps to reproduce:** - Install Accounting and l10n_es_edi_sii - Switch to a Spanish company (e.g. ES Company) - Create an invoice: * Customer: [a Spanish customer] (e.g. Ayuntamiento De Bilbao) * 1 invoice line with a "Sujeto" type tax (e.g. "4% G") and a "Recargo de Equivalencia" type tax (e.g. "0.5% SE") * another invoice line with the same taxes - Confirm the invoice - Send the invoice to "SII IVA Llevanza de libros registro (ES)" - Check the sent "jsondump.json" file in the attachments **Issue:** Value of "CuotaRecargoEquivalencia" in the json is incorrect. It only contains the tax amount of the "Recargo de Equivalencia" tax (i.e. "0.5% SE") of the second line, instead of the sum of the tax amount from both lines. **Cause:** When computing the details for the "Recargo de Equivalencia" taxes, each invoice line is grouped by their combination of taxes. For each combination, we keep the tax details of the recargo tax of one line (the latest one) overriding the previous values, instead of summing them. **Solution:** Sum the tax amount for each group of taxes. opw-4650892 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing a quotation template now clears the previously selected header and footer documents before applying the new template. This prevents sales quotations from being printed with documents from multiple templates, keeping customer-facing PDFs accurate and consistent.
Original PR description
## Version: 18.0 > 18.1 (test to fw up to master) 18.2+ fixed by https://github.com/odoo/odoo/pull/186649 ## Issue: Changing the `Quotation Template` on a quotation after ## Steps to reproduce:…
## Version:
18.0 > 18.1 (test to fw up to master)
18.2+ fixed by https://github.com/odoo/odoo/pull/186649
## Issue:
Changing the `Quotation Template` on a quotation after
## Steps to reproduce:
*Ensure `PDF Quote builder` is checked in `Settings` app*
- In `Sales / Configuration / Sales Orders:Headers/Footers`:
- Ensure there are at least 2 documents *(add them if needed)*;
- Set their `Document type` to `Header`;
- Go to `Sales / Configuration / Sales Orders:Quotation Templates`:
- Create 2 new templates (e.g. "test1" and "test2"):
- In "test1", under the `Quote Builder`, add one of the documents;
- In "test2", under the `Quote Builder`, add the second document;
- Create a new quote for any customer:
- Select "test1" as `Quotation Template`;
- Under the `Quote Builder`, select the header document;
- Change the `Quotation Template` for "test2";
- Select the header document;
- Change back to "test1" and see the header document is still selected;
- Print the quote via the action button;
- The PDF contains both "test1" and "test2" document headers.
## Fix:
Partial backport of https://github.com/odoo/odoo/pull/186649
opw-4709144This fix ensures point of sale order changes, such as deleted order lines, are not lost when a sync attempt fails. It also avoids errors when another device has already removed a related record, helping keep POS orders consistent across devices.
Original PR description
Before this commit, when an orderline was removed and the order failed to sync on the first attempt, the deletion command was already discarded. As a result, the order could be synced later with the previously deleted order line still present. Additionally, if a record is removed from another device but the change has not yet been synced, attempting to remove or modify that record can result in a "missing record" error. This commit resolves the issue by checking for the record's existence before performing any write operations. opw-4707596 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the Spanish TicketBAI electronic invoicing flow where certain tax reporting codes could be split and reported incorrectly. The update helps ensure compliant invoice XML output and adjusts tests to cover the corrected behavior.
Original PR description
The fw-port in https://github.com/odoo/odoo/pull/208205 was not changed correctly as the method on the taxes returned one element, but the calling method needed to return a list and as such the string was interpreted as a list giving two claves for e.g. 01. In the meantime, the tests are adapted as well. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a website ticket is created, Odoo now looks for an existing customer using the company from the current context. This prevents tickets in one company from being linked to a customer record belonging to another company, avoiding access errors for users limited to a specific company.
Original PR description
To reproduce: ============= 1. have a partner with email test@odoo.com in company1 2. allow to Demo only the company2 3. setup helpdesk team for company2 and enable it on website 4. create a ticket from website with email : test@odoo.com 5. check the ticket will be created with the partner from company1 6. try to open the ticket as Demo user, you will get an access error Problem: ========= `find_or_create` method of `res.partner` model is not taking into account the company_id from the context when searching for the partner. Solution: ========= The `find_or_create` method of `res.partner` model is modified to consider the company_id from the context when searching for the partner. opw-4699518 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Products that are not available for self-ordering are no longer loaded or shown in the Point of Sale self-order interface. This avoids confusing customers with items marked as out of stock when they should not appear at all.
Original PR description
Before this commit, products that were not available for self-ordering were still loaded into the PoS and displayed as "Out of stock." This could cause confusion for users. After this commit, unavailable products are no longer loaded or displayed in the PoS, ensuring that only available products are shown to customers. opw-4764785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale combo item prices now recalculate when a cashier changes the order's pricelist. This helps ensure customers are charged the correct promotional or customer-specific price for combo products.
Original PR description
- Fix issue where combo price were not recomputed when changing the pricelist of the order. - The issue was due to the fact that in the `pos_order.set_pricelist()` method we were only recopute the combo line that have a `price_type === "original"`, and that the combo line `price_type` was undefined. Now when a adding a combo product to the cart, all of its lines have a `price_type` set to `automatic` initially, and inside `pos_order.set_pricelist()` we now recompute the price of the combo line that have a `price_type === "automatic"`. Steps to reproduct: - Create pricelists and add it to pos config - Open PoS - Add combo product to cart - Change pricelist - => Price is not recomputed based on the pricelist as it should task-id: 4707663 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where replenishing scrapped manufacturing components could make the manufacturing order show the wrong remaining component quantity. This helps production teams keep reservations accurate after scrap and replenishment, reducing inventory confusion and production delays.
Original PR description
Before PRs https://github.com/odoo/odoo/pull/154912 and https://github.com/odoo/odoo/pull/177079, _free_reservation preserved MTO links by retaining move_orig_ids, allowing Manufacturing Orders (MOs)…
Before PRs https://github.com/odoo/odoo/pull/154912 and https://github.com/odoo/odoo/pull/177079, _free_reservation preserved MTO links by retaining move_orig_ids, allowing Manufacturing Orders (MOs) to reserve components from replenishment pickings. PR https://github.com/odoo/odoo/pull/149054 added replenishment moves to the MO’s procurement.group and assigned move_dest_ids to link them to component moves, supporting 2-step manufacturing flows. PR https://github.com/odoo/odoo/pull/154912 introduced the stock.break_mto parameter to conditionally preserve move_orig_ids, while PR https://github.com/odoo/odoo/pull/177079 removed it, making move_orig_ids clearing unconditional for MTO-to-MTS transitions, reintroducing a regression due to the move_dest_ids assignment. Steps to Reproduce =================== 1. Create an MO with a component qty of 20 units and confirm it. 2. Scrap 5 units of the component with Replenish enabled. 3. Validate the replenishment transfer. 4. Check the MO component line. The component qty is reduced to 5. Issue ===== The move_dest_ids assignment to replenishment moves (from https://github.com/odoo/odoo/pull/149054) prevents _trigger_assign from reserving correct MO component quantities when move_orig_ids are cleared (per https://github.com/odoo/odoo/pull/177079), as the link to the original MO requirements is broken. Fix === Removed the move_dest_ids assignment for replenish moves enabling trigger_assign to automatically reserve the correct component quantities, while maintaining the MTO-to-MTS transition (cleared move_orig_ids) and the procurement.group assignment. Task: https://github.com/odoo/odoo/commit/44437975bdaf1e7c4f5540a5cb789d9db0ec0b0b
Point of Sale now sends the session closing notification to all connected devices even when the session is closed from the backend after an error. This helps staff stay aligned and avoids devices missing important closing updates.
Original PR description
Before this commit, the session closing message was in the method called from the UI. But in case of error during the closing control, the user must close it from the backend. In this case, the message was not sent to all devices. This commit moves the message to the write method of the session to ensure that the message is sent to all devices, even if the session is closed from the backend.
Helpdesk tickets created from the website now match customers within the correct company instead of reusing a contact from another company with the same email address. This prevents access errors for users limited to one company and ensures tickets are assigned to the right customer record.
Original PR description
To reproduce: ============= 1. have a partner with email test@odoo.com in company1 2. allow to Demo only the company2 3. setup helpdesk team for company2 and enable it on website 4. create a ticket from website with email : test@odoo.com 5. check the ticket will be created with the partner from company1 6. try to open the ticket as Demo user, you will get an access error Problem: ========= `find_or_create` method of `res.partner` model is not taking into account the `company_id` when searching for the partner. Solution: ========= uses `_mail_find_partner_from_emails` method of `mail.thread` model to find/create the partner with extra domain containing `company_id`. opw-4699518
Indian GST reports now use the updated HSN reporting format based on a configurable effective date. If the setting is missing or incorrect, the system falls back to the government guideline date of 1 May 2025, helping businesses stay compliant without manual code changes.
Original PR description
Apply the HSN schema based on the 'l10n_in_reports.hsn_new_schema_apply_date' system parameter. If the parameter is missing or invalid, default to 2025-05-01 as per government guidelines.
Brazilian electronic invoicing with Avalara now preserves full invoice line descriptions without forcing customers to shorten them manually. Line breaks are converted before sending data to Avalara, avoiding a known processing issue while keeping the official PDF and XML output unchanged.
Original PR description
In some cases, it's not possible for customers to trim the description of an invoice line to the accepted length (e.g. for traceability or completeness). It turns out that Avalara will trim and transform the descriptions on our behalf to make them compatible with the government's API. As part of that process, they translate `\n` characters to ` | ` before sending it to the government. Unfortunately, there seems to be a bug with that process on their side. When a '\n' character is included in the description, they don't trim the description they send to the government sufficiently. Perhaps they trim before the '\n' to ' | ' translation, or perhaps they have some other bug. We sidestep the issue by doing that same translation on our side and sending them that. It doesn't result in any change on the EDI PDF or XML, and this way we can avoid hardcoding these limits on our side. task-4726372
When a sales order includes both regular and subscription products, confirmed invoices now schedule the next invoice using the subscription billing period instead of defaulting to the next day. This prevents customers on monthly or other recurring plans from being invoiced too soon.
Original PR description
Issue ----- For sale orders where one of the products is a subscription, after confirming the invoice, the date for the next invoice is set to the next day regardless of the billing period specified on the SO. Steps to reproduce ----- - Create a subscription product - Type: Service - Invoicing Policy: Based on Delivered Quantity - Recurring Plan set to Monthly - Create a SO - Add a regular product and the subscription product - Recurring Plan: Monthly - Confirm SO - Set delivered quantities - Create a new Invoice from the SO - Confirm the Invoice -> The next invoice date is the next day instead of month Cause ----- Not all of the order lines are subscriptions, so the next invoice date is never increased by the planned billing period. Solution ----- Change the condition from all lines to any line. ----- Ticket: opw-4549344
Batch payments in foreign-currency journals now show residual amounts in the company currency when linked payments do not have journal entries. This prevents incorrect credit values during bank reconciliation and helps users match bank statement lines accurately.
Original PR description
Fix issue when computing `amount_residual` for batch payments linked to payments without a journal entry. In such cases, the `amount_residual` may be returned in the journal currency instead of the company currency, which causes issues during bank reconciliation. Steps to reproduce: 1. Create a journal in another currency (e.g. EUR, with USD as company currency) 2. Create two customer payments in this journal 3. Create a batch payment using those two payments, in the same EUR journal 4. In the reconciliation page of the journal, add a bank statement line and try to reconcile it The batch payment line in the reconciliation view will show a credit amount equal to the "amount in currency", because it was wrongly converted from EUR to EUR instead of EUR to USD. opw-4759842