Daily updates from Odoo
Wednesday, March 12, 2025
12 changes
Resolved issues and error corrections
This update brings Odoo Spreadsheet up to the latest maintenance version, fixing issues with Excel imports, chart labels, sheet switching while editing, and data validation. It also improves spreadsheet performance, making larger or more complex spreadsheets faster and more reliable for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d8dea1b8e [REL] 18.0.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d8dea1b8e [REL] 18.0.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/359d0ccde [FIX] xlsx: correctly import labels from scatter charts [Task: 4626572](https://www.odoo.com/odoo/2328/tasks/4626572) https://github.com/odoo/o-spreadsheet/commit/daf2fad27 [FIX] BottomBar: Keep editing when selecting sheet in bottombar list [Task: 4626098](https://www.odoo.com/odoo/2328/tasks/4626098) https://github.com/odoo/o-spreadsheet/commit/d6264f24a [PERF] content_helper: pushElement use cache instead of deepEquals [Task: 4563258](https://www.odoo.com/odoo/2328/tasks/4563258) https://github.com/odoo/o-spreadsheet/commit/40ebc1cd3 [PERF] deepCopy: optimize initialization and iteration [Task: 4563258](https://www.odoo.com/odoo/2328/tasks/4563258) https://github.com/odoo/o-spreadsheet/commit/dc04aca7b [PERF] data_normalization: getItemId use cache instead of deepEquals [Task: 4563258](https://www.odoo.com/odoo/2328/tasks/4563258) https://github.com/odoo/o-spreadsheet/commit/8057e52ba [FIX] data_validation: don't prefilter on initial exact match [Task: 4518009](https://www.odoo.com/odoo/2328/tasks/4518009) https://github.com/odoo/o-spreadsheet/commit/da1e832ad [FIX] Xlsx: do not nest literal strings [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) 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>
This change fixes how sales loyalty cards are compared while editing an order, so temporary on-screen loyalty data is matched safely against saved records. It prevents valid loyalty reward lines from being deleted unexpectedly, helping sales orders keep the correct discounts or rewards.
Original PR description
Description of the issue/feature this PR addresses: Loyalty card model in UI is changeable and its values are not in the database yet It can not be compared to already existing records of loyalty cards in the database As they are not of the same datatype, so we should compare their ids instead. Current behavior before PR: Loyalty records in the sale order lines get deleted unfairly Desired behavior after PR is merged: Loyalty records in the sale order lines should be deleted if they follow one of the three conditions, but firts condition should be fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing the date on a confirmed payment now also updates the date on its associated accounting entry. This keeps payment records and accounting records aligned, reducing confusion and helping ensure accurate financial reporting.
Original PR description
Steps to reproduce: - Create a payment - Confirm - Edit and change date - Check associated move Issue: move date is not updated opw-4598423
This fix ensures stock reservations use the product’s base unit of measure when quantities are entered in another unit, such as grams for a product tracked in kilograms. It prevents overstated reserved stock, improving inventory accuracy and avoiding misleading availability information.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- UoM: Kg
- Create a delivery order:
- product: P1
- qty: 100 g
- Mark the delivery as "To Do"
- Set the quantity to 100 g
- Go to the product form of P1 → Update quantity
Problem:
The reserved quantity is set to 100 kg instead of 0.1 kg
opw-4638315This fix lets customers clean up duplicated Point of Sale record identifiers by upgrading the Point of Sale module, instead of needing a technical support intervention. It reduces manual ticket handling and helps affected upgraded databases recover more easily.
Original PR description
This PR introduces a local upgrade script to fix the duplicate UUID issue for customers who upgraded to 18.0 before this PR was merged: #194990 The creation of this local upgrade script was requested towards the end of the conversation on that PR. Before the above PR was merged, older POS [order, order.line, payment] records all got the same UUID during the upgrade to 18.0 for the reason laid out in the conversation on the PR: > [in reference to the default value for the uuid column calling `uuid4()`] ... when the ORM inits the column it will set the same value for all rows. Current behavior before PR: Post-upgrade POS tickets get sent to Tech for us to clean manually via a server action that duplicates UUIDs. Desired behavior after PR is merged: Post-upgrade POS tickets can be solved in Functional by "Upgrading" the `point_of_sale` module **or** the customer doesn't need to create a ticket because they solved it themselves by upgrading their module.
The point of sale customer display now uses the correct language instead of always showing English text. This helps stores provide a localized checkout experience for customers in their preferred language.
Original PR description
Currently, the customer display can only be viewed in English. opw-4419620
Sale orders now calculate taxes consistently with invoices when early payment discounts apply under the always-on invoice tax setting. This prevents mismatched totals between sales documents and invoices, improving pricing accuracy for customers and finance teams.
Original PR description
When applying a payment term with an early payment discount, and when said payment term computes the tax on the 'mixed' setting (_"Always (upon invoice)"_), the tax computation is based on the discounted amount untaxed, whether or not the conditions to benefit from the discount are fulfilled. In other words, applying this payment term will always affect the tax. The invoices can display this behavior, while the sale order would not. In this PR we copy the basics of the tax computation from `account` regarding this aspect. task-4491439
This fixes the Guatemala accounting setup so purchase VAT is treated as included in prices, matching the existing sales VAT behavior. It restores consistency with prior Odoo versions and helps Guatemalan businesses calculate VAT correctly on both sales and purchases.
Original PR description
In Guatemala, both sales and purchases VAT are tax_included. Currently, in version 18.0, only sales VAT has the tax_included configured. But it should be both. On previous versions of Odoo, this was correctly configured as can be seen here: https://github.com/odoo/odoo/blob/17.0/addons/l10n_gt/data/template/account.tax-gt.csv?plain=1#L2 Here, the price_include field is True for both. Version 18.0 should have this same behavior. Fixes #201036 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
Fixed an issue where subscriptions paid through the portal could receive the wrong deadline when their start date was in the past or future. This prevents duplicated quantities on invoices and removes an unnecessary message about an automated job running later.
Original PR description
## Purpose - When paying from the portal a quotation for a subscription starting in the past, or in the future, the deadline is incorrectly set which leads in a duplication of the quantities when creating the invoice. - Removal of the banner indicating the cron will run as not needed anymore Task: 4571168
This fixes an issue where team-based commission plans could assign the full commission to the last salesperson instead of separating results by plan user. Businesses using sales commissions get more accurate payouts and reporting for team achievements.
Original PR description
Before this commit, when a commission plan was based on achivements of team, the plan user would not be distinguished. As a reusult, the last salesperson would get the totality of the commission. opw-ticket: 4534131
The Chilean electronic factoring module now handles unexpected or incorrectly encoded responses from the tax authority when uploading electronic yielding files. Instead of failing when the response is not valid XML, the system records the response in the document chatter so users are informed and can continue investigating with clearer context.
Original PR description
Before the PR: As could be experienced, the SII sometimes sends responses that are not encoded properly, or instead of responding with an XML, the response is an HTML instead. As a consequence of this, a bug was discovered in the response after uploading an AEC file (stands for electronic yielding file in Spanish). After the PR: We added a special parser method, that before transforming the response to a parsed XML, analyzes the encoding, and concludes in an html parsing and posting it to the chatter to inform the user. This is difficult to debug since the possible undocumented responses are not easy to reproduce in an SII test environment, so we applied this method only to a particular case, found in some situations for some users.
POS users in Ecuador can now validate invoiced POS orders without needing inventory administrator rights. This prevents an access error during order synchronization, helping sales continue smoothly at checkout.
Original PR description
### Steps to reproduce: - install l10n_ec_edi_pos - Create a new POS in the EC Company. - With a use without inventory adminstrator access rights: - Open a pos session, select any product and a…
### Steps to reproduce: - install l10n_ec_edi_pos - Create a new POS in the EC Company. - With a use without inventory adminstrator access rights: - Open a pos session, select any product and a custome linked to the EC localisation. - Try to validate the POS order that is invoiced using the cash payment method. #### > An access error is raised with respect to the `stock_valuation_layer_ids` fields of the account.move model ### Cause of the issue: Clicking on validate will launch a call of the `syncAllOrders` method. During this call, missing records will be fetched recursisvely here: https://github.com/odoo/odoo/blob/2108ad3f7c851eeceb84d7459485a18e1574fa64/addons/point_of_sale/static/src/app/store/pos_store.js#L1271 (Note that this call does not exist prior to 18.0). However, as the data contains a pos order that is related to account moves and since the `account.move` model of the localisation inherit from the `pos.load.mixin`: https://github.com/odoo/enterprise/blob/efa1853cf1f9bbd945a91971ffe40c6906482063/l10n_ec_edi_pos/models/account_move.py#L6-L8 the account move will be fetched as a related record to the pos order and we will launch a `read` for the `fields=[]`: https://github.com/odoo/odoo/blob/2108ad3f7c851eeceb84d7459485a18e1574fa64/addons/point_of_sale/static/src/app/models/data_service.js#L513-L515 https://github.com/odoo/odoo/blob/2108ad3f7c851eeceb84d7459485a18e1574fa64/addons/point_of_sale/models/pos_load_mixin.py#L9-L11 However, a read performed with a false value in the `fields` tries to read the value of each field on the records: https://github.com/odoo/odoo/blob/2108ad3f7c851eeceb84d7459485a18e1574fa64/odoo/models.py#L3792-L3798 This includes protected fields such as the `stock_valuation_layer_ids` that can only be read by user's with administrator stock access rights. opw-4498024