Odoo Changelog — 2024-09-19

Thursday, September 19, 2024

4 changes · saas-17.2

Bug Fixes(4)

Resolved issues and error corrections

[FIX] stock: Fix forecast report for multi-step push rules

Coresaas-17.2stockMEDIUM

The stock forecast report now correctly identifies customer-bound moves when multi-step delivery routes use push rules. This helps businesses see more reliable outgoing stock quantities and avoid misleading inventory forecasts.

Original PR description

Following #156437, the new default setup for multi-step deliveries is through the new push rules. This means that when you trigger a delivery to a customer, it will first create the PICK before creating the delivery.

This means that now we need to check on the `location_final_id` if it exists before checking the `location_dest_id`, as it holds the real destination of the move to consider it as an 'out' move or not.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#inventory#forecast#deliveries#multi-step routes

[FIX] account_debit_note: allow debit note journal type recomputation

PR #180469

Coresaas-17.2account_debit_noteMEDIUM

This fix restores the ability to choose a specific journal when creating a debit note from an invoice. It ensures the debit note wizard correctly determines the journal type, so valid journals are shown instead of an empty selection.

Original PR description

Steps to reproduce:
- Install Accounting and account_debit_note
- Accounting > Customers > Invoices > Select any
- Gear Icon > Debit note
- Try to select an entry in 'Use Specific Journal'

No journal is available to pick from, this happens because 'Use specific journal' filters journal_id with the domain [('type', '=', journal_type)], and journal_type mistakenly has the value False.

The root cause of this issue is the strengthened recompuation protection added in 20c2e5996651168db3a6d75ace6a8907c1661792. The ORM will no longer allow recomputation of fields without a default if they share a compute method with another field which has a default value. (In an onchange flow).

At the time of the wizard's creation we update the cache in onchange() to contain False for each value without a default. In 17.0 and earlier we used to invalidate that cached value, leading to the computation of journal_type, but that behavior has changed since.

To avoid uncessary recomputation of 'move_type' (which is given a default value) we protect its compute method. However 'move_type' shares its compute method with journal_type, so we also prevent the computation of journal_type in the process.

We end up with our debit note wizard which has never made a call to _compute_from_moves (meaning is has no journal_type) and thus filter journal_id by [('type', '=', False)], which is forbidden as journal_id.type is a required field, preventing us from selecting a journal.

opw-4124278

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#accounting#debit-notes#journals

[FIX] l10n_ar: set company on demo data to avoid double default tax

PR #180420

Coresaas-17.2l10n_ar

This fixes an issue where loading Argentine localization demo data after database setup could fail because some sample products received duplicate default taxes. The affected demo products are now tied to the correct company, preventing errors when sample invoices or accounting entries are created.

Original PR description

### Steps to reproduce: - Create a db with `l10n_ar` but without demo data - In dev move at the bottom of the settings page: Load Demo data #### > UserError > load aborted. ### Cause of the issue:…

### Steps to reproduce:

- Create a db with `l10n_ar` but without demo data
- In dev move at the bottom of the settings page: Load Demo data

#### > UserError > load aborted.

### Cause of the issue:

Since commit 051d43dbef390de171307fe0e493d651c9ad7b4b (17.0), during the create of products, if the product is not associated to a given company, we add a default tax for each company that is not in the context (and hence should not have defined a tax yet):
https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/account/models/product.py#L138-L146 However, if you were to create a DB without demo data and if you were loading the demo data from the UI, you will create demo datas product for companies that had already set a tax for that product (e.g. `company_ri` on the product `product_product_telefonia`) and since the current company is in the context the override of the create will add a second tax on these products for that companies. As such, if the product is later used in account moves it will raise a user error: https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/l10n_ar/models/account_move.py#L141-L144 and the installation of the all the demo datas will then be aborted.

### Fix:

Since the demo data's products used in the account moves raising user errors are only expected to be used in the the company for which we have associated a tax eg:
https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/l10n_ar/demo/account_supplier_invoice_demo.xml#L136 we simply add a company_id on these products. Note that the test datas had to be updated in somewhat a similar way in
commit 051d43dbef390de171307fe0e493d651c9ad7b4b.

opw-4180872
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#Argentina#demo data#taxes#localization

[FIX] sale_purchase_stock: Keep MTO link in multi-step reception

