Tuesday, October 15, 2024
14 changes · 17.0
Enhancements to existing features
This update improves how the system matches bills submitted late for GST reporting (GSTR2B). The matching process now uses the specific month of the bill date to find the correct bills, making the matching more accurate and reliable. This ensures businesses can properly reconcile their late bill submissions with their GST returns.
Original PR description
In this PR: - Updated the matching criteria for GSTR2B late bills to use the specific month of the bill date. - Replaced previous date filter on `invoice_date` to limit searches to the start and end of the bill's month. - Ensured accurate retrieval of bills by filtering based on the bill number and company. This change enhances the precision of bill matching in the GSTR2B late bill streamline process.
Resolved issues and error corrections
This fix corrects an issue where Mexican companies' CFDI invoices, payments, and delivery slips were displaying the wrong digital stamp for the emitter. The system was incorrectly showing the SAT (tax authority) stamp in both stamp fields instead of showing the company's own digital stamp alongside the SAT stamp. This has been corrected to display the proper stamps in the PDF documents.
Original PR description
### Steps to reproduce the issue: 1. In Mexican Company, create an Invoice elligible for CFDI 2. Send & Print 3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same ### Explanation: In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello` ### Fix reasoning: Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values opw-4227743
A recent update caused partner names and other non-account information to be misaligned when exporting certain financial reports to Excel. This fix restores the correct display of partner names and similar data in exported reports like the partner ledger, ensuring users see the information in the right columns.
Original PR description
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb
Fixed an issue where users without HR permissions couldn't view employee pictures in the appraisal goal view. Users can now access the public employee profile by clicking the picture, and the "mark as done" option is properly hidden when a goal is already completed. This improves the user experience for non-HR staff using the appraisal system.
Original PR description
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631
This update adds new accounts to the Finnish financial reporting system to improve the chart of accounts structure. The changes ensure that the balance sheet reports now include additional account categories needed for more accurate financial reporting in Finland.
Original PR description
Adding some new accounts in the reports task: 4210069
This update fixes a crash that occurred in the accounting reports when users rapidly removed multiple partners from a filter. The system now gracefully handles situations where filter update requests fail, preventing the application from becoming unresponsive. This improves the stability and user experience when working with partner filters in account reports.
Original PR description
When the partner filter gets a lot of partners removed one after the other very fast, sometimes the filter update request fails, and the `this.data` variable becomes `null` while waiting for data. When this happens, we just ignore the invalid data to mitigate the problem. In [saas-17.2](https://www.odoo.com/odoo/project/967/tasks/3912381) this has anyway being amended by introducing a delay between the partner cancellation and the the filter update. Subsequent requests just reset the delay, so one only request is done in the end. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4020313) opw-4020313
This fix removes a restriction that was preventing users from manually disabling automatic transaction syncing in their online banking connections. Previously, a technical condition was blocking users from saving changes to the auto-sync setting, making it impossible to turn off automatic syncing when needed. The fix simplifies the approach by removing this problematic restriction.
Original PR description
A previous [commit](https://github.com/odoo/enterprise/pull/63926/commits/c749e1358dbd0175d0de5f32eab2c4dd98053905) added a readonly condition on the field auto_sync of the account.online.link view. This was made to prevent the automatic fetching of transaction from interactive providers when the connexion had expired. The issue lies in that condition being based on the field it applies to. This does not work well with manual editing as the readonly condition would update before hitting 'save', preventing to save the changes when unticking the 'auto_sync' checkbox. After discussion with FLG, we decided to keep things simple and remove that condition altogether. Else, one would have had to create a new field and import new data from the institution (is_interactive). No opw but the issue was raised in a odoofin support discord thread.
A bug in the barcode scanning system for manufacturing operations has been fixed. The system was not properly returning results from an internal function, which could cause operations to fail silently. This fix ensures that barcode scanning operations complete correctly when processing inventory moves.
Original PR description
Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super().
Mexican invoices now correctly display the Uso field in Spanish when the customer's language is set to Spanish (MX), instead of showing it in English. This fix ensures that invoice PDF reports respect the customer's language preference for all field labels and values.
Original PR description
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to…
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to reproduce the issue: - Go to the Accounting app --› Customer invoices journal --› Create a new invoice. - Select a customer with the Spanish (MX) / Español (MX) language set. - Select any product from the inventory catalog. - Set the Uso (l10n_mx_edi_usage) as "Gastos en general". - Confirm the invoice. - Click on "Send and print" button and mark the CFDI checkbox in the next window, click on send and print button again. - The Uso (l10n_mx_edi_usage) field is being translated into English, despite the language set for the customer is Spanish (MX) / Español (MX). Cause of the issue: The XML template (report_invoice.xml) uses a dynamic value for the Uso field, preventing the standard PO file translations from being applied. A python translation using the _description_selection from Fields with the env language detection method is necessary in the _l10n_mx_edi_get_extra_invoice_report_values method in account_move.py. opw-4212069
Fixed an issue where EC Sales Reports were incorrectly including transactions when a customer had a delivery address in a non-EC country. The system now properly checks the delivery address country first when determining if a transaction should be included in EC sales reports, and only falls back to the company's country if no delivery address is specified.
Original PR description
…sales Steps to reproduce:: [l10n_fr] - create a customer, BE Company; delivery adress USA - create an invoice for the customer - Go to EC Sales Report Issue: The transaction is displayed Solution: When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries opw-4131299 Forward-Port-Of: odoo/enterprise#69960
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