Daily updates from Odoo
Thursday, June 27, 2024
14 changes · 17.0
New functionality added to Odoo
Odoo now includes financial reporting capabilities for Tanzania, with the addition of balance sheet and profit & loss statements tailored to Tanzanian accounting requirements. This enables businesses operating in Tanzania to generate compliant financial reports directly within Odoo.
Original PR description
Added the balance sheet and profit loss statements to Tanzania localization package. task-3783153
Resolved issues and error corrections
This update corrects rounding calculation errors in the Belgian payroll system that were affecting representation fee calculations. The fix ensures that volatile representation fees are calculated and rounded correctly, preventing discrepancies in employee payslips and financial records.
Original PR description
Forward-Port-Of: odoo/enterprise#65605 Forward-Port-Of: odoo/enterprise#65585
Employees were receiving duplicate timesheet reminder emails when they had records across multiple companies. This fix ensures that reminder emails are only sent to employees within their respective company, eliminating unnecessary duplicate messages. For example, an employee with records in 4 companies will now receive 4 emails instead of 16.
Original PR description
Duplicate emails were being sent out to employees because employees were being searched from user ids for each company, but each search was not filtered by the company. So if there was a user that had multiple employee records, all of their employee records on every company would be pulled up for every company on their database that had timesheet notifications on. For example if there were 4 companies and the employee had an employee record for each of them they would receive 16 emails in total. 4 for each employee record. Adding to the search domain to only look for employees on the current company defined by the for loop avoids these duplicate emails. This is similar to a fix that was done on the manager notification emails here: https://github.com/odoo/enterprise/pull/52808 opw-3748426 Forward-Port-Of: odoo/enterprise#64291
This fix resolves a crash that occurred when creating subscription alerts with the "Create next activity" action while leaving the due date type field blank. The system now properly handles alerts without a specified date range type, allowing users to complete their alert configuration without encountering errors.
Original PR description
Steps to reproduce: - Install "Subscriptions" - Go to "Configuration" -> "Alerts" - Create a new alert: - Add a name for the alert - Action: Create next activty - Trigger On: Modification - Activtiy: To Do - Add a summary - Add a note - Due Date In: 1 - Due Date type: Put it blank Issues: When triggered the action will result in a traceback due to `activity_date_deadline_range_type`. https://github.com/odoo/odoo/blob/9a62d0c82cdc47718181aed36cad763499b4a51d/addons/mail/models/ir_actions_server.py#L123-L124 [Linked PR](https://github.com/odoo/odoo/pull/168043) opw-3946293 Forward-Port-Of: odoo/enterprise#63816
Fixed a bug where the trash workspace in Documents was showing "undefined" for the number of days before items are permanently deleted. Users will now see the correct deletion days value even after updating the setting in Documents Settings.
Original PR description
## How to reproduce: 1. Go to Documents > Settings > Change the deletion days of docs. (Optional) 2. Go to Documents > Trash #### Issue - The Deletions Days shown 'undefined'. It says: 'Items in trash will be deleted forever after undefined days.' ## After this commit: Deletions Days will be shown there even after you update them. Task-3984627
The Cash Flow Statement report was incorrectly including accounts that are not bank or credit card accounts. This fix ensures that only accounts designated as cash or credit card type are included in the report, preventing non-financial accounts from appearing in the statement.
Original PR description
**Steps to reproduce:** - Install account_reports - Go to "Accounting / Accounting / Journals / Journal Entries" - Create a new entry: * Accounting Date: [a date from last month] * Journal Items: [2…
**Steps to reproduce:** - Install account_reports - Go to "Accounting / Accounting / Journals / Journal Entries" - Create a new entry: * Accounting Date: [a date from last month] * Journal Items: [2 lines using accounts that are not of type "asset_cash" or "liability_credit_card"] - Post the entry - Create a journal: * Type: Miscellaneous * Default Account: [one of the accounts used for the created entry] - Go to "Accounting / Reporting / Statement Reports / Cash Flow Statement" **Issue:** The default account from the newly created misc journal appears in the report even if it is not a bank-type (or cash-type) account. **Cause:** Previously, only account moves from a bank or a cash journal were taken into account in the report. The default account of these journals is forced to "asset_cash" type. However, a fix has been made to allow some account moves from miscellaneous journals, which can have any type of account as default account. **Solution:** Only allow default accounts having "asset_cash" or "liability_credit_card" as type. opw-3867312
This fix prevents users from accidentally sending duplicate delivery guides when retrying after a connection error. Previously, the system would clear the ticket number on any error, forcing a new submission on retry. Now, the ticket number is preserved for connection errors, allowing the system to retrieve the existing delivery guide status instead of creating a duplicate.
Original PR description
Currently, if there is a connection error while retrieving the CDR, we clear the ticket number. This will cause the user to send a duplicate delivery guide if he clicks on 'Retry', which is not what we want. Instead, we should keep the ticket number in all error cases except explicit rejection from SUNAT, so that a retry will try to retrieve the CDR again using the existing ticket number. [link to API docs](https://cpe.sunat.gob.pe/sites/default/files/inline-files/ServicioREST_GRE-SEECont_v1.2_0.xlsx) opw-3757843 Forward-Port-Of: odoo/enterprise#65352
This fix resolves an issue where credit notes generated for global invoices in Mexican POS systems would fail validation if created more than 72 hours after the original order. The system now uses the current date for credit note creation instead of the original order date, ensuring compliance with Mexican tax authority (CFDI) validation requirements.
Original PR description
With an MX company Enable QR on POS ticket receipt Open POS session Make 2 orders without customer or invoice (save qr of a receipt) Close POS Session Go to Orders, select the 2 orders Click Actions > Create Global Invoice (After a few days) Open QR link and validate invoice Issue: Credit note CFDI validation will fail In this flow the system first issue a global invoice, then when a customer ask the invoice a credit note for the global invoice needs to be generated with the new invoice. Currently the system uses the original pos order date as credit note date and this will fail validation if the order has been created before 72 hours ago
This fix resolves a memory error that occurred during system upgrades when calculating outstanding amounts for customers with very large numbers of transactions. The issue affected the account follow-up feature when processing partners with hundreds of thousands of transaction records, causing the system to run out of memory. The fix optimizes how these calculations are performed to handle large datasets more efficiently.
Original PR description
During upgrade `_compute_total_due` method calculate for `total_due` and `total_overdue`, with too many move lines, so raises MemoryError queries: ``` jard_1413607=> select partner_id, count(id)…
During upgrade `_compute_total_due` method calculate for `total_due` and `total_overdue`,
with too many move lines, so raises MemoryError
queries:
```
jard_1413607=> select partner_id, count(id) total_move_lines from account_move_line where partner_id is not null group by partner_id order by total_move_lines desc limit 5;
partner_id | total_move_lines
------------+------------------
1905 | 547530
1371 | 288578
1396 | 18423
3223 | 10945
1244 | 6988
```
traceback:
```py
Traceback (most recent call last):
File "/tmp/tmpj_23hd3k/migrations/testing.py", line 208, in test_check
self.check(value)
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 151, in check
self.assertFalse(diff, msg)
AssertionError: [('account.menu_action_move_journal_line_form', 125, 'Accounting > Accounting > Journals > Journal Entries', 205), ('purchase.menu_procurement_management_supplier_name', 247, 'Purchase > Orders > Vendors', 218), ('account.menu_account_customer', 115, 'Accounting > Customers > Customers', 217), ('account.menu_action_move_out_refund_type', 111, 'Accounting > Customers > Credit Notes', 207), ('account.menu_account_supplier', 122, 'Accounting > Vendors > Vendors', 218), ('account.menu_action_move_out_invoice_type', 110, 'Accounting > Customers > Invoices', 206), ('account.menu_action_move_in_refund_type', 118, 'Accounting > Vendors > Refunds', 209), ('account.menu_action_account_moves_all', 126, 'Accounting > Accounting > Journals > Journal Items', 204), ('account.menu_action_move_in_invoice_type', 117, 'Accounting > Vendors > Bills', 208), ('sale.res_partner_menu', 179, 'Sales > Orders > Customers', 217), ('point_of_sale.menu_point_of_sale_customer', 461, 'Point of Sale > Orders > Customers', 217)] is not false : At least one menu or view working before upgrade is not working after upgrade.
('account.menu_action_move_journal_line_form', 125, 'Accounting > Accounting > Journals > Journal Entries', 205):
Traceback (most recent call last):
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 252, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 409, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 438, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3538, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3749, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6590, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1207, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/base_automation/models/base_automation.py", line 745, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4867, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/stock_landed_costs/models/account_move.py", line 19, in _compute_landed_costs_visible
account_move.landed_costs_visible = any(line.is_landed_costs_line for line in account_move.line_ids)
File "/home/odoo/src/odoo/17.0/addons/stock_landed_costs/models/account_move.py", line 19, in <genexpr>
account_move.landed_costs_visible = any(line.is_landed_costs_line for line in account_move.line_ids)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3775, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3825, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3930, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1108, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```
Failed request: UPG-1403488
Ticket: 3797437This update adds French language support to the checkout process for customers in Mexico using the ecommerce platform. Previously, customers selecting French would see English text during checkout, creating a poor user experience. The fix translates customer-facing elements while leaving technical invoicing terms in their original language to avoid duplicating translations across multiple Mexico localization modules.
Original PR description
This module adds user facing elements to ecommerce (i.e. the Website > Shop). This results in part of the checkout process showing up in English when customers are using a language other than Spanish. We make an exception for translating a localization into a language other than the one spoken in the country it's specific to because this is customer facing (i.e. in the website) and we do not want to restrict the language of the potential ecommerce customers. Unfortunately some of the terms that show in the extra step added by this model are defined in other `l10n_mx_*` modules and since we don't want to have to track down only these specific terms or translate all of the Mexico localization into French, we leave some parts untranslated (specifically the invoicing specifics) opw-3881171
This update fixes how the bank statement import system processes transaction type information from bank files. The system now properly handles cases where transaction type data uses different capitalization formats, making the import process more reliable and preventing potential errors when processing bank statements from various sources.
Original PR description
The issue: Our code generally assumes that strings are uppercase, which is typically true. However, in some cases, such as the one described in this ticket, the input string is only capitalized (the first character in uppercase). The Fix: convert the keys to uppercase before retrieving their values from the array, and use the get method instead of the bracket notation for safer access. opw-3979945 Forward-Port-Of: odoo/enterprise#64887
When users replace an attachment in the Documents module, the new file now correctly maintains its link to the original product or record. Previously, replacing a file would break the connection between the document and the product it was attached to, making it difficult to track which product the updated file belonged to.
Original PR description
Steps to reproduce: ------------------- - Install `Documents` and `Inventory` (for test purpose) modules - Go to Settings and enable `Centralize files attached to products` - Go to Inventory > Products > Choose any product - Add an attachment to the Product - Go to Documents, then select the `Products` workspace - Select document related to product just uploaded - `Replace` the attachment with a new one (old one should be added to `History`) Issue: ------ The new attachment, and therefore the document, is not related to the product anymore. Cause: ------ When uploading a new attachment, we link the attachment to the document, and we don't keep the related record. Solution: --------- Keep the related record on the new attachment and remove it from the old attachment to not have all versions of the attachments displayed on the attachments of the products. opw-3932497 Forward-Port-Of: odoo/enterprise#64530
This fix resolves a technical issue where appointment durations entered in hours and minutes format (like 1:50) were causing scheduling failures and 404 errors. The system was converting these durations to decimal numbers, which created precision problems. The fix ensures appointment scheduling works correctly regardless of the duration format entered.
Original PR description
[FIX] appointments: precision issue in appointment durations Representing duration given in HH:MM as fractions of an hour (i.e. as float) causes precision issues. Added comparia [Reproduce] - Install website_appointment - Open an appointment, modify "Appointment Duration" to 1:50 - Open preview for the appointment, try scheduling a slot - BUG: 404 opw-3914117 Forward-Port-Of: odoo/enterprise#65170 Forward-Port-Of: odoo/enterprise#63335
The Marketing Automation template form was displaying a duplicate button that wasn't functional or needed. This update removes that button from the interface, cleaning up the user experience and reducing confusion about available actions.
Original PR description
Before this PR: In Marketing Automation, upon opening a template form view, a duplicate button is displayed which won't be used. After this PR: Duplicate button is now hidden. Task - 3994775