PR #179964

Coresaas-17.2sale_purchase_stockMEDIUM

This fix keeps the connection between sales orders and their related purchase orders when products are received through multiple warehouse steps. It helps ensure make-to-order purchases remain traceable and correctly linked throughout the receipt process.

Original PR description

With the old pull rules, pickings were created up to the last step before reception (i.e. Input in multi-step reception) which would be all in the procurement group. Then, once the purchase order is validated, then reception move would be the orig of that last step move. In this case, the link would work properly.

However, with the new push rules, the move that trigget the creation of the purchase order is no longer Input -> Stock, but the first step of delivery. This still works correctly until the first reception step is completed, but then the move_orig of the Stock -> Output is no longer Vendor -> Input, but Input -> Stock, which doesn't contain the link to the purchase order.

This means we have to rollup the orig of the move to get to the actual purchase order, regardless of the number of extra steps in between.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#make-to-order#warehouse#purchasing#traceability

Following #156437, the new default setup for multi-step deliveries is through the new push rules. This means that when you trigger a delivery to a customer, it will first create the PICK before creating the delivery. This means that now we need to check on the `location_final_id` if it exists before checking the `location_dest_id`, as it holds the real destination of the move to consider it as an 'out' move or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce: - Install Accounting and account_debit_note - Accounting > Customers > Invoices > Select any - Gear Icon > Debit note - Try to select an entry in 'Use Specific Journal' No journal is available to pick from, this happens because 'Use specific journal' filters journal_id with the domain [('type', '=', journal_type)], and journal_type mistakenly has the value False. The root cause of this issue is the strengthened recompuation protection added in 20c2e5996651168db3a6d75ace6a8907c1661792. The ORM will no longer allow recomputation of fields without a default if they share a compute method with another field which has a default value. (In an onchange flow). At the time of the wizard's creation we update the cache in onchange() to contain False for each value without a default. In 17.0 and earlier we used to invalidate that cached value, leading to the computation of journal_type, but that behavior has changed since. To avoid uncessary recomputation of 'move_type' (which is given a default value) we protect its compute method. However 'move_type' shares its compute method with journal_type, so we also prevent the computation of journal_type in the process. We end up with our debit note wizard which has never made a call to _compute_from_moves (meaning is has no journal_type) and thus filter journal_id by [('type', '=', False)], which is forbidden as journal_id.type is a required field, preventing us from selecting a journal. opw-4124278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Steps to reproduce: - Create a db with `l10n_ar` but without demo data - In dev move at the bottom of the settings page: Load Demo data #### > UserError > load aborted. ### Cause of the issue: Since commit 051d43dbef390de171307fe0e493d651c9ad7b4b (17.0), during the create of products, if the product is not associated to a given company, we add a default tax for each company that is not in the context (and hence should not have defined a tax yet): https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/account/models/product.py#L138-L146 However, if you were to create a DB without demo data and if you were loading the demo data from the UI, you will create demo datas product for companies that had already set a tax for that product (e.g. `company_ri` on the product `product_product_telefonia`) and since the current company is in the context the override of the create will add a second tax on these products for that companies. As such, if the product is later used in account moves it will raise a user error: https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/l10n_ar/models/account_move.py#L141-L144 and the installation of the all the demo datas will then be aborted. ### Fix: Since the demo data's products used in the account moves raising user errors are only expected to be used in the the company for which we have associated a tax eg: https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/l10n_ar/demo/account_supplier_invoice_demo.xml#L136 we simply add a company_id on these products. Note that the test datas had to be updated in somewhat a similar way in commit 051d43dbef390de171307fe0e493d651c9ad7b4b. opw-4180872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

With the old pull rules, pickings were created up to the last step before reception (i.e. Input in multi-step reception) which would be all in the procurement group. Then, once the purchase order is validated, then reception move would be the orig of that last step move. In this case, the link would work properly. However, with the new push rules, the move that trigget the creation of the purchase order is no longer Input -> Stock, but the first step of delivery. This still works correctly until the first reception step is completed, but then the move_orig of the Stock -> Output is no longer Vendor -> Input, but Input -> Stock, which doesn't contain the link to the purchase order. This means we have to rollup the orig of the move to get to the actual purchase order, regardless of the number of extra steps in between. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr