Tuesday, October 15, 2024
13 changes
2 changes
Resolved issues and error corrections
This update resolves several operational issues across Odoo, including Finnish VAT reporting, manufacturing work order quantities and durations, purchase valuation rounding, POS superuser access, image thumbnails, and editor toolbar behavior. These fixes improve reporting accuracy, reduce accounting corrections, and make day-to-day workflows more reliable for users.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The self-order payment page now starts the payment process only after the page is mounted, avoiding repeated page renders. This prevents duplicate Razorpay terminal requests for the same order, reducing payment errors and improving checkout reliability.
Original PR description
Before this commit: =================== The payment page was being rendered multiple times due to the `onWillStart` method triggering the `startPayment` method multiple times. This led to multiple requests being sent to the Razorpay terminal for the same order. After this commit: ================== Replaced `onWillStart` with `onMounted` to initiate the `startPayment` method. This prevents duplicate requests to the Razorpay terminal for the same order, ensuring the payment process is handled efficiently. Task- 4254682
11 changes
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 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 81219