Daily updates from Odoo
Friday, June 28, 2024
11 changes · 17.0
Resolved issues and error corrections
This fix corrects an issue where rental returns for kits containing sub-kits with shared components were calculating incorrect quantities. When a kit contained the same component in multiple places (e.g., a component both directly and within a sub-kit), the return process would incorrectly double-count quantities. The fix ensures that return stock movements are properly matched to their original kit structure, preventing duplicate quantity calculations.
Original PR description
When renting with deliveries, if it's about a kit with subkit and shared component, the return will not be correct To reproduce the issue: 1. In Settings, enable "Rental Transfers" 2. Create a kit K…
When renting with deliveries, if it's about a kit with subkit and
shared component, the return will not be correct
To reproduce the issue:
1. In Settings, enable "Rental Transfers"
2. Create a kit K as follow:
- K
- C1
- C2
- C3
- C2
3. Confirm a rental with 1 x K
Error: in the return, there are two lines for each C2, which makes
sense since each line is linked to a different kit. However, the
quantity on each line is incorrect: 2 instead of 1
When generating the SM of the return, we first generate the values
https://github.com/odoo/odoo/blob/8db471e74238481a5429f0fcf8fbce1c0960ff27/addons/stock/models/stock_rule.py#L205-L206
In `_push_prepare_move_copy_values`, at some point, we adapt the
quantity of the returned SM based on the other SM of the SO. To do
so, we only consider the SM with the same product (among other
conditions). This criterion is not strict enough: for instance, when
looking at C2 of K, we take its quantity *and* we also take C2 of C1,
which is incorrect. Of course, we do the same when looking at C2 of
C1, hence the incorrect quantities.
OPW-3996074This fix resolves issues preventing branch companies from validating SEPA Direct Debit batch payments. Previously, the system would crash or block validation when processing payments from branch companies with their own SEPA credentials. The update now properly handles SEPA batch exports for branch company structures, allowing organizations with multiple entities to process direct debit payments correctly.
Original PR description
…atch payment Create a branch company and switch to it Activate SEPA Direct Debit (SDD) and add Creditor Identifier Activate Batch Payments Add a SEPA bank account on the Bank journal Add a SEPA bank…
…atch payment
Create a branch company and switch to it
Activate SEPA Direct Debit (SDD) and add Creditor Identifier
Activate Batch Payments
Add a SEPA bank account on the Bank journal
Add a SEPA bank account on a partner
Create SEPA mandate for the partner bank account on the Bank journal
Make an invoice to the partner
Register payment with payment method "SEPA Direct Debit"
Go to Accounting>Customer>Payments
Select the payment > Hit 'Create Batch'
Validate creted batch
Issue: A traceback will raise
```py
File "[...]/enterprise/account_sepa_direct_debit/models/account_payment.py", line 117, in _sdd_xml_gen_header
create_xml_node_chain(InitgPty, ['Id','OrgId','Othr','Id'], company_id.sdd_creditor_identifier)
File "[...]/odoo/tools/xml_utils.py", line 109, in create_xml_node_chain
current_node.text = last_node_value
File "src/lxml/etree.pyx", line 1039, in lxml.etree._Element.text.__set__
File "src/lxml/apihelpers.pxi", line 747, in lxml.etree._setNodeText
File "src/lxml/apihelpers.pxi", line 735, in lxml.etree._createTextNode
File "src/lxml/apihelpers.pxi", line 1538, in lxml.etree._utf8
TypeError: Argument must be bytes or unicode, got 'bool'
```
This occurs because we assign the credit identifier to the branch
company, but when validating the batch the system exports the
sdd xml using the company found on the journal
https://github.com/odoo/enterprise/blob/88d25bd184585143f39011947263e928b14551e5/account_batch_payment/models/account_batch_payment.py#L343
so the parent company that have no Creditor Identifier defined
After adding the Creditor Identifier on the parent company and trying
again the validation an error will block the action
"""Trying to generate a Direct Debit XML file containing payments from
another company than that file's creditor."""
opw-3943103The knowledge module's history revision tour has been updated to align with recent improvements made to the document comparison feature. This ensures the guided tour accurately reflects the current functionality and provides users with an up-to-date learning experience when reviewing document history.
Original PR description
Adapt history revision tour after the improvements done on the comparison feature. task-3761721
This fix resolves an issue where unavailabilities were not being displayed in the appointment scheduling calendar when resources had no assigned companies. Now, resources that are not linked to any specific company will properly show their unavailability periods, ensuring accurate scheduling information is always visible.
Original PR description
In gantt, if there are no allowed companies none of the resources will have their unavailabilities filled in. Resources not linked to any company should still have their unavailabilities filled in. task-3981513
This fix corrects how debit note lines are automatically populated when creating debit notes from credit notes in Colombian companies. Previously, the Purchase Order field was not being filled in correctly because the manual line copying logic was interfering with the standard process. The fix ensures that lines are properly copied with all required fields populated, improving the accuracy of debit note creation.
Original PR description
### Original issue: When creating a debit note on a bill from a purchase order with the option 'copy_lines', the field 'Purchase Order' in the lines is not populated. ### Steps to reproduce: -…
### Original issue:
When creating a debit note on a bill from a purchase order with the option 'copy_lines', the field 'Purchase Order' in the lines is not populated.
### Steps to reproduce:
- Install Purchase, Inventory apps and the l10n_co_edi module
- Switch to a Colombian company
- Go to Accounting > Configuration > Accounting > Journals
- In the Vendor Bill journal > Advanced Settings, uncheck the 'Electronic invoicing UBL 2.1 (Colombia)' option
- Go to Purchase > Orders > Purchase Orders, create a new one and confirm it
- 'Receive Products' and 'Validate'
- Go back to the Purchase order
- 'Create Bill' and 'Confirm'
- From actions, choose 'Debit Note'
- In the wizard, tick 'Copy Lines', select a 'Concepto Nota de Débito' and 'Create Debit Note'
- Display the Purchase Order field in the Invoice Line tab is visible, it should not be populated
### Cause:
This bug is due to another fix that have been badly made because no tests were there. Most of the content of enterprise/l10n_co_edi/wizards/account_debit_note.py:_prepare_default_values is not called when it is supposed to and called when it's not.
In the 'Create Debit Note' wizard view there is an option to copy the lines and so, autopopulate them. This option is not displayed for Debit Notes generated from Credit Notes because the lines would be negative.
(https://github.com/odoo/odoo/blob/47eff65afdba3a2a8283342d8b636657f1fac317/addons/account_debit_note/wizard/account_debit_note_view.xml#L16)
The logic of this option is located in the module account_debit_note: https://github.com/odoo/odoo/blob/2a02ba4de1c823bcdef0e8b6b6373fa27b5587a1/addons/account_debit_note/wizard/account_debit_note.py#L64, the line_ids value is filled with a default value if copy_lines is False. If left empty, the lines are copied from the original account.move.
In this commit, https://github.com/odoo/enterprise/commit/c738f14d4ac88d508b6b75747788f5867eb71a68 we are trying to manually populate the lines of a debit note when it is generated from a credit note. But the code is made so that the lines are always copied.
So in this other commit https://github.com/odoo/enterprise/commit/fa65a1ff8cb7333a3339438513d1eeb5d5f9690e there is a correction to take the copy_lines into consideration. But it breaks the precedent fix as Debit Notes of Credit Notes always have copy_lines to False. So the code to copy the lines manually is actually never called for Debit Notes of Credit Notes (which is the only case we want it to be called in). But is called every time copy_lines is set to True therefore ignoring the actual code to copy the lines in the module account_debit_note.
In the context of the bug of this PR, the problem comes from the manual copying of lines that is missing the value purchase_order_id.
### Solution:
Changing the logic of the _prepare_default_values function:
- if not a Colombian company or not a debit note of a credit note, stop here
- we let the logic in account_debit_note copy the lines (or not) depending on copy_lines.
- if the debit note comes from a credit note, we copy the lines and return
With this flow, the lines will not be copied manually so the value purchase_order_id will be populated.
opw-3962301
Forward-Port-Of: odoo/enterprise#65215
Forward-Port-Of: odoo/enterprise#64689The search bar in account reports now correctly searches for individual accounts even when they're organized in hierarchical groups. Previously, the search only looked at visible lines, which meant searching for a specific account would return the group it belonged to instead. This fix ensures users can find the exact account they're looking for.
Original PR description
Before this commit, the search bar only look at the visible lines. With that a problem arise with hierarchy for example. When writing an account in the searchbar we want to search on the account.account and not the group. task: 3988840
This update fixes a system error that occurred when the IoT quality module tried to process multiple device records at once. The system was incorrectly expecting to handle only a single record, causing it to crash. The fix allows the system to properly iterate through and process multiple records without errors.
Original PR description
An error occurs when the system tries to access single values from multiple records at [1]. Traceback On Sentry: ``` ValueError: too many values to unpack (expected 1) File "odoo/models.py", line…
An error occurs when the system tries to access single values from multiple records at [1].
Traceback On Sentry:
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5851, in ensure_one
_id, = self._ids
ValueError: Expected singleton: iot.device(1, 2, 3, 4, 5, 6, 7, 8)
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 38, in call_kw
return 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 "addons/web/models/models.py", line 76, in web_save
return self.with_context(bin_size=True).web_read(specification)
File "addons/web/models/models.py", line 164, in web_read
for vals in co_records.web_read(field_spec['fields'])
File "addons/web/models/models.py", line 87, in web_read
values_list: list[dict] = self.read(fields_to_read, load=None)
File "odoo/models.py", line 3610, in read
return self._read_format(fnames=fields, load=load)
File "odoo/models.py", line 3821, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "odoo/models.py", line 6608, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1261, in __get__
self.compute_value(recs)
File "odoo/fields.py", line 1443, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4934, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 100, in determine
return needle(*args)
File "home/odoo/src/enterprise/saas-17.2/quality_iot/models/iot.py", line 16, in _compute_qcp_test_type
self.qcp_test_type = types.get(self.type, '')
File "odoo/fields.py", line 1202, in __get__
record.ensure_one()
File "odoo/models.py", line 5854, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
To handle this issue, Implement an iteration to iterate records.
sentry-5540606405
Forward-Port-Of: odoo/enterprise#65604This fix corrects a currency display issue in the Thailand sales tax report where foreign currency invoices were showing incorrect currency symbols. Previously, when exporting the sales tax report to Excel, the Total Amount and VAT Amount were displayed with the company currency sign even though they were in the foreign currency. Now all values are properly displayed in the company currency for consistency and accuracy.
Original PR description
The data from the moves in foreign currency are wrongly exported in sales tax report Steps: - Install l10n_th_reports and select th company - Make an invoice in foreign currency - Go to tax report and click on Sales Tax Report button -> In the xlsx file: `Total Amount` and `Vat Amount` are displayed in move currency with the company currency sign while the `Total Excluding VAT Amount` is displayed in company currency With this commit, we display all the values in company currency. Note: The fix in 16.0 requires that we convert the value from `tax['tax_group_amount']` while in 17.0 we should use the new `tax['tax_group_amount_company_currency']` opw-3959408 Forward-Port-Of: odoo/enterprise#65300
This fix resolves two critical errors that occurred when importing Winbooks data with missing or incomplete information. The system now properly handles missing fields by using default values instead of crashing, allowing imports to complete successfully even when certain data fields are absent from the source file.
Original PR description
Steps:
- import a winbooks with data
1: DOCORDER != VAT and journal not in ('asset_receivable', 'liability_payable')
2: without "AMOUNTEUR"
Actual result:
- 1 KeyError traceback for "display_type"
- 2 TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'
Expected result
- No KeyError, default value is "product" (cf compute)
https://github.com/odoo/odoo/blob/9389095d160a03117f815dacebf591d842c81d1d/addons/account/models/account_move_line.py#L433
- AMOUNTEUR is 0 for calculation if not there
Caused by:
1 https://github.com/odoo/enterprise/commit/b9d4ce816fb926b6c0e7a71cd572c8a1c4134155 2 https://github.com/odoo/enterprise/commit/198ecca82cf61b14f42686e8b051568bda034ce9
opw-3996117
Forward-Port-Of: odoo/enterprise#65159This update resolves an error that occurred when editing customer forms if a specific contact tag (281.50) was deleted from the system. The fix allows the system to gracefully handle missing contact tags instead of crashing, ensuring users can continue working with customer records without interruption.
Original PR description
Currently, an error occurs while editing the customer form view when the '281.50' contact tag is not available Step to produce: - Install the 'l10n_be_reports' module. - Go to the list view of…
Currently, an error occurs while editing the customer form view when the '281.50' contact tag is not available
Step to produce:
- Install the 'l10n_be_reports' module.
- Go to the list view of 'Contact Tags' and delete the '281.50' record.
- Open the customer form view and try to edit it.
Stack Trace :
```
KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7fb69b00be20>, 'l10n_be_reports.res_partner_tag_281_50')
File "odoo/tools/cache.py", line 103, in lookup
r = d[key]
File "<decorator-gen-5>", line 2, in __getitem__
File "odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
ValueError: External ID not found in the system: l10n_be_reports.res_partner_tag_281_50
File "odoo/http.py", line 2250, in __call__
response = request._serve_nodb()
File "odoo/http.py", line 1759, in _serve_nodb
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2055, in dispatch
result = endpoint(**self.request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/custom/default/saas_worker/controllers/main.py", line 2305, in smtp
proxy.message_process(None, message)
File "addons/mail/models/mail_thread.py", line 1369, in message_process
routes = self.message_route(message, msg_dict, model, thread_id, custom_values)
File "home/odoo/src/custom/trial/saas_trial/models/mail.py", line 369, in message_route
return super(MailThread, self).message_route(message, message_dict, model=model, thread_id=thread_id,
File "addons/mail/models/mail_thread.py", line 1093, in message_route
self._routing_handle_bounce(message, message_dict)
File "addons/mail/models/mail_thread.py", line 754, in _routing_handle_bounce
rec_bounce_w_email._message_receive_bounce(bounced_email, bounced_partner)
File "addons/mail/models/mail_thread_blacklist.py", line 104, in _message_receive_bounce
record.message_bounce = record.message_bounce + 1
File "odoo/fields.py", line 1376, in __set__
records.write({self.name: write_value})
File "home/odoo/src/enterprise/saas-17.2/l10n_be_reports/models/res_partner.py", line 26, in write
tag_281_50 = self.env.ref('l10n_be_reports.res_partner_tag_281_50')
File "odoo/api.py", line 584, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "odoo/addons/base/models/ir_model.py", line 2185, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)
File "<decorator-gen-43>", line 2, in _xmlid_lookup
File "odoo/tools/cache.py", line 110, in lookup
value = d[key] = self.method(*args, **kwargs)
File "odoo/addons/base/models/ir_model.py", line 2178, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
```
An error occurs when the system tries to retrieve an external ID of the contact
tag '281.50'at [1], but it is not available.
link [1]: https://github.com/odoo/enterprise/blob/77c76fecda9b63e2fc17431a4cd3623650f93724/l10n_be_reports/models/res_partner.py#L26
To handle this issue, add 'raise_if_not_found=False' if the contact tag '281.50' is
not available.
sentry-5499490971This fix resolves an issue where exchange rates (TipoCambio) in Mexican electronic invoices were showing inconsistent values across different products on the same invoice. The exchange rate will now correctly display a single, consistent value based on the invoice's currency, ensuring compliance with Mexican tax requirements and improving data accuracy in financial documents.
Original PR description
Impacted versions: - 17.0 Steps to reproduce: 1. Install l10n_mx_edi module. 2. Go to Company ESCUELA KEMPER URGATE. 3. Go to Settings / Automatic Currency Rates. 4. Run manually the currency rates.…
Impacted versions:
- 17.0
Steps to reproduce:
1. Install l10n_mx_edi module.
2. Go to Company ESCUELA KEMPER URGATE.
3. Go to Settings / Automatic Currency Rates.
4. Run manually the currency rates.
5. Go to Accounting / Customers / Invoices.
6. Create a new invoice with the next values:
- Customer: "INMOBILIARIA CVA"
- Currency: USD - Product: Any but set the UNSPSC Category (any)
7. Confirm the invoice.
8. Click send and print.
9. Check CFDI and click on Click send and print.
10. Open the generated xml
Current behavior:
- TipoCambio have many variations depending of product and currency value:
Example: June 17th: have:
| Product | Quantity | TipoCambio |
|---------------------------|----------|------------|
| [FURN_0006] Monitor Stand | 1 | 18.538484 |
| [FURN_0004] Letter Tray | 1 | 18.538558 |
| [E-COM09] Large Desk | 1 | 18.538498 |
Expected behavior:
- TipoCambio (inside XML) should have the exchange value of the currency (invoiced). Example: June 17th should have 18.5385 (USD)
Changes:
- Avoid create query to search mx currency
OPW-3985223
Related PR: #64838