Tuesday, October 15, 2024
29 changes
Resolved issues and error corrections
This fix resolves two critical errors in the Mexican EDI Autozone Addenda feature that occurred when invoices were linked to sales orders. The first issue caused a system error when processing a single sales order due to incorrect date formatting, while the second caused failures when an invoice was linked to multiple sales orders. These fixes ensure that invoices with sales orders can now be properly processed and CFDI documents can be generated without errors.
Original PR description
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda…
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object to the strptime function of datetime which in reality it needs to receive a string object instead. This raises a TypeError Since the objective is to set a string date, we convert the date_order into a string date using strftime function from datetime module - Install 'Sales' application and 'l10n_mx_edi' module - In a company with mexican localization selected go to Sales > Quotations and create a new Order - Select a contact with the Addenda Autozone selected - Confirm it and create the corresponding invoice - Confirm the invoice and generate the CFDI 2. Traceback with invoice that have multiple sale order linked. In attribute t-att-PODATE for the Autozone Addenda is not expecting a recordset when initializing the value of sale_id, this causes a ValueError: expected singleton error when retrieving value of date_order when we create a invoice for multiple sale orders Initialize sale_id with the first order retrieved to use it task-no Forward-Port-Of: odoo/enterprise#71875
This fix corrects an issue in the rental app where creating extra fees products was incorrectly setting them as consumable items instead of service products. The fix ensures that when users create extra fees products from rental settings, they are automatically configured as service-type products, which is the correct product category for rental fees.
Original PR description
Steps: - Install rental app. - Goto rental settings. - Create product from extra fees product Issue: - Consumable type product is creating is should be service product. Cause: - No context to set default values for detailed_type field. Fix: - Added context `default_detailed_type: service` to create service type product. opw-4142551 Forward-Port-Of: odoo/enterprise#71641
This fix resolves a system crash that occurred when invoicing partners without proper Uruguayan identification types. Instead of showing a technical error, users now see a clear message explaining what partner information needs to be corrected, making it easier to resolve the issue.
Original PR description
### Description When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the…
### Description
When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the proper error message to the user so he can properly set the partner info.
### Steps to reproduce
1. Open runbot install AR and UY modules
2. In the UY company and invoice a e-ticket to ADHOC SA partner (id CUIT - AR type), total amount should be greater that 30.000
### Before the PR
We receive a traceback error
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1783, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1810, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 2014, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/data/build/adhoc-cicd-odoo-odoo/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/addons/base/models/ir_http.py", line 226, in _dispatch
result = endpoint(**request.params)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 759, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 28, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 732, in action_send_and_print
return self._process_send_and_print(
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 666, in _process_send_and_print
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 572, in _generate_invoice_documents
self._hook_invoice_document_before_pdf_report_render(invoice, invoice_data)
File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/wizards/account_move_send.py", line 59, in _hook_invoice_document_before_pdf_report_render
if errors := invoice._l10n_uy_edi_check_move():
File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/models/account_move.py", line 502, in _l10n_uy_edi_check_move
dtype=self.partner_id.l10n_latam_document_type_id.name))
AttributeError: 'res.partner' object has no attribute 'l10n_latam_document_type_id'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2891:163)
at XMLHttpRequest.<anonymous> (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2895:13)
```
This happens because the document type is related to the invoice, the partner actually has identification type field.
### After the PR
Now it shows the proper message telling the message the problem related to the partner configuration so they can fix it before sending EDI invoice
Reference: LATAM 1275 / ADHOC TICKET 81219This update corrects how exchange rates are applied to foreign currency transactions. Previously, the system was using outdated exchange rates from the last closing date. Now it will use the correct exchange rate for the actual transaction day, ensuring compliance with official foreign currency operation guidelines and more accurate financial reporting.
Original PR description
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/comunicacion/publicaciones/operaciones-moneda-extranjera. latam-task: 1264 adhoc-side-task: 43762