Thursday, April 25, 2024
5 changes · 17.0
New functionality added to Odoo
Businesses using Odoo for Indian logistics can now create e-way bills directly from stock transfer records, helping keep goods movements compliant with local requirements. The update also adds a cancellation flow for e-way bills, making it easier to manage changes when a shipment is modified or stopped.
Original PR description
[ADD] l10n_in_ewaybill_stock: ewaybill for stock In this commit ================= - Added a new button in stock picking so that ewaybill can be created for stock movement - Added the cancel functionality to the ewaybill task-3376530
Enhancements to existing features
The aged payable accounting report has been optimized to load significantly faster. Previously, the system was processing unnecessary data that was filtered out later, causing timeouts on large databases. The fix streamlines the data retrieval process, reducing load times from over 15 minutes to just seconds for large companies.
Original PR description
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the…
Resolved issues and error corrections
This fix resolves a critical issue that occurred during database migrations when a company was archived. The system was unable to properly set up Point of Sale configurations for archived companies because it couldn't find the required warehouse information, causing the setup process to fail. The fix now allows the system to correctly handle archived warehouses when creating Point of Sale configurations.
Original PR description
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table, this error is generated when it's try to create the…
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the account_partial_reconcile table. Currently, the entire account_partial_reconcile table is being iterated in the report generation, only to be filtered out later on in the query. This superfluous computation is extremely inefficient and it could be easily avoided by correctly using LATERAL JOIN syntax to make use of the filters applied later on.  # Fix: Use the correct condition inside the lateral join to filter on account_move_lines that are already filtered later on. # Benchmark: ### Report loading time | # account partial reconcile lines | # account move lines | Company size | Before | After | | --- | ------ | ------ | ------| ----- | | 588503 | 2339215 | Large | 15m+ (timeout) | ~14.02s | | 5761 | 27635 | Medium | 15m+ (timeout) | ~3s | | 11 | 1513 | Small | 7.69 | ~1.6s | #### Total number of account partial reconcile: 3279438 #### Total number of account move lines: 10688953 # Related ticket: opw-3819017 Forward-Port-Of: odoo/enterprise#61036
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table,
this error is generated when it's try to create the record for pos config from pos_resturant module
by data file (defined on this commit)
https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992
as picking_type_id field in pos_config is required and we set default value by fetching warehouse for related company but here as company is archived, related warehouse is also archived and that why we didnot get picking_type_id for archived company and that will raise Error :
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4787, in _create
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
```
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
Forward-Port-Of: odoo/odoo#151719This fix corrects a bug in the invoice sending process where incorrect object references caused the system to crash when processing multiple invoices. The issue occurred because the code was referencing the wrong object in a loop, leading to a "too many values to unpack" error. This fix ensures invoices are sent successfully without errors.
Original PR description
In line[1], ``self`` is referenced to ``_get_default_mail_attachments_widget``, and using ``self`` instead of ``wizard`` doesn't make sense because ``self`` could potentially hold multiple values.…
In line[1], ``self`` is referenced to ``_get_default_mail_attachments_widget``, and using ``self`` instead of ``wizard`` doesn't make sense because ``self`` could potentially hold multiple values. This becomes problematic when the ``ensure_one`` method is called. Due to this below error is raised
Traceback :
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5848, in ensure_one
_id, = self._ids
ValueError: Expected singleton: account.move.send(168, 167)
File "addons/payment/models/payment_transaction.py", line 985, in _cron_finalize_post_processing
tx._finalize_post_processing()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 144, in _finalize_post_processing
super()._finalize_post_processing()
File "addons/account_payment/models/payment_transaction.py", line 217, in _finalize_post_processing
super()._finalize_post_processing()
File "addons/payment/models/payment_transaction.py", line 1001, in _finalize_post_processing
self.filtered(lambda tx: tx.operation != 'validation')._reconcile_after_done()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 87, in _reconcile_after_done
self._post_subscription_action()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 166, in _post_subscription_action
orders._send_success_mail(tx.invoice_ids, tx)
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/sale_order.py", line 1866, in _send_success_mail
linked_invoices.with_context(email_context)._generate_pdf_and_send_invoice(template)
File "addons/account/models/account_move.py", line 4841, in _generate_pdf_and_send_invoice
return composer.action_send_and_print(force_synchronous=force_synchronous, allow_fallback_pdf=allow_fallback_pdf, bypass_download=bypass_download)
File "addons/account/wizard/account_move_send.py", line 738, in action_send_and_print
return self._process_send_and_print(
File "addons/account/wizard/account_move_send.py", line 663, in _process_send_and_print
moves_data = {
File "addons/account/wizard/account_move_send.py", line 666, in <dictcomp>
**self._get_mail_move_values(move, wizard),
File "addons/account/wizard/account_move_send.py", line 170, in _get_mail_move_values
'mail_attachments_widget': wizard and wizard.mail_attachments_widget or self._get_default_mail_attachments_widget(move, mail_template),
File "odoo/fields.py", line 1206, in __get__
self.recompute(record)
File "odoo/fields.py", line 1421, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1394, in apply_except_missing
func(records)
File "odoo/fields.py", line 1443, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4931, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 100, in determine
return needle(*args)
File "addons/account_edi_ubl_cii/wizard/account_move_send.py", line 68, in _compute_mail_attachments_widget
super()._compute_mail_attachments_widget()
File "addons/account/wizard/account_move_send.py", line 311, in _compute_mail_attachments_widget
self._get_default_mail_attachments_widget(wizard.move_ids, wizard.mail_template_id)
File "addons/account/wizard/account_move_send.py", line 138, in _get_default_mail_attachments_widget
return self._get_placeholder_mail_attachments_data(move) \
File "addons/account_edi_ubl_cii/wizard/account_move_send.py", line 112, in _get_placeholder_mail_attachments_data
if self.mode == 'invoice_single' and self._needs_ubl_cii_placeholder():
File "odoo/fields.py", line 1202, in __get__
record.ensure_one()
File "odoo/models.py", line 5851, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
[1] : https://github.com/odoo/odoo/blob/167dedab5c7423097689c6a7d0d6ee6dd904a8bf/addons/account/wizard/account_move_send.py#L311-L312
sentry - 5234450902
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves a critical error that occurs when upgrading accounting systems with duplicate journal codes. The system was attempting to process multiple journals simultaneously, causing the upgrade to fail. The fix ensures only the first matching journal is selected, allowing upgrades to complete successfully.
Original PR description
issue generated during upgrade. when it's try to find journal with journal_data['code'] and translated_code, wil get two journal, and that will raise exception as signtone error there are two journal…
issue generated during upgrade.
when it's try to find journal with journal_data['code'] and translated_code, wil get two journal,
and that will raise exception as signtone error
there are two journal with 1. INV code
2. FAC code as translated code so will get two journal and got traceback
```
select name,id, code from account_journal where id in (12,13);
name | id | code
----------------------------------------------------------------------+----+------
{"en_US": "Factures clients", "fr_BE": "Factures clients"} | 12 | FAC
{"en_US": "Factures fournisseurs", "fr_BE": "Factures fournisseurs"} | 13 | INV
(2 rows)
File "/tmp/tmpwqzy2fx8/migrations/account/saas~16.2.1.2/end-migrate.py", line 50, in migrate
ChartTemplate._pre_reload_data(company, template_data, data)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 264, in _pre_reload_data
self.env['ir.model.data']._update_xmlids([{
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2270, in _update_xmlids
rows.add((prefix, suffix, record._name, record.id, noupdate))
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 5142, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.journal(12, 13)
```
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
Forward-Port-Of: odoo/odoo#163022
Forward-Port-Of: odoo/odoo#162388