Wednesday, March 26, 2025
3 changes · saas-17.4
Resolved issues and error corrections
This update brings the spreadsheet component to a newer maintenance version with fixes for chart handling, read-only behavior, color conversion, and Excel import/export. Users should see fewer visual inconsistencies and smoother spreadsheet interactions, especially when working with charts and XLSX files.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a81a8f430 [REL] 17.4.28 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a81a8f430 [REL] 17.4.28 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3cd084c35 [FIX/PERF] Charts: fix loop condition [Task: 4675166](https://www.odoo.com/odoo/2328/tasks/4675166) https://github.com/odoo/o-spreadsheet/commit/f1fd14238 [FIX] topbar: empty composer is focusable in readonly mode [Task: 4653139](https://www.odoo.com/odoo/2328/tasks/4653139) https://github.com/odoo/o-spreadsheet/commit/0c9c0a053 [FIX] color: `toHex` don't work with alpha = 0 [Task: 4660317](https://www.odoo.com/odoo/2328/tasks/4660317) https://github.com/odoo/o-spreadsheet/commit/56bb22ef6 [FIX] local: delete unused file formula_locale [Task: 4655913](https://www.odoo.com/odoo/2328/tasks/4655913) https://github.com/odoo/o-spreadsheet/commit/5acb8fc4f [FIX] xlsx: prevent unwanted legend when importing chart from excel [Task: 4632987](https://www.odoo.com/odoo/2328/tasks/4632987) https://github.com/odoo/o-spreadsheet/commit/dcb5c0824 [FIX] xlsx: export reversed icon sets [Task: 4655950](https://www.odoo.com/odoo/2328/tasks/4655950) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Inter-company deliveries and receipts of kit products now update delivered and received quantities correctly. This prevents sales and purchase orders between companies from showing misleading fulfillment progress, especially when kit component ratios differ from the final product.
Original PR description
Currently there are two bugs: 1) Selling a kit product to another internal company (inter_company) and validating the delivery will not update the `qty_delivered` field on the corresponding…
Currently there are two bugs: 1) Selling a kit product to another internal company (inter_company) and validating the delivery will not update the `qty_delivered` field on the corresponding `SaleOrderLine` * Currently the filters to capture moves which informs the delivered quantity of the line do not account for moves with `location_dest_id` pointing to the inter-company transit location (which should count towards the delivered value) 2) Receiving a kit product via inter_company which has a `comp:final` ratio >1 will result in an inaccurate update on the `qty_received` field on the corresponding `PurchaseOrderLine` * The BoM of the sold kit-product belongs to the selling company, and in the purchase_mrp override of `_compute_qty_received` they fail to get marked as kit lines because the `bom_line_id` is hidden due to a company-precise domain constraint **Steps to reproduce:** *Having `sale_purchase_stock_inter_company_rules` and enabled synchronization of sale & purchase orders for both companies* 1. Create a kit product 2. Deliver it to another internal company 3. After validating the delivery, check the the sale order line and observe that the delivered qty is 0 **Cause of the issue:** When computing `qty_delivered`, we have the following filters to capture in/out move qty: https://github.com/odoo/odoo/blob/ef1be75601e7ce346d8e6b9367505cbf39b05101/addons/sale_mrp/models/sale_order_line.py#L69-L70 which don't account for moves to inter-company transit. When computing `qty_received`, we aggregate purchase lines: https://github.com/odoo/odoo/blob/b13e46f06c1d3166fd64fc72cacd8af1f3673ae6/addons/purchase_mrp/models/purchase.py#L56 however using the line's `company_id` means the BoM belonging to the delivering company isn't revealed. Then the `qty_received` is computed as though the line was an ordinary product, leading to the mismatch between product and qty. **Fix:** Modify the existing incoming/outgoing move filters in the qty received and delivered compute methods to account for inter-company moves. opw-4267210
Inter-company sales and purchases of kit products now update delivered and received quantities correctly. This prevents mismatches in order status and inventory progress when companies trade bundled products internally.
Original PR description
Currently inter-company kit transactions aren't working: 1) Selling a kit product to another internal company (intercompany) and validating the delivery will not update the `qty_delivered` field on the corresponding `SaleOrderLine`: Currently the filters to capture moves which informs the delivered quantity of the line do not account for moves with `location_dest_id` pointing to the inter-company transit location (which should count towards the delivered value) 2) Receiving a kit product via intercompany will result in an inaccurate update on the `qty_received` field on the corresponding `PurchaseOrderLine`: Tests added here due to inter-company rule modules being enterprise only. opw-4267210