Wednesday, July 2, 2025
9 changes · saas-18.1
Resolved issues and error corrections
Malaysia e-invoicing now allows credit notes to be submitted even when the original invoice was not previously sent to MyInvois, such as invoices created before adoption of the platform. The issue date is also aligned with MyInvois requirements by using the current UTC date, improving compliance and reducing blocked submissions.
Original PR description
So far, we have enforced that credit notes must be linked to an invoice that has been sent to MyInvois. In real life, this is too strict. Users could be issuing credit notes for invoices created before MyInvois was used, in which case these must still be reported to MyInvois even though the original invoice isn't on the platform. This also fixes a small issue with the issue date, which was set to the invoice date up until now but on their platform they explicitly ask for today in UTC timezone. task-4889022 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216710 Forward-Port-Of: odoo/odoo#215347
This fixes an error where manufacturing kit components could be over-counted when a bill of materials used very large quantities and decimal unit precision. Delivery orders now use the same correct component calculation shown in the BoM overview, helping prevent inaccurate stock moves and fulfillment quantities.
Original PR description
## How to reproduce - Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision - Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1" - Create Kit BoM…
## How to reproduce
- Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision
- Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1"
- Create Kit BoM for 5000 Units of "CMP 1" using 50 of "CMP 2"
- Check "FNS" BoM Overview:
- "CMP 2" quantity shows the correct 0.10 Units (1 * 10 / 5000 * 50) (ok)
- Create Delivery order for 1 Unit of FNS
- "CMP 2" quantity is 0.50 Units (KO)
OPW-4804958
---
### BoM Overview
### BoM exploded
---
### Test result without fix:
```
2025-06-25 00:00:00,000 28629 ERROR oes_test_17 odoo.addons.mrp.tests.test_bom: FAIL: TestBoM.test_02_explode_rounding
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/tests/test_bom.py", line 63, in test_02_explode_rounding
self.assertEqual(lines[0][1]['qty'], 0.10)
AssertionError: 0.5 != 0.1
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#216709
Forward-Port-Of: odoo/odoo#215821This fix prevents Odoo from creating an extra, incorrect warehouse transfer when a confirmed sales order quantity is reduced under specific multi-step delivery route settings. Inventory movements now use the destination defined on the route rule consistently, keeping stock operations accurate and avoiding confusing negative transfers.
Original PR description
Steps to reproduce: - Install Sales and Stock - Activate the multi-step routes setting - Go to a Delivery route in the warehouse - Change the `location_dest_id` of the operation type set on the rule…
Steps to reproduce: - Install Sales and Stock - Activate the multi-step routes setting - Go to a Delivery route in the warehouse - Change the `location_dest_id` of the operation type set on the rule - Enable the "Location Dest. Taken from Rule" checkbox - Ensure `rule.location_dest_id` and `operation_type.location_dest_id` are different - Create a Sales Order (SO) for a product with quantity = 5 and confirm - Change the SO line quantity to 3 and save Issue: A second picking is created with a move taking the product from `rule.operation_type.location_dest_id -> rule.operation_type. location_src_id` with quantity = -2. This happens because the decrease in the SO quantity triggers a negative move, and this move is not merged with the existing positive move. Instead, a new move is created in the opposite direction. In `_merge_moves`: https://github.com/odoo/odoo/blob/3c4275fb00255e519f01bf5547eff1db3a59d4b5/addons/stock/models/stock_move.py#L1191-L1193 It checks if the negative move has similar characteristics to the existing positive moves. However, the `neg_key(neg_move)` differs in `location_dest_id`, so the merge fails. This happens because the negative move does **not** read the `location_dest_id` from the rule — unlike the procurement, which **does** use the rule and therefore creates positive moves with the correct destination. When the negative move is created with the procurement, it initially has the correct `location_dest_id`. But then: https://github.com/odoo/odoo/blob/b984c72df398c4fe942d8894442e4e893ca0660e/addons/stock/models/stock_move.py#L1191 triggers `_compute_location_dest_id`, which doesn't consider the `rule.location_dest_id` and defaults to `operation_type. location_dest_id`, causing the merge to fail due to mismatched destination_locations. The positive move has read the correct value, because when it was assigned to a picking, the picking has the correct destination from the procurement. But for the neg_move it has picking None so it maps to the operation_type without consdiering the location from rule checkbox. opw-4793171 Forward-Port-Of: odoo/odoo#212355
Argentina B invoices for final consumers now include the required tax breakdown table even when VAT is 0.00. This helps ensure compliant customer invoices and avoids missing mandatory information on PDF documents.
Original PR description
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or…
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or other taxes sum is 0.0 (we are not showing any information if sums 0.0) After checking with ARCA Online PDF sxampels, and some feedback of Argentinen users, we found out that the Legend should be always present. event if the totals of theTax Breakdown are shown with 0.0 ### **Steps to reproduce** Go to an Argentina Company Create a new invoice for "Final Consumer" with document type "Invoice B" Create a product line with tax 0 (could use either VAT Exempt, VAT 0, VAT Not Taxed) Print the PDF ### **Current behavior before PR:** The PDF is NOT showing the Tax Breakdown table  ### **Desired behavior after PR is merged:** The PDF is showing the Tax Breakdown with the line VAT Content 0.0  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Manual Forward-Port-Of: https://github.com/odoo/odoo/pull/207367 Forward-Port-Of: odoo/odoo#214866
This fixes an issue where images in the editor could stay stuck at a previously saved size after users tried to resize them back to their default dimensions. Email template editing is more reliable because saved compatibility settings no longer interfere while editing, and they are still reapplied when needed on save.
Original PR description
Problem: When resized images (e.g., with `style.width: 50%`) are processed by `convert_inline`, `width` and `height` attributes may be added for email client compatibility. These attributes override resizing changes, forcing the last saved dimensions and preventing fallback to the image's default size. Solution: Remove `width` and `height` attributes from the content inserted into the editor. They will be correctly re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Resize the image to 100% - Save - Resize the image back to default - The image keeps the 100% size opw-4863515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213786
When an Argentine company or database is created, Odoo now installs the more commonly used Responsable Inscripto chart of accounts by default instead of the less common Monotributista setup. This reduces the chance that businesses start with the wrong accounting configuration and need manual correction.
Original PR description
### Description of the issue/feature this PR addresses: Odoo will try to auto install a Coa when creating a database or creating a new company where country is defined The problem is that in…
### Description of the issue/feature this PR addresses: Odoo will try to auto install a Coa when creating a database or creating a new company where country is defined The problem is that in Argentina we have different CoA depending on the AFIP Responsibility, and the one that is currently installed by default is the 'ar_base' (Responsable Monotributista): the less used one. In this case we prefer to do not install any CoA and let the user to install it manually (as it was working in older versions, but it is not possible). For that reason we made this change force to install 'ar_ri' (Responsable Inscripto) CoA by default instead ### Current behavior before PR: 1. Create a new company with country AR 2. Will automatically install the "Responsable Monotributista" Coa ### Desired behavior after PR is merged: Now will install the "Responsable Inscripto" Coa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215916
Stock transfers now keep all relevant source references when multiple replenishment moves are assigned to the same picking. This prevents the origin field from being erased, making warehouse documents easier to trace and reducing confusion during replenishment.
Original PR description
**Current behavior:** During the assignment of a picking, if any of its moves have an origin that does not match its own, the origin will be cleared altogether. **Expected behavior:** The different…
**Current behavior:** During the assignment of a picking, if any of its moves have an origin that does not match its own, the origin will be cleared altogether. **Expected behavior:** The different origin should be appended to the existing origin string (as is done in batch replenishment, for example). **Steps to reproduce:** 1. Create 2 products, create a secondary warehouse 2. Create an orderpoint for each product, make the route on both of them the (first?) pointed to by `resupply_route_ids` on the primary warehouse 3. Set `qty_to_order` 1 on each of the orderpoints, and one at a time click the 'Order' button 4. The move generated for each replenishment action will ultimately be added to a single picking -> in the end see that its `origin` field is cleared **Cause of the issue:** We currently decide to clear the picking origin during assignment if any of its moves have a different origin. **Fix:** Instead, append the different origin string to the picking. opw-4749519 Forward-Port-Of: odoo/odoo#212674
Point of Sale self-invoicing now saves customer details entered through the receipt QR code form, even when the order already has a customer linked. This ensures updates such as VAT numbers or other required invoice details are reflected in the customer record, reducing manual corrections for staff.
Original PR description
When doing a self invoice with the QR code on the PoS receipt, if a partner was linked to the order, the record would not be updated with the values entered in the self invoice form. Steps to reproduce: ------------------- * Enable the self service invoice feature in the PoS settings. * Open a PoS session. * Make and order with a partner set on it. * Finalize the order and scan the QRCode on the receipt. * Fill the form with some new informations (like a new VAT number) > Observation: Check the partner on the backend, the values are not updated. Why the fix: ------------ We update all the mandatory and optionnal fields of the partner record with the values entered in the self invoice form. opw-4676244 Forward-Port-Of: odoo/odoo#214552
This fixes Chilean electronic factoring documents so the assigned amount is always reported in Chilean pesos, even when the invoice uses another currency. It prevents incorrect AEC XML values that could cause reporting or compliance issues with Chilean tax processes.
Original PR description
In this bug, when a currency other than CLP is selected in invoicing, the generated aec has MontoCesion tag with the rate of selected currency, while it must always be in CLP. To reproduce the bug: 1- Create a database with invoice app and a Chilean company 2- Create an invoice with document type of 34 3- Choose a different currency than CLP 3- Click on `Send Now to SII` and Create AEC 4- Click on Yield Entry smart button 5- Download generated AEC xml file 6- You can see the value of MontoCesion is in selected currency which is wrong opw-4830957 Forward-Port-Of: odoo/enterprise#88175