Daily updates from Odoo
Friday, July 26, 2024
10 changes
1 change
Resolved issues and error corrections
Invoice totals are now calculated more consistently when taxes are included in prices and global rounding is used. This prevents small rounding differences from changing the untaxed amount, keeping invoice totals aligned with the sum of individual lines.
Original PR description
In case you have 2 invoice lines of 21.53 with 21% price included taxes, the code will compute 21.53 / 1.21 * 2 ~= 35.59 as untaxed amount, 7.47 as tax amount and 40.06 as total amount. However, for now, we decided we want to put the rounding into the tax amount instead of making an adjustment on the untaxed amount because we want the untaxed amount being the sum of the price excluded amount of each line. Here, 2 * round(21.53 / 1.21) = 35.58. So we are forced to put the rounding on the tax instead to have 35.58 + 7.48 = 43.06 and then, round like the round_per_line when the tax is price included. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This fixes a timing issue in the Knowledge sidebar test by waiting until a button is ready before using it. The change helps prevent false test failures, supporting smoother maintenance and more reliable releases.
Original PR description
We wait until the button is enabled before clicking on it.
Cashiers can now switch between email, WhatsApp, and SMS on the receipt screen without losing manually entered contact details. This reduces retyping and helps avoid checkout delays when customer records are missing or incomplete.
Original PR description
Before this commit: ==================== When switching the send options (email, WhatsApp, SMS) on the receipt screen, any manually entered input (such as email or phone number) would be erased if a customer was not selected or if customer data (email or mobile number) was not present. Example: Enter an email address manually. Switch the send option to WhatsApp or SMS. The manually entered email address would be erased. After this commit: ================= Manually entered input will be preserved when switching between send options on the receipt screen. Task-4038000
7 changes
Resolved issues and error corrections
Marketing automation users were unable to set the Unique Field when configuring campaigns due to insufficient access permissions. This fix grants the necessary read access to field definitions, allowing users to properly configure their marketing campaigns without encountering access errors.
Original PR description
Current behaviour: --- Connected as Marc Demo, cannot set the Unique Field of any marketing campaign Steps to reproduce: --- 1. Go to Settings > Users > Marc Demo 2. At Marketing Automation, set User 3. Connect as Marc Demo 4. Go to Marketing Automation 5. Open any campaign 6. Try to set the Unique Field 7. Access Error Cause of the issue: --- unique_field_id is comodel of ir.model.fields Fix: --- Give group_marketing_automation_user the right to read ir.model.fields opw-4001919 Forward-Port-Of: odoo/enterprise#66690
This fix resolves a critical issue where successfully processed Mexican invoices were being rolled back when errors occurred during batch processing. Previously, transaction commits only happened at the end of the entire batch, causing successfully sent invoices to be reverted if any invoice in the batch failed. Now, each invoice is committed immediately after successful processing, preventing duplicate signatures and data loss.
Original PR description
- Create 4 invoices: A, B, C, D with a correct MX setup - Make sure C will fail by removing the SAT code on the product for example - Run the send and print wizard on all invoices and check…
- Create 4 invoices: A, B, C, D with a correct MX setup
- Make sure C will fail by removing the SAT code on the product for example
- Run the send and print wizard on all invoices and check 'Download' (to force a synchronous run).
After each call to the web-service, the code does:
```
# Check for success.
if invoice.l10n_mx_edi_cfdi_state == 'sent':
continue
```
However, the `cr.commit` is at the end of the loop. So the transaction is not committed except in case of error!
When running the send and print synchronously, the error is raised to the user that will rollback the whole
transaction.
In case of the setup above, A, B and C are well commit but D is sent and has been rollback.
Then, the user will sign again D making the invoice signed twice.
To solve the issue, let's commit right after each web-service call.
That way, whatever the way we use to call the web-services, the transaction is commit immediately.
opw-4003043
opw-3985376
opw-4059666
opw-3955553
...and many others!This fix corrects how the system handles duplicate invoices in Peru's electronic invoicing system (SUNAT). Previously, when an invoice was rejected as a duplicate, the system would incorrectly mark it as successfully sent by retrieving an existing confirmation. Now, users will properly receive a rejection notification, prompting them to fix the invoice numbering issue instead of believing it was sent successfully.
Original PR description
In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`. SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequence their invoice. Instead, they get the impression that their invoice was correctly sent to SUNAT. To fix this, we don't try to retrieve an existing CDR if an invoice was rejected as duplicate, but there already exists an invoice with the same edi_filename that was sent to SUNAT. opw-3900393 Forward-Port-Of: odoo/enterprise#65520
This fix resolves a crash that occurred when users tried to create an asset from journal items belonging to different companies. Previously, the system would fail with an error when attempting this operation. Now users can safely create assets from multiple journal items regardless of which company they belong to.
Original PR description
When the customer tries to create an asset for multiple journal items from different companies, a traceback will appear. Steps to reproduce the error: - Create an invoice with Company A - Create an…
When the customer tries to create an asset for multiple journal items from
different companies, a traceback will appear.
Steps to reproduce the error:
- Create an invoice with Company A
- Create an invoice with Company B
- Go to Accounting > Journal Items > select both invoice > Create Asset
Traceback:
```
ValueError: Expected singleton: res.company(1, 5)
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 42, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.2/account_asset/models/account_move.py", line 315, in turn_as_asset
'default_company_id': self.company_id.id,
File "odoo/fields.py", line 5183, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/enterprise/blob/9373f9bac47839e3314a7823e05d4ef61af0b3e3/account_asset/models/account_move.py#L345 Here, When the user creates an asset for multiple journal items from
different companies, Self has multiple 'company_id'.
So it will lead to the above traceback.
sentry-5613448397
Forward-Port-Of: odoo/enterprise#67301
Forward-Port-Of: odoo/enterprise#66806This fix resolves an issue where sale orders with special characters in their sequence numbers (like SO/2024/12/31/01) were not appearing as suggestions during bank reconciliation. Previously, the system would only match if the bank label exactly matched the sale order name, but now it properly compares both using the same formatting rules, making it easier for users to find and match the correct sale orders.
Original PR description
Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them to names. With this commit, we'll compare names and tokens that are formatted the same way. opw-3964898
This update fixes how the planning gantt view displays grouped shifts by properly disabling summary rows that shouldn't be interactive. When shifts are grouped in the planning module, the system now correctly hides total rows and keeps only the main group-level rows visible, improving the visual clarity and usability of the gantt chart.
Original PR description
When shifts are group by in the planning, the open shift and total rows are not disabled. In this commit, we have disabled the total row and all rows except those at group level 0. task-3981814
This update adds missing translation files and terms to the Chile EDI point-of-sale and website sales modules. The website sales translations were also expanded to support other Latin American countries and languages, ensuring users in the region see proper localized text in their preferred language.
Original PR description
- Added missing pot/po files/translations for l10_cl_edi_pos - Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs - Added missing pot file + added missing terms/translations to website_sale module opw-4044338