Thursday, October 31, 2024
13 changes · 17.0
Enhancements to existing features
This update enhances the depreciation board by visually distinguishing cancelled depreciation entries in grey. Additionally, users can now properly dispose of assets through hashed journals, resolving a previous error that prevented disposal. This improves asset management workflows.
Original PR description
This commit makes cancelled depreciation entries appear in grey in the depreciation board. It also turns the the depreciation entry's name into a link towards the move's form view.
The system now automatically selects the correct document type (e-Factura or e-Ticket) based on the partner's identification type in Uruguay. When a partner has a RUT/RUC identification, the system defaults to e-Factura, which is the correct choice in 95% of cases. This reduces manual adjustments while still allowing users to override the selection when needed.
Original PR description
Description of the Issue/Feature Addressed by This PR: The current system sets the default document type to e-Ticket, regardless of the partner's identification type. However, for usability purposes, if the identification type is RUT/RUC, the document type should default to e-Factura, as this is the correct choice in 95% of cases. Current Behavior Before PR: The default document type is always set to e-Ticket, irrespective of the identification type. Desired Behavior After PR: The system will automatically select the appropriate document type (either e-Factura or e-Ticket) in the account.move module, based on the partner's identification type (RUT/RUC or other). This will reduce the need for manual adjustments. Users will still have the flexibility to select other document types to account for any exceptions. Latam-task: 1273 Adhoc-side-task: 44194
Resolved issues and error corrections
This update fixes an issue where the timer button on timesheet rows was hidden when users scrolled horizontally within the 'My Timesheets' grid view. Now, the timer button remains visible regardless of horizontal scrolling, ensuring consistent functionality for users managing their timesheets.
Original PR description
Before this commit, when the user horizontally scrolls in the grid view of `My Timesheets` menu, the grid timer button on each row is hidden, only the row title is kept. This commit keeps the grid timer button is kept when the user horizontally scroll in the grid view of `My Timesheets` menu as it is the case for the row title. task-3378510
This update fixes an issue where delivery guides for Mexican customers were incorrectly using the customer's main address instead of their specified delivery address. This ensures accurate delivery information for Mexican tax reporting (CFDI) and avoids potential errors in shipping. The change was triggered by a bug in the delivery address handling process.
Original PR description
**Steps to reproduce:** - Install l10n_mx_edi_stock_extended_31 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, enable "Customer Addresses" - Add a delivery address to a Mexican contact (e.g. INMOBILIARIA CVA) - Create a SO: * Customer: [INMOBILIARIA CVA] * Delivery Address [Delivery address of INMOBILIARIA CVA] * Product: [any product with an UNSPSC category] - Confirm the SO - Go to the created delivery (Its delivery address is the delivery address of INMOBILIARIA CVA) - Edit the delivery: * Transport Type: [Federal Transport] * Vehicule Setup: [any] * Gross Vehicule Weight: [any] * Distance to Destination (KM): [any] - Validate the delivery - Generate Delivery Guide - Check the generated delivery guide xml **Issue:** The destination address in the xml is the address of the main contact. It should be its delivery address. opw-4151229
This update corrects a technical issue related to how sales order item data is processed within the Odoo Enterprise system. By using a lambda function, the system now correctly handles inheritance and returns the expected data format (a list), ensuring accurate sales order item calculations. This improves the reliability of sales reporting.
Original PR description
Since domain method for the Sales Order Item field is not harcoded anymore, the inheritance in this module is now considered, so it needs to be adapted to work correctly with the expected value, i.e. returning a list instead of a string. [FIX] helpdesk_sale_timesheet: unharcode domain method of SO line field Since domain method of the Sales Order Item field is set using the actual class method instead of a lambda, it is not possible to inherit that method when inheriting the model. This issue is fixed by using a lambda function to call the domain method. Forward-Port-Of: odoo/enterprise#72931
This update fixes a bug in the recruitment test that prevented accurate skill detection from OCR results. The changes ensure the test runs correctly after all modules are installed and improve the accuracy of skill matching by refining the search pattern. This enhances the reliability of candidate skill identification.
Original PR description
- Added 'post_install' and '-at_install' tags to ensure the test is executed after all modules are installed, necessary for `test_skill_search_on_ocr_results` to run fully. - Fixed the test to detect when no skills were being added to the applicant, even though some should have been. - Updated the skills search regex: replaced `\s` tags with `\b` tags to correctly detect the first and last words in `ocr_tokens`.
This update fixes an issue where asset calculations in Uruguay were inaccurate due to foreign currency tax values not being properly converted. The change ensures that non-deductible tax values are stored in the asset's currency, leading to correct original value calculations and improved financial reporting. This impacts users in Uruguay utilizing the accounting module.
Original PR description
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This…
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This is used when calculating the original_value of the asset and can cause incorrect calculations. Purpose of this PR: To make sure the non_deductible_tax_value is stored in the asset's currency How to reproduce: 1- install: Uruguay - Accounting 2 - change company country to Uruguay 3- settings -> accounting -> taxes -> Fiscal Country: Uruguay. 4- create a new tax and make sure that the accounts on % of tax are expenses account so that the tax in non-deductible tax. 5- make sure to select the right tax group and country = Uruguay in the advanced options of tax. 6- create new product, and in accounting tap set the fixed asset account to the expenses account. and in the purchase tap make sure that the vendor taxes is set to the tax created before. 7- create a new vendor bill with the currency set to UYU. and confirm the bill. make sure that the fixed assets account is selected. 8- go to assets and create a new asset, in bills tab add the created bill. the asset will be created and the Original Value filed will contain the wrong amount. When calculating the non_deductible_tax_value for an asset, if there are original move lines in a foreign currency they won't be converted into the assets currency opw-4089386 Forward-Port-Of: odoo/enterprise#70268
This update resolves a bug where certain fields in web studio reports weren't translating correctly when editing invoices. The issue stemmed from how the system handled indentation in the report XML, leading to a mismatch between the edited content and the translation keys. This ensures all reports, regardless of language, display accurate translations.
Original PR description
Steps to reproduce ================== - Install account_accountant,web_studio - Go to an invoice - Set the partner's language to French - Print the Invoice without Paiement PDF - Open studio - Edit that report - Add a new text below the invoice header - Save the report and exit studio - Print the same report => Some fields aren't translated Cause of the issue ================== When editing the report, ```xml <strong>Due Date:</strong><br/> ``` is converted to ```xml <strong>Due Date:</strong> <br/> ``` This no longer matches the translation key. opw-3730267
This update resolves a bug where the mass depreciation action incorrectly recalculated posted assets. The fix restricts the action to only draft assets, aligning with existing functionality and preventing unnecessary calculations. This ensures accurate depreciation reporting.
Original PR description
As of today, the action_account_asset_compute_depreciations server action allows to recompute the board on posted assets by calling compute_depreciation_board.
There is two issues with that:
- compute_depreciation_board shouldn't be called on assets that could already have moves without providing a date
- This action should reflect what can be done on the form view (only applies to draft)
The easy fix is to update the action to only affect draft entries.
Task id # 4297606This update resolves an issue where stock quantities weren't correctly updated after changing the lot number in the shopfloor process. The fix ensures that stock levels are accurately reflected, preventing incorrect location assignments for materials. This improves inventory accuracy and reduces potential errors in production workflows.
Original PR description
### Steps to reproduce: - In the settings Enable Multi-steps route - Create a product FP with a BOM: - 1 component: 1 x COMP (tracked by SN) - 1 operation: "Register SN on COMP" - Add an instruction…
### Steps to reproduce:
- In the settings Enable Multi-steps route
- Create a product FP with a BOM:
- 1 component: 1 x COMP (tracked by SN)
- 1 operation: "Register SN on COMP"
- Add an instruction on your op:
- type: "Register consumed component"
- Product To Register: COMP
- Put 2 SN for COMP:
- SN01 in Stock/Shelf1
- SN02 in Stock/Shelf2
- Create and confirm an MO for 1 Unit of FP
> SN01 is reserved on the COMP raw move.
- Go to the shopfloor > "Register SN on COMP"
- Change the SN of the COMP from SN01 to SN02
#### > Go back to the MO the incorrect location was used
### Cause of the issue:
While the lot is correctly updated by the action here: https://github.com/odoo/enterprise/blob/e90cf74be3945d1f1256d398ca9c4b61bc35ed08/mrp_workorder/models/quality.py#L485-L507 The associated quant is not set and hence the move location_id, package, ... are not updated with it.
### Fix:
We take advantage of the `quant_id` dummy field of the `stock.move.line` to update the info to write thanks to the write override: https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L85 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L399-L400 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L911-L920
### Note:
Unfortunately, the Dialog opened when clicking on the the quality check from the shopfloor:
https://github.com/odoo/enterprise/blob/34ab94cdcc49f4ade66953874a03f2988b2b4317/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L12
is not embedded in a form view so that the onchange:
https://github.com/odoo/odoo/blob/366676cafdce00d55823c6daf41452b0c2373e4d/addons/stock/models/stock_move_line.py#L185-L192
is not triggered by our change of "lot_id".
opw-4149941
---This update fixes an issue where printed Chilean invoices displayed inconsistent currency rates for each line item. The change ensures that all invoice lines use a consistent currency rate, improving invoice accuracy and compliance. The fix corrects a calculation error related to rounding within the Chilean currency system.
Original PR description
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For…
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice line. **Cause:** The currency rate to display is computed for each invoice line, based on the following formula: abs(self.balance) / self.price_subtotal However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it. **Solution:** Compute the rate from the total values instead of the subtotal of each line. The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice. opw-4242448 Linked community PR: https://github.com/odoo/odoo/pull/185230 Forward-Port-Of: odoo/enterprise#73035
This update resolves an issue where timesheet grids weren't correctly displaying times due to time zone discrepancies. This fix ensures accurate time representation for timesheet entries, improving data reliability. It's a follow-up to a previous bug fix.
Original PR description
small fix related to following bugfix: https://github.com/odoo/enterprise/pull/72526
This update fixes an issue where invoices for subscription orders weren't accurately calculating amounts due, particularly when down payments were involved. The change ensures that invoice amounts are correctly calculated by using the appropriate data for recurring products, resolving discrepancies and improving invoice accuracy.
Original PR description
### Steps to reproduce the issue: 1. Create a Sale Order with a recurring product and a non-recurring product and Confirm 2. Create a Down Payment Invoice and Confirm It 3. Try creating a new Invoice…
### Steps to reproduce the issue: 1. Create a Sale Order with a recurring product and a non-recurring product and Confirm 2. Create a Down Payment Invoice and Confirm It 3. Try creating a new Invoice 4. The Already invoiced and Amount to invoice values are incorrect ### Explanation: When calculating `amount_to_invoice` in `sale.order` with `is_subscription=True`, the calculation of the non-recurring lines is calculated using their `price_total`, `qty_to_invoice` and `product_uom_qty`. Down Payment lines do not have `price_total`. ### Fix reasoning: In `odoo/addons/sale`, the calculation of `amount_to_invoice` uses `account.move._get_sale_order_invoiced_amount`. https://github.com/odoo/odoo/blob/6a5a94b1cc5556371ea94a17624c534086a2a6e1/addons/sale/models/sale_order.py#L643-L647 https://github.com/odoo/odoo/blob/b5d02cc72543b36c7e5e620a3a579f15c88baed6/addons/sale/models/account_move.py#L157-L166 Modifying this code in order to only calculate using non-recurring `order_line` and adapting already existing test to include down payment possibility. opw-4052417